Subject: Re: [mpls] [OSPF] ??: ??: WG Last Call for "Signalling ELC using OSPF"

From: <[email-masked]>
Date: Thu, 1 Dec 2016 10:40:34 +0000

Hi Acee,

Thanks for taking the time to read the associated MPLS document https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-04.txt

In my reading, the relevant text is:
“An LSR may have a limitation on the depth of the label stack that it
   can read and process in order to do multipath load balancing.  This
   limitation expressed in terms of the number of label stack entries
   that the LSR can read is defined as the Readable Label Depth (RLD)
   capability of that LSR. »

Which, IMHO, ties the RLD with the load-balancing behavior.

Indeed, it would be good that the authors of the MPLS document clarify this point, because both meanings are possible. You are right that the number of readable label would provide some valuable information. Yet, IMO, the number of read and used labels would be more effective for their goal.
Should we wait for their feedback and their draft update?
That being said, if we agree that the RLD concept is defined in the MPLS document, there is no impact on the OSPF document which would merely defined how this RLD is encoded in OSPF, and normatively defer to the MPLS document for the meaning of this RLD.

Thanks,
-- Bruno

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Wednesday, November 30, 2016 11:53 PM
To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; [email-masked]
Cc: OSPF WG List; Carlos Pignataro (cpignata); [email-masked]; Xuxiaohu
Subject: Re: [OSPF] ??: ??: WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

I haven’t responded to your comments since it required reading https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-04.txt. I’ve now re-read it and I do not agree with you that it restricts RLD to be used for EL load-balancing. While the draft discusses this application, it certain doesn’t restrict usage. I’ve copied the authors explicitly for verification (although they seem to have remained reticent heretofore ;^). The relevant sentence is:

" This limitation expressed in terms of the number of label stack entries

   that the LSR can read is defined as the Readable Label Depth (RLD)

   capability of that LSR."

This sounds pretty generic to me.

Thanks,
Acee

From: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 30, 2016 at 6:33 AM
To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Cc: OSPF WG List <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>, Xiaohu Xu <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OSPF] ??: ??: WG Last Call for "Signalling ELC using OSPF"

Hi Shraddha,

Please see inline [Bruno]

From: Shraddha Hegde [mailto:[email-masked]]  Sent: Sunday, November 27, 2016 2:16 AM

Hi,

Agree with Acee that RLD should be generic and not tied to EL processing and load balancing in Forwarding plane.
It is very much possible that an LSR has policies and  is capable of using ip headers and will load balance on ip headers for MPLS packets
but still advertises RLD.
[Bruno] I agree with you that load balancing is more complex than what is covered by RLD. Yet, although draft-ietf-mpls-spring-entropy-label does not cover the full picture, they have valid use of the RLD as their goal is to add additional EL, ELI in case the label stack is greater than RLD. In such case, the LSR is never capable of load-balancing based on the IP header.
RLD may be tied to load-balancing and still cover the generic case, including your point, with the following definition:
If the label stack is smaller than the RLD, load-balancing is either performed on:
- the IP/encapsulated header
- the EL within the RLD
- all the labels in the RLD.

The issue with not tying RLD to load-balancing behavior, is that some plateform are capable of reading N labels, but will do the load-balancing only based on the _single_ inner label. Such behavior would defeat the RLD usage done by draft-ietf-mpls-spring-entropy-label. And it’s not hypothetical and I can provide real name/example off line  (although AFAIK Juniper Trio does hash using all labels, this is not universal)

Keeping it generic also has the advantage that RLD can be used for future use-cases.
[Bruno] We are advertising a single value hence a single meaning. Either all use cases need this exact meaning and they can share the same IGP advertisement. Or they don’t. As expressed above, if the RLD is not tied to load-balancing behavior, I don’t think that it will be a good fit for draft-ietf-mpls-spring-entropy-label, which has defined it. Plus we don’t know the would-be future use-cases, so it’s hard to discuss about them, and to compromise for them.
To accommodate both points, I’d rather propose that the OSPF document advertise both values/meanings: the generic RLD and the RLD tied to load-balancing behavior. The cost would be minimal (1 octet), especially compared to the TLV encoding overhead (4 octets). Also, future use case may also extend this RLD advertisement latter on, thanks to the TLV extensibility. But this would require that this ospf draft allows it, by allowing a length greater than 1, and defining the RLD to be encoded in the first octet.
Bottom line, there seem to be some options to accommodate all points of view/usage.

Regards,
-- Bruno

Rgds
Shraddha

From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Sunday, November 27, 2016 5:27 AM
To: Xuxiaohu <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: OSPF WG List <[email-masked]<mailto:[email-masked]>>; Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OSPF] 答复: ??: WG Last Call for "Signalling ELC using OSPF"

Although I still think RLD should be generic and not tied to entropy label processing, I’ll relent if this will bring us to consensus.

Thanks,
Acee

From: Xiaohu Xu <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 25, 2016 at 8:05 PM
To: Bruno Decraene <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Subject: 答复: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

发件人:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
发送时间: 2016年11月25日 22:46
收件人: Xuxiaohu; Acee Lindem (acee)
抄送: OSPF WG List; [email-masked]<mailto:[email-masked]>; Carlos Pignataro (cpignata)
主题: RE: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Xiaohu,

Please see inline [Bruno3]

From: Xuxiaohu [mailto:[email-masked]]
Sent: Friday, November 25, 2016 3:20 AM
To: Acee Lindem (acee); DECRAENE Bruno IMT/OLN
Cc: OSPF WG List; [email-masked]<mailto:[email-masked]>; Carlos Pignataro (cpignata)
Subject: ??: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Acee and Bruno,

发件人: Acee Lindem (acee) [mailto:[email-masked]]
发送时间: 2016年11月25日 1:21
收件人:[email-masked]<mailto:[email-masked]>
抄送: OSPF WG List; [email-masked]<mailto:[email-masked]>; Carlos Pignataro (cpignata); Xuxiaohu
主题: Re: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

See inline (I’ve neglected migrating to Outlook 2016 since it won’t do proper reply formatting).

From: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 24, 2016 at 4:57 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, Xiaohu Xu <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Acee

Please see inline [Bruno3]

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Monday, November 21, 2016 6:41 PM
To: DECRAENE Bruno IMT/OLN
Cc: OSPF WG List; [email-masked]<mailto:[email-masked]>; Carlos Pignataro (cpignata); Xuxiaohu
Subject: Re: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

From: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 21, 2016 at 12:21 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, Xiaohu Xu <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Acee,

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Monday, November 21, 2016 6:02 PM
To: DECRAENE Bruno IMT/OLN; Xuxiaohu
Cc: OSPF WG List; [email-masked]<mailto:[email-masked]>; Carlos Pignataro (cpignata)
Subject: Re: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

From: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 21, 2016 at 9:43 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Xiaohu Xu <[email-masked]<mailto:[email-masked]>>
Cc: OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Acee,

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Saturday, November 19, 2016 12:33 AM
To: DECRAENE Bruno IMT/OLN; Xuxiaohu
Cc: OSPF WG List; [email-masked]<mailto:[email-masked]>; Carlos Pignataro (cpignata)
Subject: Re: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

From: OSPF <[email-masked]<mailto:[email-masked]>> on behalf of Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 18, 2016 at 11:30 AM
To: Xiaohu Xu <[email-masked]<mailto:[email-masked]>>
Cc: OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Xiaohu,

Please see inline [Bruno]

From: Xuxiaohu [mailto:[email-masked]]
Sent: Monday, November 14, 2016 1:00 PM
To: DECRAENE Bruno IMT/OLN
Cc: OSPF WG List; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: ??: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

Could you please explain why the defination of the RLDC should be specific to the LB behavior of the transit LSR?

[Bruno] The whole purpose of EL and ELC is to improve load balancing of MPLS packets on transit LSR.

According to §6 of your draft, RLDC is also used to improve load-balancing : “The RLDC is used by ingress LSRs
   to determine whether it's necessary to insert an EL for a given LSP
   tunnel in the case where there has already been at least one EL in
   the label stack. »

What would be the point for the ingress to add an additional EL, within the RLDC of LSR A, if LSR A do not use this EL to improve the load balancing?

cf my example below where a LSR can read 5 labels, yet do not use those 5 labels for the load-balancing hence would not benefit from adding an EL within those 5 labels.

BTW, it would be useful for the discussion if you could reply to the content of my email sent: Monday, November 14, 2016 (also included below). As this was already the second time I send this example on the OSPF mailing list.

If I understand correctly, it seems that the text proposed by you conflict with Acee's take (see blow):

"   1. The standards track IGP drafts should have a precise definition of RLD and so not require a normative reference to the MPLS entropy draft (which is informational). The IGP drafts need not precisely specify how the information is used - this can be specified via a reference to the MPLS draft.
   2. The MPLS draft should precisely specify the initial use case of entropy label insertion at the ingress of the LSP. It should not limit the applicability of RLDC to this use case. "

[Bruno] I’m not seeing any conflict. I agree with both points. In this thread, I’m working on 1, i.e. having a clear definition of RLD.  But I would also like that this RLD advertisement be effective in improving the load-balancing of MPLS packets.

I think Readable Label Depth (RLD) should be independent of EL Capability (ELC). It allows advertisement of the the maximum number of labels an OSPF router will examine in a received MPLS encapsulated packet.
 If an OSPF Router supports ELC, it would imply that it support the EL Capability within RLD labels.
[Bruno] Would work for me, assuming that this is stated in the document, and :s/support the EL Capability within RLD labels/for load-balancing purpose, use the EL within RLD labels.
I would propose the following text: “RLDC is the maximum number of labels, from the top of the stack, where the MPLS transit LSR searches for the ELI,EL pair and load-balance based on the EL if present.”

I would completely decouple the two capabilities. Here is the text I would recommend.

The Readable Label Depth (RLD) is the maximum number of labels, starting with top or first label in the stack, that an LSR can examine in a received MPLS packet.  The supported RLD can be important when searching for an entropy label for purpose of load-balancing as the <ELI, EL> pair must be included in the first RLD labels in the stack.

[Bruno] What would you use this RLD information for?
Current OSPF draft proposes to use it to make a decision on whether/where adding an additional ELI, EL pairs in the stack of labels. But if we don’t know whether that additional EL, within the RLD, will be used for load-balancing purpose, the ingress can’t know whether adding this ELI, EL is useful or not. Since we are in a context where the number of labels that can be pushed is limited, we may be wasting 2 label push for zero benefit.

As the name would imply, Entropy Label Capability (ELC) would be used to determine if the LSR supports load-balancing. The RLD capability, also as as the name would imply, would be used solely to determine the number of labels an LSR will read.
[Bruno3] “read” is one thing but it does not say much about the result/behavior. That’s why I’m calling for “read and use” or “use” for short.

If you want to restrict the capability to the entropy label usage then an appropriate moniker would be the ELRD (Entropy Label Readable Depth). However, I see no reason to restrict it or attempt to tie load balancing to the depth an LSR can read (other than the former is constrained by the latter). The Entropy Label behavior can be fully defined by the Entropy Label Capability (ELC). Please view this in terms of capability modularity without allowing the details of two capabilities to be mix.

[Xiaohu] Concur.

[Bruno3] you concur on “I see no reason to [..] attempt to tie load balancing to the depth an LSR can read”? The draft seems to say otherwise:

- §1 “This capability, referred to
   as Readable Label Deepth Capability (RLDC) can be used by ingress
   LSRs to determine whether it's necessary to insert an EL for a given
   LSP tunnel in the case where there has already been at least one EL
   in the label stack [I-D.ietf-mpls-spring-entropy-label<https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-03#ref-I-D.ietf-mpls-spring-entropy-label>] ”

§6 “The RLDC is used by ingress LSRs
   to determine whether it's necessary to insert an EL for a given LSP
   tunnel in the case where there has already been at least one EL in
   the label stack. »

[Xiaohu1] Is the following updated text OK to you?

5.  Advertising RLDC Using OSPF

   A new TLV within the body of the OSPF RI LSA, called RLDC TLV is
   defined to advertise the capability of the router to read the maximum
   label stack depth.  As showed in Figure 2, it is formatted as
   described in Section 2.3 of [RFC7770] with a Type code to be assigned
   by IANA and a Length of one.  The Value field is set to the maximum
   readable label stack depth in the range between 1 to 255.  The scope
   of the advertisement depends on the application but it is RECOMMENDED
   that it SHOULD be domain-wide.  If a router has multiple linecards
   with different capabilities of reading the maximum label stack
   deepth, the router MUST advertise the smallest one in the RLDC TLV.
   This TLV is applicable to both OSPFv2 and OSPFv3.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type=TBD2           |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     RLD       |
       +-+-+-+-+-+-+-+-+
                          Figure 2: RLDC TLV Format

6.  Usage and Applicability

   The ELC is used by ingress LSRs to determine whether an EL could be
   inserted into a given LSP tunnel.  The RLDC may be used by ingress LSRs
   to determine whether it's necessary to insert an EL for a given LSP
   tunnel in the case where there has already been at least one EL in
   the label stack.  This document only describes how to signal the ELC
   and RLDC using OSPF.  As for how to apply those capabilities when
   inserting EL(s) into LSP tunnel(s), it's outside the scope of this

Xu, et al.               Expires April 21, 2017                 [Page 4]

Internet-Draft          Signalling ELC using OSPF           October 2016

   document and accordingly would be described in
   [I-D.ietf-mpls-spring-entropy-label].

Best regards,
Xiaohu

If this is not what you mean, please update the draft to reflect this. Also note that changing this would significantly impact [I-D.ietf-mpls-spring-entropy-label<https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-03#ref-I-D.ietf-mpls-spring-entropy-label>] because they use the same term RLD to mean something different. And they use it specifically to influence the load-balancing behavior.

Am I the only one who thinks this is obvious?

think ELC should be defined in RFC 6790 and the SPRING Entropy label draft as opposed to the IGP advertisement drafts.
[Bruno] I tend to agree that the definition of RLD, or the load-balancing behavior of a transit LSR supporting EL, would be better specified by the MPLS WG. Then the value advertised by control plane protocols/signaling.
https://tools.ietf.org/html/rfc7325#section-2.4.5 talks about this, but the document is informational, and the text is a bit too large/ open to have the LSR behavior advertised in the IGP using a single integer.
But this option may delay a lot the IGP draft, unless it is splitted in 2 parts (as ELC is ready). Alternatively, I’m ok with your above proposition.

Why can’t we simply use the definition of entropy processing included in RFC 6790 section 4?
[Bruno] Basically, section 4.3 says that the LSR can load-balance based on whatever it wants, and not necessarily based on the EL label. If it does not use the EL label, there is no point in the ingress trying to add additional ELI,EL labels within the RLD of this LSR.

I’d say that a router supporting ELC recognizes the <ELI, EL> label in the first RLD labels and MAY load-balance as described in RFC 6790. An OSPF document should not update the MPLS data plane behavior.
[Bruno3] I agree that an OSPF document should not update the MPLS data plane behavior. ELC is defined in RFC 6790 as the capability of the egress (of the LSP/segment). It does not advertise any transit capability.
(Now we could argue that a sensible implementation would implement both features at the same time, but I would not a priori bet on this for all implementation, especially since those are two different forwarding plane capabilities and some hardware could be able to do one and not the other)

I get it that you want an LSR capability that indicates that it MUST load-balance based on an entropy label within the first RLD labels. However, shouldn’t this forwarding plane behavior be defined in MPLS rather than the IGPs? If the MPLS WG won’t engage in this definition, perhaps this should be defined in https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-04.txt – I believe you have some leverage here  ;^) and it certainly isn’t within the charter of the OSPF or ISIS WGs.

[Xiaohu] Agree. As per RFC6790, the ingress of a given LSP doesn’t know whether or not intermediate LSRs along that LSP could perform EL-based load-balancing when inserting EL/ELI under that LSP. The ingress just “assumes” that all or partial intermediate LSRs could perform EL-based LB.

[Bruno3] No. RFC 6790 makes no assumption on transit LSR behavior. e.g. “Transit LSRs MAY operate with no change in forwarding behavior.”

And there is no issue with RFC 6790. The issue is related to the RLD usage made by [I-D.ietf-mpls-spring-entropy-label<https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-03#ref-I-D.ietf-mpls-spring-entropy-label>]

--Bruno

When you look the stacked LSP tunnel in the MPLS SR case as a stack of LSPs that share the same ingress, things become much simpler. The principles used in RFC6790 should be applicable to the MPLS-SR case as well. That’s to say, the ingress of a given tier LSP (i.e., a node segment) within the stacked LSP tunnel just needs to assume that all or partial intermediate LSRs could perform EL-based LB as well. More specially, there is no need for the ingress to “know” whether intermediate LSRs are capable of performing EL-based LB. Even assume that the ingress of a given LSP knows that some intermediate LSRs of that LSP don’t support EL-based LB, should it insert EL/ELI or not?

Best regards,
Xiaohu

Which is the purpose of advertising the RLD (AFAIK).

It is one usage of RLD – however, the maximum number of labels an LSR can examine must not be inextricably tied to the Entropy Label processing.
[Bruno3] It’s currently the only usage, so I’d rather have the RLD useful for this usage. If there are more usages, we may take them into account. But there is not free lunch: if we want to advertise 2 (slightly) different thing, we’ll need to advertise two capabilities)

Why doesn’t this work?

   1. The RLD defines the maximum number of labels that an MPLS LSR is able to read.
   2. The ELC defines an MPLS LSR's Entropy Label load-balancing and entropy label popping capabilities with the constraint that the LSR will only look at the first RLD labels.

Happy Thanksgiving,
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 1 Dec 2016 11:14:49 +0000

Hi Acee, authors,

While I don't disagree with Acee's note, what other uses are there for the having this RLD variable (labels that an intermediate LSR can "read") besides LB?

By the way, RFC 3031 mentions a "label reader" with a much different meaning than here. Curious: is "label read" defined somewhere?

Thanks,

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Nov 30, 2016, at 17:53, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bruno,

Thanks,
Acee

Hi Shraddha,

Hi,

Regards,
-- Bruno

Rgds
Shraddha

Thanks,
Acee

Hi Bruno,

Hi Xiaohu,

Hi Acee and Bruno,

Hi Bruno,

Hi Acee

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

[Xiaohu] Concur.

        0                   1                   2                   3

Best regards,
Xiaohu

--Bruno

Best regards,
Xiaohu

Why doesn’t this work?

Happy Thanksgiving,
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 1 Dec 2016 13:03:58 +0000

Hi Carlos,

Although it is a subtle point, what bothers me is the semantics of the RLD and ELC. Why should Readable Label Depth (RLD) have anything to do with load-balancing? Once RLD labels have been read, why should RLD imply how this information is used? If we are going to inextricably tie RLD to the EL load-balancing capability, we don’t even need ELC (Entropy Label Capability) - it is redundant.

Thanks,
Acee

From: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 1, 2016 at 6:14 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Bruno Decraene <[email-masked]<mailto:[email-masked]>>, Shraddha Hegde <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Xiaohu Xu <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] ??: ??: WG Last Call for "Signalling ELC using OSPF"

Hi Acee, authors,

Thanks,

Hi Bruno,

Thanks,
Acee

Hi Shraddha,

Hi,

Regards,
-- Bruno

Rgds
Shraddha

Thanks,
Acee

Hi Bruno,

Hi Xiaohu,

Hi Acee and Bruno,

Hi Bruno,

Hi Acee

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

[Xiaohu] Concur.

        0                   1                   2                   3

Best regards,
Xiaohu

--Bruno

Best regards,
Xiaohu

Why doesn’t this work?

Happy Thanksgiving,
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 1 Dec 2016 22:02:05 +0000

I received some additional information offline from Bruno. Based on that, I have a suggestion for the base entropy label draft. We do need two capabilities:

  Entropy Label Capability (ELC) – This is same egress LSR capability that is described in section 4.1 of RFC 6790. It should stay to be compatible with the capabilities advertised in the MPLS protocols.

  Entropy Label Load-balancing Capability ELLC) - This indicates that a transit LSR is able to load based on an <ELI, EL> tuple. The ELLC will include mandatory one-octet Load-balancing Label Depth (LLD) that it specifies the maximum number of labels the LSR will examine to find an <ELI, EL> tuple. The range will be 2-255 since an LSR must be able to use the top two labels. I think since the SPRING draft is defining this, we could indicate that an LSR advertising this capability WILL load-balance (as opposed the MAY in section 4.3 of RFC 6790) - however, this is up for debate.

Thoughts? Note that I realize the above could be refined. I’m just trying to clean up the semantics.

Thanks,
Acee

From: mpls <[email-masked]<mailto:[email-masked]>> on behalf of Acee Lindem <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 1, 2016 at 8:03 AM
To: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>, Shraddha Hegde <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] [OSPF] ??: ??: WG Last Call for "Signalling ELC using OSPF"

Hi Carlos,

Thanks,
Acee

Hi Acee, authors,

Thanks,

Hi Bruno,

Thanks,
Acee

Hi Shraddha,

Hi,

Regards,
-- Bruno

Rgds
Shraddha

Thanks,
Acee

Hi Bruno,

Hi Xiaohu,

Hi Acee and Bruno,

Hi Bruno,

Hi Acee

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

[Xiaohu] Concur.

        0                   1                   2                   3

Best regards,
Xiaohu

--Bruno

Best regards,
Xiaohu

Why doesn’t this work?

Happy Thanksgiving,
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 2 Dec 2016 09:08:49 +0000

Looks clear and good to me.

Thanks.

Bruno

PS: For extra clarity, by « SPRING draft”  I assume that you are referring to draft-ietf-mpls-spring-entropy-label (which some could call it a MPLS draft ;-) )

From: mpls [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Thursday, December 01, 2016 11:02 PM
To: Acee Lindem (acee); Carlos Pignataro (cpignata)
Cc: [email-masked]; [email-masked]; Shraddha Hegde; OSPF WG List
Subject: Re: [mpls] [OSPF] ??: ??: WG Last Call for "Signalling ELC using OSPF"

Thanks,
Acee

Hi Carlos,

Thanks,
Acee

Hi Acee, authors,

Thanks,

   capability of that LSR."

Thanks,
Acee

Hi Shraddha,

Hi,

Regards,
-- Bruno

Rgds
Shraddha

Thanks,
Acee

Hi Bruno,

Hi Xiaohu,

Hi Acee and Bruno,

Hi Bruno,

Hi Acee

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

[Xiaohu] Concur.

        0                   1                   2                   3

Best regards,
Xiaohu

--Bruno

Best regards,
Xiaohu

Why doesn’t this work?

Happy Thanksgiving,
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 3 Dec 2016 04:34:43 +0000

Hi, Acee,

Exactly — this is a much more semantically useful distinction.

However, please see inline.

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Dec 1, 2016, at 5:02 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Yes, with the clarification that “Egress LSR” respect to the specific segment / LSE.

  Entropy Label Load-balancing Capability ELLC) - This indicates that a transit LSR is able to load based on an <ELI, EL> tuple. The ELLC will include mandatory one-octet Load-balancing Label Depth (LLD) that it specifies the maximum number of labels the LSR will examine to find an <ELI, EL> tuple. The range will be 2

It cannot be 2, because that would imply ELI; EL at the top of the stack, which in turn means this was the advertising node (Termination and not Transit) using PHP.

-255

The one-octet imposes a limitation not present in spring-sr-mpls.

since an LSR must be able to use the top two labels. I think since the SPRING draft is defining this, we could indicate that an LSR advertising this capability WILL load-balance (as opposed the MAY in section 4.3 of RFC 6790) - however, this is up for debate.

If this is a “Capability”, it probably implies a “I can do this”, not “I must do this”.

The doc still needs many next-level clarifications — and a strong dependency on [I-D.ietf-mpls-spring-entropy-label].

Thanks,
Acee

Thanks!

— Carlos.

Hi Carlos,

Thanks,
Acee

Hi Acee, authors,

Thanks,

Hi Bruno,

Thanks,
Acee

Hi Shraddha,

Hi,

Regards,
-- Bruno

Rgds
Shraddha

Thanks,
Acee

Hi Bruno,

Hi Xiaohu,

Hi Acee and Bruno,

Hi Bruno,

Hi Acee

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

[Xiaohu] Concur.

        0                   1                   2                   3

Best regards,
Xiaohu

--Bruno

Best regards,
Xiaohu

Why doesn’t this work?

Happy Thanksgiving,
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 3 Dec 2016 18:21:17 +0000

Hi Carlos,

Actually, I now believe that we should wait for the MPLS draft to be WG last called before WG last calling the IGP drafts. I think this exercise was beneficial since both Bruno, myself, Shraddha, and others to really think about the requirements.  See inline.

Date: Friday, December 2, 2016 at 11:34 PM

Hi, Acee,

—

Ok – I guess this is covered by ELC. It seems that the egress LSR is anyplace a label terminates and is popped.

-255

I’m fine with with a larger field.

Bruno had commented that it would be advantageous for the ingress LSR or controller to know whether inserting <ELI, EL> would be beneficial. Hence, something stronger than “MAY” may be appropriate.

As I stated previously, I now think I-D.ietf-mpls-string-entropy-label should precede the IGP drafts.

Thanks,
Acee

Thanks,
Acee

Thanks!

— Carlos.

Hi Carlos,

Thanks,
Acee

Hi Acee, authors,

Thanks,

Hi Bruno,

Thanks,
Acee

Hi Shraddha,

Hi,

Regards,
-- Bruno

Rgds
Shraddha

Thanks,
Acee

Hi Bruno,

Hi Xiaohu,

Hi Acee and Bruno,

Hi Bruno,

Hi Acee

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

[Xiaohu] Concur.

        0                   1                   2                   3

Best regards,
Xiaohu

--Bruno

Best regards,
Xiaohu

Why doesn’t this work?

Happy Thanksgiving,
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 3 Dec 2016 20:06:46 +0000

We are aligned.

Just one comment inline

—

On Dec 3, 2016, at 1:21 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

Hi, Acee,

—

-255

I agree. More than MAY but certainly less than MUST. A strong desire to use it :-)

C.

Thanks,
Acee

Thanks,
Acee

Thanks!

— Carlos.

Hi Carlos,

Thanks,
Acee

Hi Acee, authors,

Thanks,

Hi Bruno,

Thanks,
Acee

Hi Shraddha,

Hi,

Regards,
-- Bruno

Rgds
Shraddha

Thanks,
Acee

Hi Bruno,

Hi Xiaohu,

Hi Acee and Bruno,

Hi Bruno,

Hi Acee

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

[Xiaohu] Concur.

        0                   1                   2                   3

Best regards,
Xiaohu

--Bruno

Best regards,
Xiaohu

Why doesn’t this work?

Happy Thanksgiving,
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 5 Dec 2016 08:44:01 +0000

Hi All,

I have a few comments/concerns on the draft-ietf-mpls-spring-entropy-label draft and since the relevant
audience is in the thread I’ll raise it here.

1.       The draft does not clearly specify that the <ELI, EL> should be inserted  such that it does not
Get exposed on a node that does not understand <ELI, EL>. This should be specified in section 4.

2.       When there is protection enabled in the network via TI-LFA/R-LFA it is possible that the stack depth

Changes with additional labels getting imposed on an intermediate node. There is also possible that in case

of failures traffic follows a different path and  <ELI, EL> gets exposed at a node that does not understand it.

This aspect should be clearly brought out in the draft.

3.       In case of anycast-sids, multiple nodes advertise the same prefix and sid and traffic follows the shortest path.

If all the nodes in the anycast group are not EL capable, then care should be taken not to expose the <ELI,EL>

At the top of the stack on these nodes.

Rgds

Shraddha

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Sunday, December 4, 2016 1:37 AM
To: Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]; OSPF WG List <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked]
Subject: Re: [mpls] [OSPF] ??: ??: WG Last Call for "Signalling ELC using OSPF"

We are aligned.

Just one comment inline

—

Hi Carlos,

Hi, Acee,

—

-255

C.

Thanks,
Acee

Thanks,
Acee

Thanks!

— Carlos.

Hi Carlos,

Thanks,
Acee

Hi Acee, authors,

Thanks,

   capability of that LSR."

Thanks,
Acee

Hi Shraddha,

Hi,

Regards,
-- Bruno

Rgds
Shraddha

Thanks,
Acee

Hi Bruno,

Hi Xiaohu,

Hi Acee and Bruno,

Hi Bruno,

Hi Acee

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

[Xiaohu] Concur.

        0                   1                   2                   3

Best regards,
Xiaohu

--Bruno

Best regards,
Xiaohu

Why doesn’t this work?

Happy Thanksgiving,
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 6 Dec 2016 03:43:44 +0000

Hi Shraddha,

Thanks for raising the following concerns.

In fact, the EL insertion decision process on the ingress would become much complex when taking the RLD into account. For example, should the RLD of those LSRs that are not along the LSP be considered? If not, the EL insertion decision process should know the real path of the LSP and adjust the EL insertion decision once the path of that LSP is changed due to whatever reason (e.g., topology change). In addition, in the case of hierarchical LSP tunnel, the ingress should calculate the shortest path from each node segment to its next node segment so as to determine the real path of a given LSP of the hierarchy. More badly, it becomes impossible to do the above path computation in the inter-area case since the topology of one area is not visible to a node within another area.

Best regards,
Xiaohu

发件人: mpls [mailto:[email-masked]] 代表 Shraddha Hegde
发送时间: 2016年12月5日 16:44
收件人: Carlos Pignataro (cpignata); Acee Lindem (acee)
抄送: [email-masked]; [email-masked]; OSPF WG List
主题: Re: [mpls] [OSPF] ??: ??: WG Last Call for "Signalling ELC using OSPF"

Hi All,

Rgds

Shraddha

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Sunday, December 4, 2016 1:37 AM
To: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; OSPF WG List <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] [OSPF] ??: ??: WG Last Call for "Signalling ELC using OSPF"

We are aligned.

Just one comment inline

—

Hi Carlos,

Hi, Acee,

—

-255

C.

Thanks,
Acee

Thanks,
Acee

Thanks!

— Carlos.

Hi Carlos,

Thanks,
Acee

Hi Acee, authors,

Thanks,

   capability of that LSR."

Thanks,
Acee

Hi Shraddha,

Hi,

Regards,
-- Bruno

Rgds
Shraddha

Thanks,
Acee

Hi Bruno,

Hi Xiaohu,

Hi Acee and Bruno,

Hi Bruno,

Hi Acee

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

[Xiaohu] Concur.

        0                   1                   2                   3

Best regards,
Xiaohu

--Bruno

Best regards,
Xiaohu

Why doesn’t this work?

Happy Thanksgiving,
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.