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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 5 Nov 2016 16:45:59 +0000

This begins the WG last call for  "Signalling ELC using OSPF”, https://www.ietf.org/id/draft-ietf-ospf-mpls-elc-03.txt. Please review the document and send comments to this list prior to Nov 27th, 2016. Due to the IETF week, the last call period is going to be 3 weeks rather than usual 2 weeks.

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 5 Nov 2016 16:49:48 +0000

Draft Authors,

Please confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Each authors should respond explicitly to this list.

Thanks,
Acee

P.S. I realize some of you have already done this earlier in the process, and I appreciate your willingness to do it again.

From: OSPF <[email-masked]<mailto:[email-masked]>> on behalf of Acee Lindem <[email-masked]<mailto:[email-masked]>>
Date: Saturday, November 5, 2016 at 12:45 PM
To: OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Thanks,
Acee

---

From: <[email-masked]>
Date: Mon, 7 Nov 2016 10:43:55 +0000

Hi authors, all,

Please find below some comments on the RLDC definition.

1) I’d like to see a more specific definition of RLDC.
e.g. load-balancing hashing could be done based on (hashing):
-a- a (stack of) N  “regular” MPLS labels (i.e. there is no ELI in this stack)
-b- the (IP) header below the stack of N  labels
-c- the EL label in the stack of N labels (i.e. there is one ELI in this stack)

I’d like the specification to be clear on the applicability of the RLDC. Does it apply on these 3 cases, on only a subset?
Personally, I’d like at least a and c be in scope of the RLDC definition, such that an ingress with limited push capability could have enough information to decide that it could avoid pushing an ELI,EL pair if the stack of MPLS labels that it pushes has enough entropy within the first RLDC labels.

2) Current text seems to limit the use of the RLDC to the insertion of a _second_ EL. Why is the RLD not applicable to the first EL?

§1.  Introduction

“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 Usage and Applicability

“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. »

I think that this is an unnecessary restriction of the RLDC usage. Indeed, an ingress with a limited capability in term of label push, could be forced to push a single EL label. It should be able to use the RLDC info in order to choose the best location for the EL, even if it pushes a single one.
But both sentences seems to restrict RLDC usage for the additional EL push, not the first one.

Thanks,
Regards,
--Bruno

From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Saturday, November 05, 2016 5:46 PM
To: OSPF WG List
Subject: [OSPF] WG Last Call for "Signalling ELC using OSPF"

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 8 Nov 2016 01:26:42 +0000

Hi Bruno,

From: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 7, 2016 at 6:43 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi authors, all,

I think that the signaling document should reference section 4 of https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-04.txt. However, I don’t think -b- is covered there.

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 8 Nov 2016 02:33:55 +0000

Hi Acee and Bruno,

Thanks for your comments. Please see my response inline.

发件人: OSPF [mailto:[email-masked]] 代表 Acee Lindem (acee)
发送时间: 2016年11月8日 9:27
收件人: [email-masked]; OSPF WG List
主题: Re: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

Hi authors, all,

[Xiaohu] The RLDC is only applicable to c, as it had been stated in section 6 (see below).

   the label stack.

§1.  Introduction

   the label stack. »

I would tend to agree.

[Xiaohu] I agree that the goal (i.e., use the RLDC info in order to choose the best location for the EL, even if it pushes a single one.) is perfect. And it seems in align with the second of the recommendations for inserting EL pairs

   o  An LSR that is limited in the number of <ELI, EL> pairs that it
      can insert SHOULD insert such pairs deeper in the stack.

   o  An LSR SHOULD try to insert <ELI, EL> pairs at positions so that
      for the maximum number of transit LSRs, the EL occurs within the
      RLD of the incoming packet to that LSR.

   o  An LSR SHOULD try to insert the minimum number of such pairs while
      trying to satisfy the above criteria.

However, it would make the EL insertion decision process on the ingress much complex. For instance, the ingress need to determine the total number of transit LSRs within each LSP hierarchy when that LSP is the outermost one. In fact, the EL insertion decision process in the recommended solution as described in section 4 of https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-04.txt has  already been a bit complex. For instance, the ingress needs to determine the minimum of the RLDs of transit LSRs of each LSP hierarchy when that LSP is the outermost one. How to do that in the inter-area/inter-level scenario? IMHO, the most practice way is to insert a single EL under the innermost LSP☺

Best regards,
Xiaohu

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

---

From: <[email-masked]>
Date: Tue, 8 Nov 2016 11:15:47 +0000

Hi Xiaohu,

Thanks for your reply.
Please see inline [Bruno]

In short, I insist on the need to have a specific definition of what “RLD” (or RLDC depending on the draft…) means.
- From a general standpoint, this is required for interop of even usage of this information. Then on this specific case, unfortunately, from the discussion, it seems that different person have a different understanding of it, so we may have a bigger problem.
- And we may have a bigger problem as the EL spec allow many (all) behavior on the transit LSR. https://tools.ietf.org/html/rfc6790#section-4.3  e.g. the EL may not be used if the LSR is capable of parsing the inner packet (IP header), in which case this is useless to add an (additional) EL,ELI pair, especially if the ingress is limited in the number of labels that it can push. (hence the problem is even bigger for draft-ietf-mpls-spring-entropy-label-04.txt which tries to make a decision based on the RLDC advertisement (which currently is loosely defined) and the LSR transit behavior (which is just unknown/unspecified)…
- This is a pre-requisite to even discuss the draft. (well, I mean the second half of this draft related to the RDLC TLV (type TBD2).

From: Xuxiaohu [mailto:[email-masked]]
Sent: Tuesday, November 08, 2016 3:34 AM
To: Acee Lindem (acee); DECRAENE Bruno IMT/OLN; OSPF WG List
Subject: ??: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi Acee and Bruno,

发件人: OSPF [mailto:[email-masked]] 代表 Acee Lindem (acee)
发送时间: 2016年11月8日 9:27
收件人: [email-masked]<mailto:[email-masked]>; OSPF WG List
主题: Re: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

Hi authors, all,

[Xiaohu] The RLDC is only applicable to c, as it had been stated in section 6 (see below).
[Bruno] I don’t think that this is good enough. The goal of RLD/RLDC is to give the ingress node, additional knowledge on the capability on the load-balancing of downstream LSR, in order to be able to take an informed decision with regard to the placement of EL labels. Knowing “a” seems useful to me. So if you don’t want RLD to apply to “a”, then I’d like the draft to be extended to also be able to advertise the RLD for the “a” case. IOW, in TLV=TBD2, allow the advertisement of both RLD for EL an RLD for stack of regular labels.
Note that in the general case, case “a” is a bit more complex as some implementations are limited to do the hashing on a range of inner labels e.g. labels 5 to label 9, so in order to accurately reflect this, we would need to advertise this range. At which point we could also advertise the “b” case, since if the MPLS encapsulated protocol is IP, some implementation will have a different behavior and load balance based on the IP header.
So the problem is not very easy and some trade-off may be involved. But we need to clearly define the meaning of the RLD advertisement, otherwise it’s either useless or misleading.
Note that even if the document is restricted to the case “c”, the behavior needs to be clear for IP traffic. Indeed, some hardware may do the LB based on the IP header, even if a ELI is present in the label stack. In which case, there may be an incentive for the ingress to push more labels, in order to “hide” the IP header and allow the EL to be used. (as the EL could provide more entropy than the IP header, e.g. if the IP header is from an IP tunnel). And given that the EL spec roughly opens all possibly option for the transit LSR behavior, https://tools.ietf.org/html/rfc6790#section-4.3 it looks like much more work is needed.

   the label stack.

§1.  Introduction

   the label stack. »

I would tend to agree.

[Xiaohu] I agree that the goal (i.e., use the RLDC info in order to choose the best location for the EL, even if it pushes a single one.) is perfect.
[Bruno] Good.

And it seems in align with the second of the recommendations for inserting EL pairs

[Bruno] Your text is quoted from a different draft. This is not the one that I’m commented on. IOW, "Signalling ELC using OSPF" is about the signaling of information. Not how it is used.
That being said, if we can’t agree on the exact meaning of RLD, draft-ietf-mpls-spring-entropy-label becomes somewhat useless. (e.g. LSR LB based on the IP header, so don’t care about the EL)

Best regards,
Xiaohu

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

---

From: <[email-masked]>
Date: Tue, 8 Nov 2016 11:15:48 +0000

Hi Acee,

Thanks for your reply. Please see inline [Bruno]

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Tuesday, November 08, 2016 2:27 AM
To: DECRAENE Bruno IMT/OLN; OSPF WG List
Subject: Re: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

Hi authors, all,

I think that the signaling document should reference section 4 of https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-04.txt. However, I don’t think -b- is covered there.
[Bruno] The above section 4 has indeed more details, but I’m not certain that the definition is clear enough for everyone to agree on which “a”, “b”, “c” cases are covered by the RLDC advertisement. My reading would be that “a” and “c” are covered, not “b”. Reading your email, I’d say that you have the same understanding. But it bothers me that one of the authors has a different understanding.
Also draft-ietf-mpls-spring-entropy-label-04.txt is an informational document, so I’m not sure how much it would qualify to be a normative definition of what draft-ietf-ospf-mpls-elc advertise.

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 8 Nov 2016 12:02:23 +0000

Hi Bruno,

From: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 8, 2016 at 7:15 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi Acee,

Hi Bruno,

Hi authors, all,

I think that the signaling document should reference section 4 of https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-04.txt. However, I don’t think -b- is covered there.
[Bruno] The above section 4 has indeed more details, but I’m not certain that the definition is clear enough for everyone to agree on which “a”, “b”, “c” cases are covered by the RLDC advertisement. My reading would be that “a” and “c” are covered, not “b”. Reading your email, I’d say that you have the same understanding. But it bothers me that one of the authors has a different understanding.
Alsodraft-ietf-mpls-spring-entropy-label-04.txt is an informational document, so I’m not sure how much it would qualify to be a normative definition of what draft-ietf-ospf-mpls-elc advertise.

Ok - the document could define the use cases it specifically handles without limiting usage of the RLD capability.

Thanks,
Acee

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 8 Nov 2016 15:20:25 +0000

Jumping a bit mid-thread, but with somewhat similar or related comments.

Summary: I am concerned with the lack of precision in the definitions and usage on these set of documents.

Acee, if this document needs to depend on Section 4 of draft-ietf-mpls-spring-entropy-label-04.txt, then the issue is compounded. I believe draft-ietf-mpls-spring-entropy-label-04has its own set of problems (for example, placing EL/ELI independent of whether the underlying Label is for a Node SID or a Segment SID is not optimum).

So the main question is: Is draft-ietf-ospf-mpls-elc-03 to be treated independently form draft-ietf-mpls-spring-entropy-label-04? That is a fundamental question for advancing and reviewing this/these doc(s). We have the advertisement of a capability — what is it used for? Is it the right variable to advertise (based on the application using it)?

Specifically, I think that RLDC is largely underspecified. The doc says:
"
   it would be useful for ingress LSRs to know each LSR's capability of
   reading the maximum label stack deepth.  This capability, referred to
   as Readable Label Deepth Capability (RLDC)
“

That definition simple does not make sense. And it does not explain the applicability (A, b, c, d).

Then the doc continues:
“
   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] .
"

So this only is useful when there’s an EL (I assume ELI/EL pair) already?

And is “[I-D.ietf-mpls-spring-entropy-label]” normative?

Overall, I think a WGLC is premature, since some basics are not well covered. Is it RLD or RLDC? And what exactly is a “Readable Label Deepth Capability (RLDC)” The capability to do what? Is this a Capability or a scalar?

Another point comment — although I think this needs a thorough review before WGLC.

The doc says:
   Of course,
   even it has been determined that it's neccessary to insert an EL for
   a given LSP tunnel, if the egress LSR of that LSP tunnel has not yet
   indicated that it can process ELs for that tunnel, the ingress LSR
   MUST NOT include an entropy label for that tunnel as well.

This is good and consistent with RFC 6790:
   c.  X MUST NOT include an entropy label for a given tunnel unless the
       egress LSR Y has indicated that it can process entropy labels for
       that tunnel.

So it’s better to point to it instead of re-MUST NOT independently.

But, what is the egress of a tunnel in this context? Not the final egress, but the SID egress. ?

Thanks,

—
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 Nov 8, 2016, at 6:15 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 8 Nov 2016 21:47:47 +0000

Hi Carlos,
I’ll wait for the authors to respond on the precise definition for RLDC.  Perhaps, my impression of https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-04.txt being cooked is incorrect.
Thanks,
Acee

From: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 8, 2016 at 10:20 AM
To: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Then the doc continues:
“

The doc says:
   Of course,

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

---

From: <[email-masked]>
Date: Wed, 9 Nov 2016 14:46:11 +0000

Hi Carlos,

We are preparing a new version of draft-ietf-mpls-spring-entropy-label taking into account more parameters in EL/EL placement. It was too short to post it before cut-off.

Brgds,

From: OSPF [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Tuesday, November 08, 2016 16:20
To: DECRAENE Bruno IMT/OLN
Cc: OSPF WG List
Subject: Re: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Then the doc continues:
“

The doc says:
   Of course,

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 10 Nov 2016 04:29:21 +0000

Hi Carlos,

发件人: OSPF [mailto:[email-masked]] 代表 Carlos Pignataro (cpignata)
发送时间: 2016年11月8日 23:20
收件人: Bruno Decraene
抄送: OSPF WG List
主题: Re: [OSPF] WG Last Call for "Signalling ELC using OSPF"

[Xiaohu] draft-ietf-ospf-mpls-elc-03 defines an approach of advertising the RLDC of an LSR via OSPF. The definition of the RLDC is described in the following text (i.e., each LSR's capability of reading the maximum label stack depth). As for how to use this capability, it’s not limited by the draft although one use case (i.e., the application as described in Section 4 of draft-ietf-mpls-spring-entropy-label-04.txt) is mentioned in this draft.

[Xiaohu]Could you speak more specifically? Is the definition of the RLDC (i.e., what is the capability of reading the maximum label stack depth) itself not clear enough? If so, could you please suggestion any more specific text? Or the applicability of the RLDC not clear enough? If so, we co-authors currently only think about one use case of this RLDC that is described in Section 4 of draft-ietf-mpls-spring-entropy-label-04.txt) , please feel free to tell us if you find any other use cases of this RLDC.

Then the doc continues:
“

[Xiaohu] In the EL insertion use case, yes, your understand is correct.

[Xiaohu] Currently yes, if it’s widely believed that this reference should be informational, it can be moved to the informational reference section.

[Xiaohu] RLDC (Readable Label Deeth Capability) means a given LSR's capability of reading the maximum label stack depth. If it’s widely believed that “RLD” is more suitable than “RLDC” from the expression perspective, it’s fine to make a change.

The doc says:
   Of course,

[Xiaohu] Good suggestion. Will fix it.

[Xiaohu] IMHO, the egress of an LSP tunnel is clear enough and easy to understand. In contrast, what’s the mean of SID egress, could you please help point to a reference for this term defincation?

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 10 Nov 2016 08:56:25 +0000

Hi all,

(Hopefully) For the benefit of the discussion, I’m sharing a real world MPLS (transit LSR) load balancing algo on one plateform:

Label <=3: 2-tuple <source IP(rightmost 30bit), destination IP (rightmost 30bit)>
Label = 4: bottom-of-stack label (rightmost 20bit)
Label>=5: Fifth(rightmost 20bit) label from the top

This is a more or less random pick, and in general the behaviors are very diverse depending on the plateform (router, line card, os version, MPLS encapsulated traffic).

In general, it’s not clear to me how the RLDC advertisement really helps the ingress to make an informed decision and improve the load balancing of its flow across the MPLS network, as the current advertisement seems a bit simplistic to me.
More specifically, with the current definition of the RLDC, it’s hard for me to guess which RLDC value should be advertised. So I would really expect interop issues and endless discussion about who is right.

Thanks,
Regards,
-- Bruno

From: Xuxiaohu [mailto:[email-masked]]
Sent: Thursday, November 10, 2016 5:29 AM
To: Carlos Pignataro (cpignata); DECRAENE Bruno IMT/OLN
Cc: OSPF WG List
Subject: ??: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 10 Nov 2016 09:57:41 +0000

Hi Bruno,

Thanks for sharing the following information. However, it seems that it has nothing to do with the EL-based MPLS load-balancing mechanism. The ELC and RLDC as described in draft-ietf-ospf-mpls-elc are applicable to the EL-based MPLS load-balancing mechanism.

Best regards,
Xiaohu

发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2016年11月10日 16:56
收件人: Xuxiaohu
抄送: OSPF WG List; Carlos Pignataro (cpignata)
主题: RE: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 10 Nov 2016 13:29:12 +0000

Hi, Xiaohu,

Please see inline.

—

On Nov 9, 2016, at 11:29 PM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

[Xiaohu] draft-ietf-ospf-mpls-elc-03 defines an approach of advertising the RLDC of an LSR via OSPF. The definition of the RLDC is described in the following text (i.e., each LSR's capability of reading the maximum label stack depth).

To me “LSR's capability of reading the maximum label stack depth” does not mean “the value of LSEs that an LSR can read in an MPLS label stack”...

As for how to use this capability, it’s not limited by the draft although one use case (i.e., the application as described in Section 4 of draft-ietf-mpls-spring-entropy-label-04.txt) is mentioned in this draft.

[Xiaohu]Could you speak more specifically? Is the definition of the RLDC (i.e., what is the capability of reading the maximum label stack depth) itself not clear enough?

It is not fully clear to me. Maybe it is just me. What is the “capability of reading the maximum label stack deepth”?

A capability to me is a binary state. Yes, capable, not capable. What is the “maximum label stack depth”?

But it’s not just grammar. From the definition in RFC 3031:

https://tools.ietf.org/html/rfc3031#section-3.9

   If a packet's label stack is of depth m, we refer to the label at the
   bottom of the stack as the level 1 label, to the label above it (if
   such exists) as the level 2 label, and to the label at the top of the
   stack as the level m label.

Which means the bottom is label 1, the minimum not the maximum.

If so, could you please suggestion any more specific text? Or the applicability of the RLDC not clear enough? If so, we co-authors currently only think about one use case of this RLDC that is described in Section 4 of draft-ietf-mpls-spring-entropy-label-04.txt) , please feel free to tell us if you find any other use cases of this RLDC.

No, Xiaohu. That thinking is the other way around.

You are defining something independent of the use case. Your definition is generic and outside the use of SPRING. It is independent of SR.

And yes, the applicability is not clear enough — since it is beyond (and independent of) SR, but dependent of LB techniques, maybe?

Then the doc continues:
“

What’s another use case?

It is informational now!!!

Should it be Normative?

[Xiaohu] RLDC (Readable Label Deeth Capability) means a given LSR's capability of reading the maximum label stack depth.

What is “the maximum label stack depth”?

If it’s widely believed that “RLD” is more suitable than “RLDC” from the expression perspective, it’s fine to make a change.

I’m not sure what’s widely believed. What I believe is that calling something RLD in some place, and RLDC in others is not useful.

Further, I think that the way this is defined is a per-advertisement value. However, in your other draft on mpls-spring-EL, you use the same definition to mean something else, to be per path or per network.

Which one is it?

The doc says:
   Of course,

That’s my point — most terms are not defined.

Thanks,

— Carlos.

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 10 Nov 2016 13:31:07 +0000

Hi Xuxiaohu,

The RLDC specification(s) needs to be clear enough such that:
- transit LSR knows what to advertise
- ingress LSR knows how to use it in order to achieve/optimize load balancing across the MPLS network.

So let’s start with the first question: which RLDC value should be advertised by such transit LSR? (cf below) And please quote the text from the RDLC spec which supports the answer.

> However, it seems that it has nothing to do with the EL-based MPLS load-balancing mechanism.

AFAIK, EL is defined in RFC6790, which defines a new behavior on the egress and ingress. It does not standardize the load-balancing behavior on transit nodes which are mostly free to do any load-balancing behavior. So it looks like hard to define an IGP TLV to advertise this non-standardized behavior, which is largely independent of the EL specification. IOW to re-use your terms, there is no such EL-based MPLS load-balancing specification for transit LSR.
https://tools.ietf.org/html/rfc6790#section-4.3
Now, we (MPLS WG) can try to model the load-balancing behavior of MPLS LSR, so that we (IGP WG) can latter advertise the parameters of this model in the IGP. But from what I can see in existing product, the current RLDC seems insufficient to model the behavior of existing MPLS LSR.
The current RLDC advertisement seems to be able to model a very small subset: a transit LSR which recognizes the ELI, and load balance solely on the following label (the EL).
If so,
- this need to be clear in the RLDC specification, because currently this is not.
- this may be seen as an incremental improvement but I don’t believe that it really solves the problem, nor significantly improve it given the behavior of existing plateform.

I’d rather have a solution which is more generally applicable and provide a significant improvement. i.e. model the load-balancing behavior of most current and future MPLS LSR, and then advertise the parameters in the IGP. (including a model ID such that this can be improved in the future). I agree that this is more complex job.

Thanks,
Best regards,
Bruno

From: Xuxiaohu [mailto:[email-masked]]
Sent: Thursday, November 10, 2016 10:58 AM
To: DECRAENE Bruno IMT/OLN
Cc: OSPF WG List; Carlos Pignataro (cpignata); [email-masked]
Subject: ??: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

Best regards,
Xiaohu

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

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 10 Nov 2016 13:32:28 +0000

Xiaohu,

No — the RLDC/RLD from draft-ietf-ospf-mpls-elc is applicable to any MPLS case. It’s not like an LSR reads different depths depending on the application.

Where does it say that RLDC/RLD are only applicable to EL-based MPLS LB?

—

On Nov 10, 2016, at 4:57 AM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 11 Nov 2016 04:32:26 +0000

Hi,

I agree that the current definition of RLD is underspecified today in draft-ietf-mpls-spring-entropy-label and we need to have a more precise definition and we will fix it.

Now, regarding RLDC, advertising RLD in IGP was introduced for the purpose of entropy label insertion.
Carlos, do you see a use case to transmit RLDC for another purpose than placing ELI/ELs ?

Brgds,

Stephane

From: mpls [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Thursday, November 10, 2016 14:32
To: Xiaohu Xu
Cc: [email-masked]; OSPF WG List
Subject: Re: [mpls] [OSPF] 答复: WG Last Call for "Signalling ELC using OSPF"

Xiaohu,

—

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 11 Nov 2016 10:00:42 +0000

Hi Carlos,

Your understanding is absolutely correct. The RLDC could be applicable to other scenarios although only the EL insertion applicability is mentioned in this draft.

Best regards,
Xiaohu

发件人: Carlos Pignataro (cpignata) [mailto:[email-masked]]
发送时间: 2016年11月10日 21:32
收件人: Xuxiaohu
抄送: Bruno Decraene; OSPF WG List; [email-masked]
主题: Re: [OSPF] 答复: WG Last Call for "Signalling ELC using OSPF"

Xiaohu,

—

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 11 Nov 2016 10:10:43 +0000

Hi Bruno,

发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2016年11月10日 21:31
收件人: Xuxiaohu
抄送: OSPF WG List; Carlos Pignataro (cpignata); [email-masked]
主题: RE: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi Xuxiaohu,

[Xiaohu] LSRs advertise how many labels they could read from the top of the label stack. LSRs can advertise this information no matter whether or not they support EL-based LB.

[Xiaohu] This draft only describes how to advertise the RLDC via IGP. As for how to use this information by ingress LSRs when inserting EL pairs, it’s discussed in Section 4 of draft-ietf-mpls-spring-entropy-label-04.

Best regards,
Xiaohu

Thanks,
Best regards,
Bruno

Cc: OSPF WG List; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 11 Nov 2016 13:16:41 +0000

Hi, Stephane,

Please see inline.

—

On Nov 10, 2016, at 11:32 PM, [email-masked]<mailto:[email-masked]> wrote:

Hi,

I do not see other realistic use case. In fact, personally, I am not fully convinced of this ELI/EL use case either.

But Xiaohu (co-author) indicates there are different uses:
https://www.ietf.org/mail-archive/web/ospf/current/msg08418.html

Text in the document seems to indicate the use is for EL in SPRING only:

   In
   addition, in the cases where stacked LSPs are used for whatever
   reasons (e.g., SPRING-MPLS [I-D.ietf-spring-segment-routing-mpls]),
   it would be useful for ingress LSRs to know each LSR's capability of
   reading the maximum label stack deepth.  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] .

Best,

— Carlos.

Brgds,

Stephane

From: mpls [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Thursday, November 10, 2016 14:32
To: Xiaohu Xu
Cc: [email-masked]<mailto:[email-masked]>; OSPF WG List
Subject: Re: [mpls] [OSPF] 答复: WG Last Call for "Signalling ELC using OSPF"

Xiaohu,

—

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 12 Nov 2016 22:08:17 +0000

Hi Tiger, other authors,
So, this is my take on the draft information content based on the comments from Carlos and Bruno.

   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.

Thanks,
Acee

From: OSPF <[email-masked]<mailto:[email-masked]>> on behalf of Xiaohu Xu <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 11, 2016 at 5:10 AM
To: Bruno Decraene <[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月10日 21:31
收件人: Xuxiaohu
抄送: OSPF WG List; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
主题: RE: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi Xuxiaohu,

Best regards,
Xiaohu

Thanks,
Best regards,
Bruno

Hi Bruno,

Best regards,
Xiaohu

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

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Sun, 13 Nov 2016 11:36:17 +0000

Hi Acee,

I fully agree with your take.

Best regards,

Xiaohu

________________________________
发件人: Acee Lindem (acee) [[email-masked]]
发送时间: 2016年11月13日 6:08
收件人: Xuxiaohu; [email-masked]
抄送: OSPF WG List; [email-masked]; Carlos Pignataro (cpignata)
主题: Re: [OSPF] 答复: WG Last Call for "Signalling ELC using OSPF"

Hi Tiger, other authors,

Thanks,
Acee

Hi Bruno,

Hi Xuxiaohu,

Best regards,
Xiaohu

Thanks,
Best regards,
Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Sun, 13 Nov 2016 12:48:17 +0000

Hi all,

How about making the following two changes:

OLD:

"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....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..."

NEW:

"A new TLV within the body of the OSPF RI LSA, called RLD TLV is defined to advertise the maximum label stack depth that the originating router can read (i.e., how many labels can the router read from the label stack of a given received MPLS packet to the maximum extent). How to use this RLD information is outside the scope of this draft... If a router has multiple line cards and the maximum label stack depths they can read are different, the originating router MUST advertise the smallest one in the RLD TLV..."

OLD:

"6<https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-03#section-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 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.  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
  document and accordingly would be described in
   [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>]."

NEW:

"6<https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-03#section-6>.  Usage and Applicability

   The ELC is used by ingress LSRs to determine whether an EL could be
   inserted into a given LSP tunnel [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>].

   The RLD could 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>]."   This document

   only describes how to signal the ELC and RLD using OSPF.  How to apply

   them is outside the scope of this document."

Best regards,

Xiaohu

Hi Tiger, other authors,

Thanks,
Acee

Hi Bruno,

Hi Xuxiaohu,

Best regards,
Xiaohu

Thanks,
Best regards,
Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 14 Nov 2016 10:51:03 +0000

Hi Xiaohu,

Thanks for the proposed text.
My understanding is that the RLDC is intended to give information to the ingress node, to help him insert an ELI, EL pair at a given depth (or not)  in order to improve the load-balancing on a transit LSR.

My concern is that the current definition of the RLDC “the maximum label stack depth that the originating router can read” is not that specific to the load balancing capability of the transit LSR.
cf the below example of a load balancing algo on one real world plateform
Label <=3: 2-tuple <source IP(rightmost 30bit), destination IP (rightmost 30bit)>
Label = 4: bottom-of-stack label (rightmost 20bit)
Label>=5: Fifth(rightmost 20bit) label from the top

In this case, even if the LSR can read 5 labels, advertising a RDLC of 5 gives a wrong or incomplete information to the ingress as it could understand that
- it could insert the EL anywhere in the 5 first labels;  which is wrong as the EL would only provide a value if placed at the bottom of the stack
- inserting an EL in the first 5 labels would improve load-balancing; which, is wrong as inserting an (additional EL) could make the IP header not readable anymore hence even degrade the load balancing.

As already expressed, modeling the load-balancing behavior of a MPLS LSR would require more than the advertisement of a single value. However, to keep the change minimal, I would propose the following change
OLD: 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....
NEW: This document defines a new TLV, called RLDC TLV, within the body of the OSPF RI LSA. RLDC value advertised is the label stack depth that the LSR will use to load-balance a MPLS packet. If an ELI, EL pair is within the RLDC, and the LSR is capable of recognizing the ELI, the LSR MUST use the entropy of the EL to load-balance the packet.  If an ELI, EL pair is within the RLDC, and the LSR is not capable of recognizing the ELI, the LSR MUST either use the entropy of the whole stack of RLDC labels (hence including the EL label) or load-balance based on the below non-MPLS header (e.g. the IP header).

I’m open to any different text or a different property, but the point is to advertise a _load_balancing_ property of the LSR.

In the above example, with this new definition, the plateform would advertise a RLDC of 0, even though it can read 5 labels.

Thanks
Bruno
From: Xuxiaohu [mailto:[email-masked]]
Sent: Sunday, November 13, 2016 1:48 PM
To: Acee Lindem (acee); DECRAENE Bruno IMT/OLN
Cc: OSPF WG List; [email-masked]; Carlos Pignataro (cpignata)
Subject: ??: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi all,

OLD:

NEW:

OLD:

NEW:

Best regards,

Xiaohu

________________________________
发件人: Acee Lindem (acee) [[email-masked]]
发送时间: 2016年11月13日 6:08
收件人: Xuxiaohu; [email-masked]<mailto:[email-masked]>
抄送: OSPF WG List; [email-masked]<mailto:[email-masked]>; Carlos Pignataro (cpignata)
主题: Re: [OSPF] 答复: WG Last Call for "Signalling ELC using OSPF"
Hi Tiger, other authors,
So, this is my take on the draft information content based on the comments from Carlos and Bruno.

Thanks,
Acee

Hi Bruno,

Hi Xuxiaohu,

Best regards,
Xiaohu

Thanks,
Best regards,
Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 14 Nov 2016 11:05:41 +0000

I meant:
My concern is that the current definition of the RLDC “the maximum label stack depth that the originating router can read” is not that specific to the load balancing behavior of the transit LSR.

Sorry for the spam

From: OSPF [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, November 14, 2016 11:51 AM
To: Xuxiaohu
Cc: OSPF WG List; Carlos Pignataro (cpignata); [email-masked]
Subject: Re: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Xiaohu,

Thanks
Bruno

Cc: OSPF WG List; [email-masked]<mailto:[email-masked]>; Carlos Pignataro (cpignata)

Hi all,

OLD:

NEW:

OLD:

NEW:

Best regards,

Xiaohu

Thanks,
Acee

Hi Bruno,

Hi Xuxiaohu,

Best regards,
Xiaohu

Thanks,
Best regards,
Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 14 Nov 2016 12:00:30 +0000

Hi Bruno,

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

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. "

Best regards,
Xiaohu

________________________________
发件人: [email-masked] [[email-masked]]
发送时间: 2016年11月14日 19:05
收件人: DECRAENE Bruno IMT/OLN; Xuxiaohu
抄送: OSPF WG List; Carlos Pignataro (cpignata); [email-masked]
主题: RE: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

I meant:

Sorry for the spam

Hi Xiaohu,

Thanks
Bruno

Hi all,

OLD:

NEW:

OLD:

NEW:

Best regards,

Xiaohu

Thanks,
Acee

Hi Bruno,

Hi Xuxiaohu,

Best regards,
Xiaohu

Thanks,
Best regards,
Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

So the main question is: Is draft-ietf-ospf-mpls-elc-03 to be treated independently form draft-ietf-mpls-spring-entropy-label-04? That is a fundamental question for advancing and reviewing this/these doc(s). We have the advertisement of a capability ― what is it used for? Is it the right variable to advertise (based on the application using it)?

Then the doc continues:
“

Another point comment ― although I think this needs a thorough review before WGLC.

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

―

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. >

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 14 Nov 2016 12:16:00 +0000

by the way, the RLD is just used to advertise how many labels can be read to the maximum extent. It's not used to indicate whether or not the EL-based LB capability is supported. In the EL-based LB approach, it doesn't require all LSRs along a given LSP to recoginize the ELI. In a word, the ingress of a given LSP tries to insert ELI/EL within the RLD of all LSRs along the LSP. If all LSRs are capable of performing EL-based BL, that's great. If some or even all LSRs are not capable of performing EL-based BL, that's fine.

Best regards,

Xiaohu

________________________________
发件人: mpls [[email-masked]] 代表 Xuxiaohu [[email-masked]]
发送时间: 2016年11月14日 20:00
收件人: [email-masked]
抄送: OSPF WG List; [email-masked]
主题: [mpls] 答复: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

Best regards,
Xiaohu

I meant:

Sorry for the spam

Hi Xiaohu,

Thanks
Bruno

Hi all,

OLD:

NEW:

OLD:

NEW:

Best regards,

Xiaohu

Thanks,
Acee

Hi Bruno,

Hi Xuxiaohu,

Best regards,
Xiaohu

Thanks,
Best regards,
Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

―

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. >

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 14 Nov 2016 20:27:38 +0000

I think Bruno’s point is to tell that if a router advertises that it can read up to x labels, it does not mean that it will take into account all labels between position 1 and x when doing loadbalancing. This is implementation dependent. And even RFC6790 tells that looking for ELI is optional by using a “MAY”.
In addition, loadbalancing hash keys may be tuned on a node and not reflected in RLDC. A user may prefer to ask router to look at payload rather than hashing one or more MPLS labels.

Regards,

Stephane

From: OSPF [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Monday, November 14, 2016 21:16
To: DECRAENE Bruno IMT/OLN
Cc: OSPF WG List; [email-masked]
Subject: [OSPF] 答复: ??: WG Last Call for "Signalling ELC using OSPF"

Best regards,

Xiaohu

________________________________
发件人: mpls [[email-masked]] 代表 Xuxiaohu [[email-masked]]
发送时间: 2016年11月14日 20:00
收件人: [email-masked]<mailto:[email-masked]>
抄送: OSPF WG List; [email-masked]<mailto:[email-masked]>
主题: [mpls] 答复: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

Best regards,
Xiaohu

发件人: [email-masked]<mailto:[email-masked]> [[email-masked]]

Sorry for the spam

From: OSPF [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, November 14, 2016 11:51 AM
To: Xuxiaohu
Cc: OSPF WG List; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: Re: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Xiaohu,

Thanks
Bruno

Hi all,

OLD:

NEW:

OLD:

NEW:

Best regards,

Xiaohu

Thanks,
Acee

Hi Bruno,

Hi Xuxiaohu,

Best regards,
Xiaohu

Thanks,
Best regards,
Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 18 Nov 2016 17:30:09 +0000

Hi Xiaohu,

Sent: Monday, November 14, 2016 1:00 PM

Hi Bruno,

[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.

[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.

Best regards,
Xiaohu

Sorry for the spam

Hi Xiaohu,

Thanks
Bruno

Hi all,

OLD:

NEW:

OLD:

NEW:

Best regards,

Xiaohu

Thanks,
Acee

Hi Bruno,

Hi Xuxiaohu,

Best regards,
Xiaohu

Thanks,
Best regards,
Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 18 Nov 2016 23:32:55 +0000

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,

Hi Bruno,

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. think ELC should be defined in RFC 6790 and the SPRING Entropy label draft as opposed to the IGP advertisement drafts.

Thanks,
Acee

Best regards,
Xiaohu

发件人:[email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]

Sorry for the spam

Hi Xiaohu,

Thanks
Bruno

Hi all,

OLD:

NEW:

OLD:

NEW:

Best regards,

Xiaohu

发件人: Acee Lindem (acee) [[email-masked]<mailto:[email-masked]>]

Thanks,
Acee

Hi Bruno,

Hi Xuxiaohu,

Best regards,
Xiaohu

Thanks,
Best regards,
Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 21 Nov 2016 14:43:33 +0000

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]; Carlos Pignataro (cpignata)
Subject: Re: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

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.”

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.

Thanks,
--Bruno

Thanks,
Acee

Best regards,
Xiaohu

Sorry for the spam

Hi Xiaohu,

Thanks
Bruno

Hi all,

OLD:

NEW:

OLD:

NEW:

Best regards,

Xiaohu

Thanks,
Acee

Hi Bruno,

Hi Xuxiaohu,

Best regards,
Xiaohu

Thanks,
Best regards,
Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi all,

Thanks,
Regards,
-- Bruno

Hi Carlos,

Then the doc continues:
“

The doc says:
   Of course,

Best regards,
Xiaohu

Thanks,

—

Hi Acee,

Hi Bruno,

Hi authors, all,

Thanks,
Regards,
-- Bruno

§1.  Introduction

   the label stack. »

I would tend to agree.

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Acee

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 21 Nov 2016 17:01:45 +0000

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,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

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.

Why can’t we simply use the definition of entropy processing included in RFC 6790 section 4?

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Mon, 21 Nov 2016 12:19:14 -0500

One grammar correction below. 

> On Nov 21, 2016, at 12:01 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Bruno, 
> 
> From: Bruno Decraene <[email-masked] <mailto:[email-masked]>>
> 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]>>
> From: Acee Lindem (acee) [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: OSPF WG List; [email-masked] <mailto:[email-masked]>; Carlos Pignataro (cpignata)
> From: OSPF <[email-masked] <mailto:[email-masked]>> on behalf of Bruno Decraene <[email-masked] <mailto:[email-masked]>>
> 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]>>
> From: Xuxiaohu [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: OSPF WG List; Carlos Pignataro (cpignata); [email-masked] <mailto:[email-masked]>

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 is important when searching for an entropy label for the purposes of load-balancing as the <ELI, EL> pair must be included in the first RLD labels in the stack. 

Thanks,
Acee

> https://tools.ietf.org/html/rfc7325#section-2.4.5 <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.
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ospf <https://www.ietf.org/mailman/listinfo/ospf>

---

From: <[email-masked]>
Date: Mon, 21 Nov 2016 17:21:41 +0000

Hi Acee,

Sent: Monday, November 21, 2016 6:02 PM

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

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. »

[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."

[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.

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. Which is the purpose of advertising the RLD (AFAIK).
Thanks
--Bruno

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 21 Nov 2016 17:40:50 +0000

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,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

[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.

Am I the only one who thinks this is obvious?

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.

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.

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 23 Nov 2016 01:35:48 +0000

Hi Acee,

The ELC is only used to indicate that the advertising router as an egress of a given LSP could pop the EL/ELI pair. As such, the ingress of an LSP doesn’t know whether those transit LSRs along this LSP could perform EL-based load-balancing when inserting EL/ELI.

Best regards,
Xiaohu

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

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

---

From: <[email-masked]>
Date: Thu, 24 Nov 2016 09:57:46 +0000

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]; Carlos Pignataro (cpignata); Xuxiaohu
Subject: Re: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

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.

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)

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)

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 24 Nov 2016 17:20:43 +0000

Hi Bruno,

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

Date: Thursday, November 24, 2016 at 4:57 AM

Hi Acee

Cc: OSPF WG List; [email-masked]<mailto:[email-masked]>; Carlos Pignataro (cpignata); Xuxiaohu

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

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.

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.

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

Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 25 Nov 2016 02:20:10 +0000

Hi Acee and Bruno,

发送时间: 2016年11月25日 1:21

Hi Bruno,

Hi Acee

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

[Xiaohu] Concur.

[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. 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

Why doesn’t this work?

Happy Thanksgiving,
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 25 Nov 2016 14:46:27 +0000

Hi Xiaohu,

Sent: Friday, November 25, 2016 3:20 AM

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,

Hi Acee

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

[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. »

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.

[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

Why doesn’t this work?

Happy Thanksgiving,
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 25 Nov 2016 14:46:28 +0000

Hi Acee,

Please see inline [Bruno4]

Sent: Thursday, November 24, 2016 6:21 PM

Hi Bruno,

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

Hi Acee

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Acee,

Hi Bruno,

Hi Xiaohu,

Hi Bruno,

If you want to restrict the capability to the entropy label usage then an appropriate moniker would be the ELRD (Entropy Label Readable Depth).
[Bruno4] I'm not proposing this. I'm proposing to add that the label read _are_ used for loadbalancing purpose. Either by recognizing the ELI or by hashing on all those labels.
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).
[Bruno4] Tying RLD to load balancing is exactly what [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>] does. Now we can say that the OSPF document is the reference regarding the definition of RLD and hence this mpls document is wrong about its usage. Both options works for me. But note also that the ospf document does tie both:

- §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. »

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.
[Bruno4] I'm all for modularity. But ELC only defines EL behavior on the egress LER, not on transit LSR.

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?
[Bruno4] would work for me.
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  ;^)
[Bruno4] not so much. Note that this is a MPLS WG document, and this looks fine to me as this is MPLS dataplane specific.
and it certainly isn't within the charter of the OSPF or ISIS WGs.

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.
[Bruno4] ELC is already defined in RFC 6790 and it only defines the entropy label popping capability. It does not define the entropy label load-balancing capability. However, the IGP document could advertise this additional (third) capability. this would also works for me.

Happy Thanksgiving,

Thanks. Happy thanksgiving to you.
--Bruno
Acee

Thanks,
--Bruno

Thanks,
Acee

Thanks
--Bruno

Thanks,
Acee

Thank you.

Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 26 Nov 2016 01:05:16 +0000

Hi Bruno,

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

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.

[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

   inserted into a given LSP tunnel.  The RLDC may be used by ingress LSRs

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

--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: Mon, 28 Nov 2016 16:24:01 +0000

Hi Xiaohu,

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

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

[Bruno4] I’m fine with this, with the addition of the reference to draft-ietf-mpls-spring-entropy-label at the end of the first sentence, in order for the reader to know where RLD is defined and how it is used.

[Bruno4] I’m not seeing the benefit of this section and would rather remove it.

--Bruno

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: Xuxiaohu <[email-masked]>
Date: Tue, 29 Nov 2016 10:06:28 +0000

Hi Bruno,

Thanks for your further comments and suggestions. Please see my response inline with [Xiaohu2]

发送时间: 2016年11月29日 0:24

Hi Xiaohu,

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

[Xiaohu2] In fact, it has been said in the introduction section that
 “…In addition, in the cases where stacked LSPs are used for
   whatever reasons (e.g., SPRING-MPLS
   [I-D.ietf-spring-segment-routing-mpls]), it would be useful for
   ingress LSRs to know each LSR's capability of reading the maximum
   label stack depth.  This capability, referred to as Readable Label

Xu, et al.                Expires June 2, 2017                  [Page 2]

Internet-Draft          Signalling ELC using OSPF          November 2016

   Depth Capability (RLDC) may be used by ingress LSRs to determine
   whether it's necessary to insert an EL for a given LSP of the stacked
   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].
…”

As a result, it seems no need to add the reference to draft-ietf-mpls-spring-entropy-label in Section 5, IMO. No?

[Xiaohu2] OK, I will remove it.

Best regards,
Xiaohu

--Bruno

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: <[email-masked]>
Date: Tue, 29 Nov 2016 13:39:46 +0000

Hi Xiaohu,

Thanks for proposing text.
Please see inline [Bruno5]
In summary, I think we have converged on this OSPF document defining the OSPF encoding and I-D.ietf-mpls-spring-entropy-label defining the meaning and usage of RLD. This is clearly one way to avoid inconsistency between both documents.

Thanks,
--Bruno

Sent: Tuesday, November 29, 2016 11:06 AM

Hi Bruno,

Hi Xiaohu,

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

As a result, it seems no need to add the reference to draft-ietf-mpls-spring-entropy-label in Section 5, IMO. No?
[Bruno5] ok. works for me. In section 10, I think [I-D.ietf-mpls-spring-entropy-label]. should be moved to normative reference, as it’s the reference to the RLD meaning and usage.

[Bruno5] ok ,thanks.

Best regards,
Xiaohu

--Bruno

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: Thu, 1 Dec 2016 01:47:12 +0000

Hi Bruno,

OK, I will update the reference according to your suggestion. Thanks again for your valuable comments and suggestions.

Best regards,
Xiaohu

发送时间: 2016年11月29日 21:40

Hi Xiaohu,

Thanks,
--Bruno

Hi Bruno,

Hi Xiaohu,

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

--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.

Thank you.