Rob Shakir | 23 Jul 23:56 2014

Re: SPRING MPLS and Entropy Label

Hi Kireeti,

(Responding on-list for completeness - and a reminder to myself.)

On 23 Jul 2014, at 12:54, Kireeti Kompella <kireeti <at> juniper.net> wrote:

>> - I feel that it would be useful to provide some clarification as to where we
>> expect entropy to be required for load-sharing in the draft.
> 
> There are three questions hiding here:
> 1) is ECMP needed with MPLS SPRING (in particular, Adj-SID)?
> Valid question, as ECMP wasn't seen at first as necessary with RSVP-TE, which shares intent with Adj-SID.
I'd say the answer is Yes.  You give an example of why; analogies from the multi path RSVP draft can also be
used. 
> 
> 2) is EL the way to achieve ECMP with MPLS SPRING?
> I sincerely hope so; having two mechanisms in MPLS to enable ECMP wouldn't be ideal. But I won't rule out
other ways. 
> 
> [Your point is taken: laying out (1) and (2) more clearly would help the draft.]

rjs> I agree with both points. Let me work to contribute some material to expand on the couple of points I
raised following the meeting this week.

> 
> 3) Given Yeses to (1) and (2), how?
> That's the current focus of the draft. This part is for now an exploration. I agree that at some point, we
have to narrow the options down to a few (ideally one). This would be an action for vendors, knowing their
chips, and providers, knowing their requirements to sit together and work it out. 
> 
(Continue reading)

internet-drafts | 23 Jul 19:54 2014
Picon

I-D Action: draft-ietf-mpls-ipv6-only-gap-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

        Title           : Gap Analysis for Operating IPv6-only MPLS Networks
        Authors         : Wesley George
                          Carlos Pignataro
	Filename        : draft-ietf-mpls-ipv6-only-gap-01.txt
	Pages           : 24
	Date            : 2014-07-23

Abstract:
   This document reviews the MPLS protocol suite in the context of IPv6
   and identifies gaps that must be addressed in order to allow MPLS-
   related protocols and applications to be used with IPv6-only
   networks.  This document is not intended to highlight a particular
   vendor's implementation (or lack thereof) in the context of IPv6-only
   MPLS functionality, but rather to focus on gaps in the standards
   defining the MPLS suite.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-only-gap/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-ipv6-only-gap-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ipv6-only-gap-01

Please note that it may take a couple of minutes from the time of submission
(Continue reading)

Loa Andersson | 23 Jul 18:04 2014
Picon

English review of MPLS wg documents

Working Group,

We have been aware of that some documents would benefit from an
English review before we request publication or even before the
wglc.

We have done an English review of one document, the experience is
very good. We now would like to have authors/editors to volunteer
their documents for this type of review.

We would also need to have volunteer reviewers, please tell the wg
chairs if you are willing to be an English language reviewer.
We has asked this before so if you already volunteered we should
have your name listed.

/Loa
--

-- 

Loa Andersson                        email: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Loa Andersson | 23 Jul 17:51 2014
Picon

working group last draft-ietf-mpls-deprecate-bgp-entropy-label

Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-deprecate-bgp-entropy-label-01.

Please send your comments to the mpls wg mailing list (mpls <at> ietf.org).

There are no IPR disclosures against this document. The authors have
stated that they are unware of any IPRs related to this document.

This working group last call ends August 6, 2014.

/Loa
for the MPLS wg chairs
--

-- 

Loa Andersson                        email: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

internet-drafts | 23 Jul 17:29 2014
Picon

I-D Action: draft-ietf-mpls-deprecate-bgp-entropy-label-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

        Title           : Deprecation of BGP Entropy Label Capability Attribute
        Authors         : John G. Scudder
                          Kireeti Kompella
	Filename        : draft-ietf-mpls-deprecate-bgp-entropy-label-01.txt
	Pages           : 4
	Date            : 2014-07-23

Abstract:
   RFC 6790 defines the BGP Entropy Label Capability attribute.
   Regrettably, it has a bug: although RFC 6790 mandates that Entropy
   Label-incapable routers must remove the attribute, in practice this
   requirement can't be guaranteed to be fulfilled.  This specification
   deprecates the attribute.  A forthcoming document will propose a
   replacement.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-deprecate-bgp-entropy-label/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-deprecate-bgp-entropy-label-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-deprecate-bgp-entropy-label-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
(Continue reading)

Gregory Mirsky | 22 Jul 20:57 2014
Picon

BFD Directed Path discussion

Dear All,

on behalf of the authors of this work I thank you all who participated in the discussions Monday (BFD WG) and today (MPLS WG). Great comments and suggestions – very excited by your interest in this work.

I’ve tried to capture summary of the comments and sketch possible ways to address these:

·         BFD Return Path TLV suitable for RFC 5880, what about S-BFD?

In order to maintain stateless character of S-BFDReflector, S-BFD control packet may need to carry return path information. Need to discuss with authors of S-BFD Base and start work on S-BFD over MPLS LSP with IP and ACH encapsulations;

·         What would happen if Return Path conveyed to the far-end BFD peer is not available? Ingress may send another BFD Return Path in its TLV along with the same BFD Discriminator;

·         Can BFD Echo of RFC 5880 be used in conjunction with the BFD Return Path TLV over MPLS LSP? It may be interesting as BFD Echo already allows for a payload but work on proper handling and encapsulations of BFD Echo is needed. Besides, use of BFD Echo over MPLS LSP may be limited to single segment LSPs thus S-BFD may be more generic mechanism to have stateless far-end BFD peer;

·         how this work is related to Extended BFD Discriminator TLV work? Both may be complementary, especially as parts of controlling BFD session. Would welcome authors of Extended BFD Discriminator TLV to discussion and review draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf drafts (authors are planning to bring them over the finish line)

 

Please excuse me if I’ve missed your question and please add it to this discussion.

 

                Regards,

                                Greg

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Xuxiaohu | 22 Jul 17:05 2014

Re: [spring] SPRING MPLS and Entropy Label

It makes no sense of making that compromise, IMHO. It seems that the most feasible way is to allow operators
themselves to make the choice among these options according to their network conditions.

Best regards,
Xiaohu

________________________________________
发件人: stephane.litkowski <at> orange.com [stephane.litkowski <at> orange.com]
发送时间: 2014年7月22日 22:51
收件人: Xuxiaohu; Rob Shakir
抄送: mpls <at> ietf.org; spring <at> ietf.org; draft-kini-mpls-spring-entropy-label <at> tools.ietf.org
主题: RE: [spring] SPRING MPLS and Entropy Label

So let's find the best compromise ... but we can't stay stuck ...


-----Original Message-----
From: Xuxiaohu [mailto:xuxiaohu <at> huawei.com]
Sent: Tuesday, July 22, 2014 10:39
To: LITKOWSKI Stephane SCE/IBNF; Rob Shakir
Cc: mpls <at> ietf.org; spring <at> ietf.org; draft-kini-mpls-spring-entropy-label <at> tools.ietf.org
Subject: Re: [spring] SPRING MPLS and Entropy Label

I personally don't believe there is any possibility of making that recommendation at present since each
option is only applicalbe in a certain condition.

Best regards,
Xiaohu
________________________________________
发件人: spring [spring-bounces <at> ietf.org] 代表 stephane.litkowski <at> orange.com [stephane.litkowski <at> orange.com]
发送时间: 2014年7月22日 22:27
收件人: Rob Shakir
抄送: mpls <at> ietf.org; spring <at> ietf.org; draft-kini-mpls-spring-entropy-label <at> tools.ietf.org
主题: Re: [spring] SPRING MPLS and Entropy Label

> It sounds like you'd be supportive of asking the authors to extend
> this draft to making a recommendation? :-)

Completely right :)


-----Original Message-----
From: Rob Shakir [mailto:rjs <at> rob.sh]
Sent: Tuesday, July 22, 2014 10:23
To: LITKOWSKI Stephane SCE/IBNF
Cc: spring <at> ietf.org; draft-kini-mpls-spring-entropy-label <at> tools.ietf.org; mpls <at> ietf.org
Subject: Re: [spring] SPRING MPLS and Entropy Label

Hi Stephane,

On 21 Jul 2014, at 22:52, <stephane.litkowski <at> orange.com> <stephane.litkowski <at> orange.com> wrote:

> Hi Rob,
>
> Many thanks to raise this important subject back on the table.
> Entropy label in SPRING is mainly a matter of what are the current
> capabilities of our favorite vendor's current HW ... Unfortunately, I
> think we are touching something quite "secret"  and vendors would not
> share their issues publicly :)

There are two things that we need to achieve w.r.t SR/MPLS and EL from my perspective:

1) How do we exploit EL with *today's* hardware such that SR LSPs can be efficiently load shared?
2) Going forward, which of the approaches that this draft identifies for dealing with deep label stacks
produced by SR/MPLS should we optimise for?

So, yes, I agree that there's something around current capabilities that we need to figure out - but
equally, I'd like to visit question (2), such that we can see whether the WG thinks that it is possible that
we can reach a recommendation and hence future hardware revisions can potentially focus on optimising
for one particular SR/MPLS + EL approach.

> I think some options may also introduce some "HW capability" issues :
> - reusable EL and EL top of the stack  : need multiple MPLS operation
> , so it may require forwarding feedback loops on some HWs reducing the
> forwarding capacity
>
> Personally, I don't like (hate :) ), the multiple EL/ELI (at each tunnel level or at specific point of
insertion) because it would again reduce the available MTU for the customer jumbo frames.

ACK - this is one of the reasons that I would like to understand the author's intentions on this draft. At the
moment, the draft is a taxonomy of the approaches, but rather stops short of making any recommendations.
It sounds like you'd be supportive of asking the authors to extend this draft to making a recommendation? :-)

Cheers,
r.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne
doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a
ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be
protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
spring mailing list
spring <at> ietf.org
https://www.ietf.org/mailman/listinfo/spring


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne
doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur,
veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant
susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be
protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
류정동 | 22 Jul 15:32 2014
Picon
Picon

Uploaded draft-ietf-mpls-smp-requirements-07

Hi, all.

The authors of this document uploaded a new version, which resolves all the comments raised so far. 

Best regards,

Jeong-dong

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

internet-drafts | 22 Jul 14:59 2014
Picon

I-D Action: draft-ietf-mpls-smp-requirements-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

        Title           : Requirements for MPLS-TP Shared Mesh Protection
        Authors         : Yaacov Weingarten
                          Sam Aldrin
                          Ping Pan
                          Jeong-dong Ryoo
                          Greg Mirsky
	Filename        : draft-ietf-mpls-smp-requirements-07.txt
	Pages           : 15
	Date            : 2014-07-22

Abstract:
   This document presents the basic network objectives for the behavior
   of shared mesh protection (SMP) which are not based on control plane
   support. This is an expansion of the basic requirements presented in
   RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC
   6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". This
   document provides requirements for any mechanism that would be used
   to implement SMP for MPLS-TP data paths, in networks that delegate
   protection switch coordination to the data  plane.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-smp-requirements-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-smp-requirements-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Adrian Farrel | 22 Jul 14:56 2014
Picon

Progressing foo-over-UDP

In London I took an action to write up suggested text for how to handle the
concerns of congestion and checksum in UDP-over-foo.

I think we had some agreement of what was needed (look at the minutes of TSVWG -
or was it TSV Area? - from London).

Of course, I have let you all down. I have about 75% of the necessary text for
MPLS-over-UDP (as a concrete example), but I am not complete. You don't need to
know my excuses.

Attached below (so you can laugh at me) is the text I have so far. it is work in
progress, but since I am currently getting in the way, some of you might want to
take the pen (if no-one wants to, I will try to continue and complete this).

Cheers,
Adrian

==================

x.  Applicability and Deployment of MPLS-in-UDP

   It is helpful to categorise the type of networks in which this
   solution might be deployed.  That is, it is useful to look at the
   type of network over which the UDP tunnel might run, and the type of
   network that may be running MPLS.  An understanding of these 
   categories will lead to the realization that deploying MPLS-in-UDP in
   some environments is entirely safe, in other scenarios might cause 
   issues to the networks involved but is a local choice for the 
   operators of those networks, while in other situations the deployment
   might be significantly harmful to other services or traffic outside
   the responsibility of the operator deploying MPLS-in-UDP.

   In broad terms these deployment categories can be listed as follows:

   - Tunneling across the Internet
   - Tunneling over a provider network in a customer/provider
     relationship
   - Tunneling in a client/server relationship owned by a single
     operator
   - Tunneling within a "flat" network

   The remainder of this section describes the deployment of MPLS-in-UDP
   in these networks, and gives warnings, advice, and caveats
   appropriate to those scenarios with special reference to congestion
   avoidance and the use of checksums.  The use made of MPLS-in-UDP by
   applications must be cognisant of the underlying network deployment.
   However, it needs to be understood that an end-point application is
   generally unaware of the services or connectivity over which it is
   sending data.  That is, an end-point application is sending IP data
   possibly using TCP or UDP, and that data is encapsulated in MPLS
   somewhere within the network, and then those MPLS packets are
   themselves encapsulated in UDP as described in this document.  That
   means that the decision points for the concerns and choices described
   in the sections that follow are at the point of encapsulation of MPLS
   in UDP, and at the time of deployment of the encapsulation function.
   While there are possibilities to apply back-pressure to applications,
   when there is tunneling within tunnels and a significant amount of
   multiplexing of flows within flows (as is the case with MPLS-in-UDP)
   these techniques are hard to apply and may have less immediate
   effect.

   Implementers are advised to note that widely deployable
   implementations have to provide the function set that is needed in
   each of the deployment scenarios discussed below.  That is, those
   implementations that only provide a subset of the functionality are
   not suitable for deployment in the full set of scenarios.

   The text in these sections is not intended to be, and should not be
   taken as, broader guidance for the issues of tunneling different
   protocols over UDP.

x.1.  Congestion Considerations

   End-to-end traffic flows may be multiplexed into MPLS LSPs, and those
   LSPs may be multiplexed into a single UDP tunnel.  These UDP tunnels
   appear as single flows in the core IP network over which the tunnel
   flows.  Thus, any congestion issues related to the core network and 
   caused by end-to-end traffic flows may be hard to report back to the
   head ends of the flows causing the congestion.

   The impact of congestion must be considered both in terms of the
   effect on the rest of the network of a UDP tunnel that is consuming
   excessive capacity, and in terms of the effect on the flows using the
   UDP tunnels in particular if packets are queued (causing delay or 
   jitter) or dropped.

   Various mechanisms exist to propagate congestion information to the
   source of flows either when congestion has occurred or when it is
   perceived to be imminent.  It should be noted that in the case of a
   tunnel (such as a UDP tunnel), the source of a flow is the head end
   of the tunnel.  That is, any congestion notification from the core
   network will be propagated to the head end of the tunnel, not to the
   original source of the traffic.  

   The head end of a UDP tunnel can take a number of actions when it is
   informed about congestion.  No comment is made here about which
   action is best or even appropriate, but section x.3 discusses these
   actions in the context of the different deployment scenarios.

   - Do nothing assuming that the burden of congestion will be carried 
     by other flows, or that the fact of congestion on the UDP tunnel
     will cause back-pressure in the payload flows.

   - Pass on the congestion information to the payload flows.  However,
     in this instance the payload of the UDP tunnel is MPLS flows, and
     the mechanisms for congestion notification in MPLS flows are
     lacking.

   - Throttle the data being placed onto the UDP tunnel by queuing or
     dropping packets from the payload flows.

   - Change the flows that are in a tunnel by putting some of them in a
     different tunnel.  This may have no effect on the congestion, but
     in some networks with ECMP may result in an improvement.

   - Completely fail one or more flows carried in the tunnel, or even
     fail the entire tunnel.  This mechanism is sometimes known as
     "circuit breaker".

x.2.  UDP Checksum Considerations

is checksum an issue
what can be done about it

- use it or not

x.3.  Deployment Scenarios

x.3.1.  MPLS-in-UDP over the Public Internet

   - Tunneling across the Internet
   The use of MPLS-in-UDP over the public Internet is NOT RECOMMENDED.

x.3.2. MPLS-in-UDP in Managed Networks

   - Tunneling over a provider network in a customer/provider
     relationship
   - Tunneling in a client/server relationship owned by a single
     operator

x.3.3. MPLS-in-UDP in Private Networks

   - Tunneling in a client/server relationship owned by a single
     operator
   - Tunneling within a "flat" network

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

George Swallow (swallow | 22 Jul 14:49 2014
Picon

Re: IPR poll on draft-akiya-mpls-entropy-lsp-ping

I'm not aware of any IPR beyond the two that are linked to the mols/documents page.

George

On Jul 13, 2014, at 3:51 AM, Loa Andersson <loa <at> pi.nu> wrote:

> Folks,
> 
> I've responses from
> 
> Nobo, Sam, and Carlos.
> 
> Need responses from
> 
> George, Andy and Nagendara
> 
> Please note that Nagendra is listed as contributing author and need
> to respond.
> 
> /Loa
> 
> On 2014-07-12 23:54, Nobo Akiya (nobo) wrote:
>> Hi Loa,
>> 
>> I am not aware of any other IPRs to this document besides IPRs # 2221 and # 2305.
>> 
>> Thanks!
>> 
>> -Nobo
>> 
>>> -----Original Message-----
>>> From: Loa Andersson [mailto:loa <at> pi.nu]
>>> Sent: Saturday, July 12, 2014 10:02 AM
>>> To: mpls <at> ietf.org
>>> Cc: mpls-chairs <at> tools.ietf.org; draft-akiya-mpls-entropy-lsp-
>>> ping <at> tools.ietf.org; Martin Vigoureux
>>> Subject: IPR poll on draft-akiya-mpls-entropy-lsp-ping
>>> 
>>> Working Group,
>>> 
>>> The authors of draft-akiya-mpls-entropy-lsp-ping has told the wg chairs that
>>> the draft is ready to be polled to see uf we have support to make it a
>>> working group document.
>>> 
>>> While addressing the last procedures details we will start the the IPR
>>> poll.This mail starts that IPR poll.
>>> 
>>> Are you aware of any IPR that applies to draft-akiya-mpls-entropy- lsp-ping?
>>> 
>>> If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
>>> 3979, 4879, 3669 and 5378 for more details).
>>> 
>>> Currently there are two IPR disclosures that relates to this document.
>>> 
>>> If you are listed as a document author or contributor please respond to this
>>> email regardless of whether or not you are aware of any relevant IPR. *The
>>> response needs to be sent to the MPLS wg mailing list.* The document will
>>> not advance to the next stage until a response has been received from each
>>> author and contributor.
>>> 
>>> If you are on the MPLS WG email list but are not listed as an author or
>>> contributor, then please explicitly respond only if you are aware of any IPR
>>> that has not yet been disclosed in conformance with IETF rules.
>>> 
>>> Thanks, Loa
>>> (as MPLS WG co-chair)
> 
> -- 
> 
> 
> Loa Andersson                        email: loa <at> mail01.huawei.com
> Senior MPLS Expert                          loa <at> pi.nu
> Huawei Technologies (consultant)     phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls


Gmane