Subject: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

From: Loa Andersson <[email-masked]>
Date: Sat, 23 Apr 2016 15:53:28 +0800

Working Group,

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

Please send your comments to the mpls wg mailing list ([email-masked]).

There are no IPR disclosures against this document.

All the authors and contributors (with one exception) have stated on
the working group mailing list that they are not aware of any other
IPRs that relates to this draft.

This working group last call ends May 12, 2016.

/Loa
for the MPLS wg chairs
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Sri <[email-masked]>
Date: Sat, 23 Apr 2016 05:06:53 -0500

Hi,

Support as co-author.

Sri

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 23 Apr 2016 17:57:48 +0000

I support publication of this work. I have the following editorial
comments:

208,209c208,209
<    source routed label stacks.  Lets L_N-P denote the label to be used
<    to reach the node SID of LSR P.  Let L_A-Ln denote the label used for
---
>    source routed label stacks.  Let L_N-P3 denote the label to be used
>    to reach the node SID of LSR P3.  Let L_A-Ln denote the label used for
322c322
<    label stack.  In the example described in Section 3 it will result in
---
>    label stack.  In the example described in Section 3, it will result in
330c330
<    Section 3 the LSR P1 would poorly load-balance traffic on the
---
>    Section 3, the LSR P1 would poorly load-balance traffic on the
349c349
<    This option was discounted since there exist a number of hardware
---
>    This option was rejected since there are a number of hardware
351,352c351,352
<    Choosing this option can lead to a loss of load-balancing using EL in
<    a significant part of the network but that is a critical requirement
---
>    Choosing this option can lead to EL load-balancing interruptions in
>    a significant part of the network and that is a critical requirement
377c377
<    This option was discounted due to the existence of hardware
---
>    This option was rejected due to the existence of hardware
381c381
<    restrict the number of tunnels that can form a LSP and constrain the
---
>    restrict the number of LSRs that can form an LSP and constrain the
419c419
<    This option was discounted due to the significant change in label
---
>    This option was rejected due to the significant change in label
432c432
<    This option was discounted due to the significant change in label
---
>    This option was rejected due to the significant change in label

Thanks,
Acee 

On 4/23/16, 3:53 AM, "mpls on behalf of Loa Andersson"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 24 Apr 2016 03:22:58 +0000

Hi Loa,

Support as a co-author.

Thanks,
Jeff

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 23 Apr 2016 20:24:25 -0700

Now with correct email

Support as a co-author.

Thanks,
Jeff

---

From: Uma Chunduri <[email-masked]>
Date: Sun, 24 Apr 2016 18:25:31 +0000

We have implemented this and have few minor comments (shall post soon).

I support adoption.

--
Uma C.

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Saturday, April 23, 2016 12:53 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

Working Group,

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

All the authors and contributors (with one exception) have stated on the working group mailing list that they are not aware of any other IPRs that relates to this draft.

/Loa
for the MPLS wg chairs
--

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Sun, 24 Apr 2016 18:32:03 +0000

Support as a co-author.

-Siva

From: mpls [mailto:[email-masked]] On Behalf Of Sri
Sent: Saturday, April 23, 2016 6:07 AM
To: Loa Andersson
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

Hi,

Support as co-author.

Sri

On Sat, Apr 23, 2016 at 2:53 AM, Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
Working Group,

Please send your comments to the mpls wg mailing list ([email-masked]<mailto:[email-masked]>).

/Loa
for the MPLS wg chairs
--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Huawei Technologies (consultant)     phone: +46 739 81 21 64<tel:%2B46%20739%2081%2021%2064>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 25 Apr 2016 14:58:51 +0100

I support this becoming a WG doc and thereby comming under WG
control.

However I am not sure about the dismissal of the option to reuse
the ELI+EL. This clutters the stack less than the proposed option.

Also I wonder why this is standards track?

Surely any equipment that understands the ELI can do this and thus this 
is just an informal description of the problem and a solution.

Stewart

---

From: George Swallow <[email-masked]>
Date: Mon, 25 Apr 2016 13:57:27 -0400

Stewart -

> I support this becoming a WG doc and thereby comming under WG

The document is a WG doc.   We are now in WG last call.

> Also I wonder why this is standards track?

A reasonable question, particularly since there are no MUSTs, SHALLs or
REQUIREDs.  Will discuss with my Co-Chairs and ADs.

> Surely any equipment that understands the ELI can do this and thus this is
> just an informal description of the problem and a solution.
>
> Stewart
>
>

---

From: George Swallow <[email-masked]>
Date: Mon, 25 Apr 2016 14:24:37 -0400

I support the document going forward as "Informational" and have the
following comments:

Section 5.4 para 1

OLD:

   protocol such as an IGP.  For the same Section 3
<https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-02#section-3>
above, if LSR P1

NEW:

   protocol such as an IGP.

<NEW PARAGRAPH>

   Applying this method to the example in Section 3 above, if LSR P1

Section 5.4 para

OLD:

   A variant of this solution was selected which balances the number of
   labels that need to be pushed against the requirement for entropy.

NEW:

<move this para above para 2>

   Note that as refinement of this solution which balances the number of
   pushed labels against the desired entropy is the solution described
in Section 4.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 25 Apr 2016 20:03:14 +0100

On 25/04/2016 18:57, George Swallow wrote:
> Stewart -
>
> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant 
> <[email-masked] <mailto:[email-masked]>> wrote:
>

Sorry, I missed that :( I should have read the subject!

> A reasonable question, particularly since there are no MUSTs, SHALLs 
> or REQUIREDs.  Will discuss with my Co-Chairs and ADs.

Well that brings me to wonder what needs to be specified, since action 
when the label stack is pushed is a local matter and as I remember a 
number of the rejected strategies are just normal MPLS.

- Stewart

>     Surely any equipment that understands the ELI can do this and thus
>     this is just an informal description of the problem and a solution.
>
>     Stewart
>
>
>         Please send your comments to the mpls wg mailing list
>         ([email-masked] <mailto:[email-masked]>).
>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 25 Apr 2016 19:19:12 +0000

Hi George, et. al,
I’ve found several occurrences, three actually, of SHOULD being used in Section 4.

And I agree with Stewart that application of <ELI, EL> is the local decision and, at most, this work can be published as Informational.
One comment, suggestion:

·         the sample algorithm in Section 4 suggests that the same <ELI,EL> tuple been used multiple times whereas it may be advantageous to generalize and point that the different entropy label value may be used by referring to the tuple as <ELI, ELn>

Regards,
        Greg

From: mpls [mailto:[email-masked]] On Behalf Of George Swallow
Sent: Monday, April 25, 2016 10:57 AM
To: Stewart Bryant
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

Stewart -

On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:
I support this becoming a WG doc and thereby comming under WG
control.

A reasonable question, particularly since there are no MUSTs, SHALLs or REQUIREDs.  Will discuss with my Co-Chairs and ADs.

Surely any equipment that understands the ELI can do this and thus this is just an informal description of the problem and a solution.

Stewart

/Loa
for the MPLS wg chairs

---

From: Loa Andersson <[email-masked]>
Date: Tue, 26 Apr 2016 13:03:53 +0800

Greg,

(talking about the SHOULDs in Section 4 only)

I think what George (and Stewart) says is that since the document does
not use any MUST, SHALL or REQUIRED, it makes sense to publish it as an
Informational RFC.

However, it does not work to turn that argument around and say that an
Informational RFC can't use the normative language, it was doen for 
example in RFC 7412.

I think we should change it to Informational, but there is no need to
do anything to the SHOULDs in section 4.

/Loa

On 2016-04-26 03:19, Gregory Mirsky wrote:
> And I agree with Stewart that application of <ELI, EL> is the local
> decision and, at most, this work can be published as Informational.
>
> One comment, suggestion:
>
> ·the sample algorithm in Section 4 suggests that the same <ELI,EL> tuple
> been used multiple times whereas it may be advantageous to generalize
> and point that the different entropy label value may be used by
> referring to the tuple as <ELI, ELn>
>
> Regards,
>
>          Greg
>
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *George Swallow
> *Sent:* Monday, April 25, 2016 10:57 AM
> *To:* Stewart Bryant
> *Cc:* [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [mpls] working group last call on
> draft-ietf-mpls-spring-entropy-label
>
> Stewart -
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 26 Apr 2016 07:56:54 +0100

If I look at section 4, the key piece of information is the RLD which
is the subject of other drafts. Given the RLD, how it is decided
to distribute the ELIs within the stack is purely a local matter.

5.1 is the trivial case of 4 for a large RLD, and for shorter RLD
is a matter for the imposing LSR to balance reduction in
ECMP against LS size (which may be a limit for that LSR anyway).
Either way unless you use some sort of phone a friend scheme*
(which you may need as the label stack grows beyond the capability of
the edge nodes) this is a local matter.

5.2 is the other trivial case of 4, which again is a local matter.

5.3 and 5.3.1 require hardware changes, but optimises the stack
size, which is an oft quoted issue in MPLS systems, particularly
PWs. As such it is not a local matter, but if you knew that strategic
nodes had that capability it would become a local matter.

Incidentally there is a need for something of the form of 5.3
in that an LSR pushing further labels may need to look at the existing
stack, retrieve the EL and add its own ELI/ELs. There perhaps
ought to be text describing this action, but once you have this
capability, surely 5.3 becomes a viable general solution.

Also a 5.3 like solution may be needed to overcome the
ingress node imposition limitations in cases where phone-a-friend
is not available.

5.4 is as the document notes really a version of 4.

There is so much that is a local matter that I am not sure the text
should go beyond describing the issues and leaving the decision
to the imposing LSR s/w team.

- Stewart

*As I recall that there is IPR on at least one phone-a-friend scheme

---

From: Sri <[email-masked]>
Date: Tue, 26 Apr 2016 10:09:33 -0700

Thanks Acee for the comments. I accept the comments but pls see inline at
Sri> for some clarification.

> >    to reach the node SID of LSR P3.  Let L_A-Ln denote the label used for

Sri> Changing 'Lets' to 'Let' is fine. Note that we are introducing
notation here that can be applied to specific node and adjacency SIDs. So
L_N-P is the generic notation for the label used for the SID of the node P,
which when applied to the SID for the node P3 becomes the label L_N-P3.  So
I prefer that the rest of the sentence stay as-is.

> >    label stack.  In the example described in Section 3, it will result in

Sri> Accepted

> >    Section 3, the LSR P1 would poorly load-balance traffic on the

Sri> Accepted

> >    This option was rejected since there are a number of hardware

Sri> Accepted

> >    a significant part of the network and that is a critical requirement

Sri> Accepted

> >    This option was rejected due to the existence of hardware

Sri> Accepted

> >    restrict the number of LSRs that can form an LSP and constrain the

Accepted

> >    This option was rejected due to the significant change in label

Sri> Accepted

> >    This option was rejected due to the significant change in label

Sri> Accepted

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 26 Apr 2016 17:54:32 +0000

Hi Sri,

Thanks - see one inline.

From: Sri Kini <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 26, 2016 at 1:09 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Loa Andersson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

Thanks Acee for the comments. I accept the comments but pls see inline at Sri> for some clarification.

On Sat, Apr 23, 2016 at 10:57 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
I support publication of this work. I have the following editorial
comments:

208,209c208,209
>    to reach the node SID of LSR P3.  Let L_A-Ln denote the label used for

Sri> Changing 'Lets' to 'Let' is fine. Note that we are introducing notation here that can be applied to specific node and adjacency SIDs. So L_N-P is the generic notation for the label used for the SID of the node P, which when applied to the SID for the node P3 becomes the label L_N-P3.  So I prefer that the rest of the sentence stay as-is.

It is still wrong since the original sentence specifically references LSR P3.  Perhaps:

    source routed label stacks.  Let L_N-Px denote the label to be used
    to reach the node SID of LSR Px.  Let L_A-Ln denote the label used for

Thanks,
Acee

322c322

Sri> Accepted

330c330

Sri> Accepted

349c349

Sri> Accepted

351,352c351,352

Sri> Accepted

377c377

Sri> Accepted

381c381

Accepted

419c419

Sri> Accepted

432c432

Sri> Accepted

Thanks,
Acee

On 4/23/16, 3:53 AM, "mpls on behalf of Loa Andersson"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

>[email-masked]<mailto:[email-masked]>

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

---

From: Sri <[email-masked]>
Date: Tue, 26 Apr 2016 11:00:43 -0700

Accepted.

Thanks
Sri

On Tue, Apr 26, 2016 at 10:54 AM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Sri,
>
> Thanks - see one inline.
>
> From: Sri Kini <[email-masked]>
> To: Acee Lindem <[email-masked]>
> Cc: Loa Andersson <[email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, "
> [email-masked]" <[email-masked]>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 27 Apr 2016 01:05:02 +0000

Hi Loa,
if the WG decides to publish the document, then the Informational is the right track.

Appreciate authors to consider my comment on generalizing references to an Entropy Label in the tuple as <ELI, ELn>.

	Regards,
		Greg

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Monday, April 25, 2016 10:04 PM
To: Gregory Mirsky; George Swallow; Stewart Bryant
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

Greg,

I think what George (and Stewart) says is that since the document does not use any MUST, SHALL or REQUIRED, it makes sense to publish it as an Informational RFC.

However, it does not work to turn that argument around and say that an Informational RFC can't use the normative language, it was doen for example in RFC 7412.

I think we should change it to Informational, but there is no need to do anything to the SHOULDs in section 4.

/Loa

On 2016-04-26 03:19, Gregory Mirsky wrote:
> Hi George, et. al,
>
> I've found several occurrences, three actually, of SHOULD being used 
> in Section 4.
>
> *the sample algorithm in Section 4 suggests that the same <ELI,EL> 
> tuple been used multiple times whereas it may be advantageous to 
> generalize and point that the different entropy label value may be 
> used by referring to the tuple as <ELI, ELn>
>
> Regards,
>
>          Greg
>
> I support this becoming a WG doc and thereby comming under WG control.
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 Apr 2016 04:29:40 +0000

Loa,

I just scanned through draft-ietf-mpls-spring-entropy-label-03 and wanted to share some observations. Please treat these as WGLC comments.

I have a number of concerns. It seems as if this document was not really reviewed to see if it was ready for WGLC:

1. What is this document specifying?

As Greg just mentioned below, there are several SHOULD terms in Section 4. Those SHOULD are dependent upon the “RLD".

That same section then lists the following:

   The RLD can be advertised via protocols and those extensions are
   described in separate documents [I-D.xu-isis-mpls-elc] and
   [I-D.xu-ospf-mpls-elc].

First, those are expired and should be marked as replaced by wg docs.

But the main point is that knowing the RLD is REQUIRED (neither RECOMMENDED nor OPTIONAL) to be able to follow and comply with the requirements on where to position the {ELI; EL} and with the pseudocode.

2. OAM?

The document says the following:

   The recommendations above are not expected to bring any additional
   OAM considerations beyond those described in section 6 of [RFC6790].
   However, the OAM requirements and solutions for source routed tunnels
   formed by label stacking are still under discussion and future
   revisions of this document will address those if needed.

Is this saying that the document still needs to evolve to be ready? What are really the OAM considerations related to this draft?

3. Intended status:

I agree with others in the sense that this is not a Standards Track doc.

4. EL Capability?

This is probably the most important comment. The document defines the ELC acronym, but it does not use it.

      ELC - Entropy Label Capability

From RFC 6790, the egress capability of processing EL needs to be signaled to the ingress for the ingress to be able to insert an ELI; EL.

In this case, the proposed method tries to optimize for position, but it is not taking into account whether the egress of each segment can actually process ELI; EL (or if it would otherwise Drop the packet!). The algorithm does says “if EL-capable”, but how is that learned?

In other words, this seems like a bug. Is the ingress is inserting a label (ELI) which the “egress” (each Node segment for example) might not understand and would drop?

5. Labels to push?

Inserting N * 2 LSEs can have implications on the head-end in terms of max numbers of labels which can be pushed. A label stack that is pushed onto a packet, might not be able to be pushed if the stack grows by 2 * N LSEs.

The text says in various portions things like:

   The LSR that inserts <ELI, EL> pairs MAY have limitations
   on the number of such pairs that it can insert and also the depth at
   which it can insert them.

However, is it really the limitation how many labels an ingress can push?

Also, if there is one node in the path which does not advertise the RLD, then would the RLD be zero and make the algorithm moot?

More editorial comments:

No reference to draft-ietf-spring-segment-routing-mpls?

   Source routed tunnels with label stacking is a technique that can be
   leveraged to provide a method to steer a packet through a controlled
   set of segments.

Why “source router tunnels with label stacking” (SRTLS?) and not Segment Routing with MPLS data plane?

      OAM - Operation, Administration and Maintenance

Should be "OAM - Operation, Administration, and Maintenance"

   [I-D.xu-isis-mpls-elc]
              Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
              Litkowski, "Signaling Entropy Label Capability Using IS-
              IS", draft-xu-isis-mpls-elc-02 (work in progress), April
              2015.

   [I-D.xu-ospf-mpls-elc]
              Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
              Litkowski, "Signaling Entropy Label Capability Using
              OSPF", draft-xu-ospf-mpls-elc-01 (work in progress),
              October 2014.

These are expired and replaced by other documents. They should be marked as Replaced-by in the Tracker.

Thanks!

— Carlos.

> On Apr 25, 2016, at 3:19 PM, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi George, et. al,
> From: mpls [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of George Swallow
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
> Please send your comments to the mpls wg mailing list ([email-masked] <mailto:[email-masked]>).
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 27 Apr 2016 12:07:34 +0100

> Segment Routing with MPLS data plane?

You are right, although source routing is really the generic name for 
this technology.

Stewart

---

From: Sri <[email-masked]>
Date: Thu, 28 Apr 2016 19:36:07 -0700

Hi Loa, I agree that changing it to informational while retaining the
SHOULDs is the right way. That should address similar comments by Stewart,
George, Greg and Carlos.

Thanks
Sri

---

From: Sri <[email-masked]>
Date: Thu, 28 Apr 2016 19:41:25 -0700

Hi George,

Thanks for the review comments. I accept the comments, but see inline.

Sri> Accepted

>
> Section 5.4 para 1
>
> OLD:
>
>    protocol such as an IGP.  For the same Section 3 <https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-02#section-3> above, if LSR P1
>
> NEW:
>
>    protocol such as an IGP.
>
> <NEW PARAGRAPH>
>
Sri> Accepted

>    pushed labels against the desired entropy is the solution described in Section 4.
>
>
> Sri> Accepted. I think the "as refinement" was a typo and it should be "a
refinement". If it is not pls let me know.

Thanks
Sri

---

From: Sri <[email-masked]>
Date: Fri, 29 Apr 2016 13:38:37 -0700

Hi Stewart,

Thanks for your comments. Pls see inline

> I support this becoming a WG doc and thereby comming under WG

Sri> As pointed out by George, this draft is going through WGLC.

> the ELI+EL. This clutters the stack less than the proposed option.

Sri> This option was not considered since it changes the label swap
operations and would need hardware changes.

> Also I wonder why this is standards track?
Sri> As per the response to Loa's suggestion, this draft will be changed to
Informational.

> just an informal description of the problem and a solution.

Sri> Since there are different ways to do this and some ways are better
than others, this draft lists the different options and recommends one
solution.

---

From: Sri <[email-masked]>
Date: Fri, 29 Apr 2016 13:41:17 -0700

Hi Stewart,

Pls see inline.

On Mon, Apr 25, 2016 at 12:03 PM, Stewart Bryant <[email-masked]>
wrote:

> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant <
> <[email-masked]>[email-masked]> wrote:
>
> when the label stack is pushed is a local matter and as I remember a number
> of the rejected strategies are just normal MPLS.
>

Sri> Just re-iterating a response to a similar point in an earlier email -
 "Since there are different ways to do this and some ways are better than
others, this draft lists the different options and recommends one solution."

Thanks
Sri

---

From: Sri <[email-masked]>
Date: Fri, 29 Apr 2016 13:59:29 -0700

Hi Greg,

Thanks for your comments. Pls see inline.

> decision and, at most, this work can be published as Informational.

Sri> As per my response to Loa's suggestion, the draft will be changed to
informational with all the SHOULDs retained.

> One comment, suggestion:
>
> ·         the sample algorithm in Section 4 suggests that the same
> <ELI,EL> tuple been used multiple times whereas it may be advantageous to
> generalize and point that the different entropy label value may be used by

Sri> We had shown that ELs may be different in the example in an earlier
version of the draft. Instead of referring to ELn, I would suggest that a
second sentence be added in the third para in sec 4 as follows "The ELs
among multiple <ELI, EL> pairs inserted in the stack may be same or
different".

Thanks
Sri

> *From:* mpls [mailto:[email-masked]] *On Behalf Of *George Swallow
> *Cc:* [email-masked]; [email-masked];
> [email-masked]

---

From: Sri <[email-masked]>
Date: Fri, 29 Apr 2016 14:01:09 -0700

A response to an earlier email from Greg, addresses all comments in this
email.

On Tue, Apr 26, 2016 at 6:05 PM, Gregory Mirsky <[email-masked]

> Appreciate authors to consider my comment on generalizing references to an
> Entropy Label in the tuple as <ELI, ELn>.
>
>         Regards,
>                 Greg
>
> I think what George (and Stewart) says is that since the document does not
> use any MUST, SHALL or REQUIRED, it makes sense to publish it as an
> Informational RFC.
>
> Informational RFC can't use the normative language, it was doen for example
> in RFC 7412.
>

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 29 Apr 2016 21:13:06 +0000

Hi Sri,
I agree with the way you plan to address my comment #2.

                Regards,
                                Greg

From: Sri [mailto:[email-masked]]
Sent: Friday, April 29, 2016 1:59 PM
To: Gregory Mirsky
Cc: George Swallow; Stewart Bryant; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

Hi Greg,

On Mon, Apr 25, 2016 at 12:19 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi George, et. al,
I’ve found several occurrences, three actually, of SHOULD being used in Section 4.

Sri> As per my response to Loa's suggestion, the draft will be changed to informational with all the SHOULDs retained.

One comment, suggestion:

•         the sample algorithm in Section 4 suggests that the same <ELI,EL> tuple been used multiple times whereas it may be advantageous to generalize and point that the different entropy label value may be used by referring to the tuple as <ELI, ELn>

Sri> We had shown that ELs may be different in the example in an earlier version of the draft. Instead of referring to ELn, I would suggest that a second sentence be added in the third para in sec 4 as follows "The ELs among multiple <ELI, EL> pairs inserted in the stack may be same or different".

Regards,
        Greg

Thanks
Sri

From: mpls [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of George Swallow
Sent: Monday, April 25, 2016 10:57 AM
To: Stewart Bryant
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

Stewart -

Stewart

/Loa
for the MPLS wg chairs

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 29 Apr 2016 22:15:36 +0100

> On 29 Apr 2016, at 21:41, Sri <[email-masked]> wrote:
> 
> Sri> Just re-iterating a response to a similar point in an earlier email -  "Since there are different ways to do this and some ways are better than others, this draft lists the different options and recommends one solution."

Hi Sri

We don't normally make a formal recommendation on a local matter such as this.

Stewart

---

From: Sri <[email-masked]>
Date: Fri, 29 Apr 2016 14:37:12 -0700

Hi Carlos,

On Tue, Apr 26, 2016 at 9:29 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Loa,
>
> I just scanned through draft-ietf-mpls-spring-entropy-label-03 and wanted
> to share some observations. Please treat these as WGLC comments.
>
> I have a number of concerns. It seems as if this document was not really
> reviewed to see if it was ready for WGLC:
>
> As Greg just mentioned below, there are several SHOULD terms in Section 4.
> Those SHOULD are dependent upon the “RLD".
>
>
Sri> As per my response to Loa's suggestion, this draft would be changed to
Informational with all the SHOULDs retained.

> First, those are expired and should be marked as replaced by wg docs.

Sri> Accepted. These references would be updated.

>
> But the main point is that knowing the RLD is REQUIRED (neither
> RECOMMENDED nor OPTIONAL) to be able to follow and comply with the
> requirements on where to position the {ELI; EL} and with the pseudocode.
>

Sri> The RLD is required to follow the recommended solution in the draft.
What exactly is the comment?

> Is this saying that the document still needs to evolve to be ready? What
> are really the OAM considerations related to this draft?
>

Sri> There are no new OAM consideration related to the recommendations in
this draft. Having said that, the SPRING OAM drafts are not RFCs yet. Hence
the wording.

> I agree with others in the sense that this is not a Standards Track doc.

Sri> As per an earlier response to Loa's suggestion, the draft will be
changed to Informational.

> acronym, but it does not use it.

Sri> ELC is not defined in this draft. It is taken from RFC6790

> From RFC 6790, the egress capability of processing EL needs to be signaled
> to the ingress for the ingress to be able to insert an ELI; EL.
>
> In this case, the proposed method tries to optimize for position, but it
> is not taking into account whether the egress of each segment can actually
> process ELI; EL (or if it would otherwise Drop the packet!). The algorithm
> does says “if EL-capable”, but how is that learned?
>

Sri> RFC6790 defined procedures to signal ELC, but did not do so for
OSPF/ISIS and these are defined in the documents referenced -
draft-xu-isis-mpls-elc and draft-xu-ospf-mpls-elc (which will be changed to
the WG draft versions).

>
> In other words, this seems like a bug. Is the ingress is inserting a label
> (ELI) which the “egress” (each Node segment for example) might not
> understand and would drop?
>

Sri> No. The recommended solution takes ELC into account and the
advertisement of ELC is as per the referenced drafts/RFCs.

>
> 5. Labels to push?
>
> Inserting N * 2 LSEs can have implications on the head-end in terms of max
> numbers of labels which can be pushed. A label stack that is pushed onto a
> packet, might not be able to be pushed if the stack grows by 2 * N LSEs.
>

Sri> How about re-wording it as "The LSR that inserts <ELI, EL> pairs MAY
have limitations on the number of labels that can be pushed and this can
limit the number of <ELI, EL> pairs that it can insert and also the depth
at which it can insert them".

> Also, if there is one node in the path which does not advertise the RLD,
> then would the RLD be zero and make the algorithm moot?
>

Sri> If the RLD of a node is not available at the headend, then it is a
local matter on how to treat it.

> No reference to draft-ietf-spring-segment-routing-mpls?

Sri> Accepted. Will add it.

> Routing with MPLS data plane?

Sri> Because Segment Routing is based on Source Routing.

Sri> Accepted

Sri> Accepted

> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *George Swallow

---

From: Sri <[email-masked]>
Date: Fri, 29 Apr 2016 14:38:46 -0700

Hi Stewart,

Since this will be an Informational draft shouldn't it be okay?

Sri

---

From: Sri <[email-masked]>
Date: Fri, 29 Apr 2016 15:03:20 -0700

Hi Stewart,

If even after changing the Status to Informational, any of these comments
still need to be addressed pls let me know.

Thanks
Sri

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 29 Apr 2016 22:08:50 +0000

Hi, Sri,

Thanks for the response — please see inline.

> On Apr 29, 2016, at 5:37 PM, Sri <[email-masked]> wrote:
> 
> Hi Carlos,
> 
> On Tue, Apr 26, 2016 at 9:29 PM, Carlos Pignataro (cpignata) <[email-masked] <mailto:[email-masked]>> wrote:
> Loa,
> 
> Sri> As per my response to Loa's suggestion, this draft would be changed to Informational with all the SHOULDs retained.
> 

Sorry I still do not understand. My comment is not about the intended status of the document.

Those SHOULDs depend on the RLD. So it is a protocol specification. However, the RLD is defined in other docs, and loosely integrated. How does the solution work without RLD (i.e., if the SHOULD is not followed)? And how is this whole thing specified without the ELC as a mandatory field?

> Sri> Accepted. These references would be updated.

OK.

> Sri> The RLD is required to follow the recommended solution in the draft. What exactly is the comment?
> 

The comment is, quoting from above, that “ the RLD is REQUIRED (neither RECOMMENDED nor OPTIONAL) to be able to follow and comply with the requirements”. Why SHOULD? And how is the RLD learned, used, calculated, etc?

> Sri> There are no new OAM consideration related to the recommendations in this draft. Having said that, the SPRING OAM drafts are not RFCs yet. Hence the wording.
> 

If the wording of “and future revisions of this document will address those if needed” is intended, is a WGLC premature?

> Sri> As per an earlier response to Loa's suggestion, the draft will be changed to Informational.
> 
> 
> 
> 4. EL Capability?
> 

I know, but it is not used.

Moreover, RFC 6790 defines the ELC, and explains how to signal it (Section 5) with LDP, BGP, and RSVP-TE. Later, RFC 7447 obsoleted the BGP use. However, this document does not use LDP or RSVP-TE.

If the ELC is not considered, then you can end up with pushing ELI/EL to a node that does not understand it.

> Sri> RFC6790 defined procedures to signal ELC, but did not do so for OSPF/ISIS and these are defined in the documents referenced - draft-xu-isis-mpls-elc and draft-xu-ospf-mpls-elc (which will be changed to the WG draft versions).

Yes. However, this document is not using the ELC — that’s my point.

> Sri> No. The recommended solution takes ELC into account and the advertisement of ELC is as per the referenced drafts/RFCs.
> 

How does the solution take into account the ELC? Can you please copy/paste text from the draft?

Currently the draft says:

So it is talking about the advertisement of RLD, but not the ELC, and not the use (after advertisement).

> Sri> How about re-wording it as "The LSR that inserts <ELI, EL> pairs MAY have limitations on the number of labels that can be pushed and this can limit the number of <ELI, EL> pairs that it can insert and also the depth at which it can insert them".
> 

To me, that is not a “MAY”. It may (not MAY) have limitations. But, the more important piece is missing — how do these limitations impact the solution in this doc?

> Sri> If the RLD of a node is not available at the headend, then it is a local matter on how to treat it.
> 

I believe this is incorrect. It’s part of the calculation, not a local matter.

Thanks,

— Carlos.

> 
> Thanks!
> 
> — Carlos.
> 
>> On Apr 25, 2016, at 3:19 PM, Gregory Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi George, et. al,

---

From: Sri <[email-masked]>
Date: Fri, 29 Apr 2016 15:51:43 -0700

Hi Carlos, pls see inline.

On Fri, Apr 29, 2016 at 3:08 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

>> As Greg just mentioned below, there are several SHOULD terms in Section
>> 4. Those SHOULD are dependent upon the “RLD".
>>
>>
> Sri> As per my response to Loa's suggestion, this draft would be changed
> to Informational with all the SHOULDs retained.
>
>
>
> Those SHOULDs depend on the RLD. So it is a protocol specification.
> However, the RLD is defined in other docs, and loosely integrated. How does
> the solution work without RLD (i.e., if the SHOULD is not followed)? And
> how is this whole thing specified without the ELC as a mandatory field?
>

Sri> The SHOULDs are part of the recommended solution. That does not imply
that this draft is a protocol specification. The documents
draft-xu-ospf-mpls-elc and draft-xu-isis-mpls-elc are the protocol
specifications and those are used in the recommended solution. They ELC is
required anytime EL is used. There is no implication in this doc that ELC
is not required. If it is not clear the the determination in the pseudocode
of whether a label is EL-capable can be done through ELC, I can modify the
first sentence in the second last para of section 4 to read "The RLD and
ELC can be advertised via protocols and ..."

> The comment is, quoting from above, that “ the RLD is REQUIRED (neither
> requirements”. Why SHOULD? And how is the RLD learned, used, calculated,
> etc?
>

Sri> Note that it is REQUIRED to follow and comply with the recommendation
(not requirements). RLD is advertised (learned) via the extensions in
draft-xu-ospf-mpls-elc and draft-xu-isis-mpls-elc, used as described in the
pseudocode and calculated as described in the second para of sec 4 (i.e.
based on the hardware limitations)

> If the wording of “and future revisions of this document will address
> those if needed” is intended, is a WGLC premature?
>

Sri> I don't think so. I can remove the second sentence and add a reference
to draft-ietf-spring-sr-oam-requirement and refer to it in the first
sentence right after RFC6790.

> Moreover, RFC 6790 defines the ELC, and explains how to signal it (Section
> 5) with LDP, BGP, and RSVP-TE. Later, RFC 7447 obsoleted the BGP use.
> However, this document does not use LDP or RSVP-TE.
>

Sri> Does the explanation to the earlier comments suffice?

>> From RFC 6790, the egress capability of processing EL needs to be
>> signaled to the ingress for the ingress to be able to insert an ELI; EL.
>>

Sri> Does the explanation to the earlier comments suffice?

>
>
>
>>
>> In other words, this seems like a bug. Is the ingress is inserting a
>> label (ELI) which the “egress” (each Node segment for example) might not

Sri> Does the explanation to the earlier comments suffice?

>
>
>>
>> 5. Labels to push?
>>
>> Inserting N * 2 LSEs can have implications on the head-end in terms of
>> max numbers of labels which can be pushed. A label stack that is pushed
>> onto a packet, might not be able to be pushed if the stack grows by 2 * N
>> LSEs.
>>
> To me, that is not a “MAY”. It may (not MAY) have limitations. But, the
> more important piece is missing — how do these limitations impact the
> solution in this doc?
>

Sri> Ok. I can change MAY to may. Does earlier explanation about ELC
suffice?

> I believe this is incorrect. It’s part of the calculation, not a local

Sri> Yes, it is part of the calculation. But it not being available at the
headend is presumably due to the appropriate protocol extensions not being
implemented in that intermediate node and would suggest that the best
course of action be some kind of default value determined by the headend.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 30 Apr 2016 20:05:41 +0000

Hi, Sri,

> On Apr 29, 2016, at 6:51 PM, Sri <[email-masked]> wrote:
> 
> On Fri, Apr 29, 2016 at 3:08 PM, Carlos Pignataro (cpignata) <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Sri,
> 
>> On Apr 29, 2016, at 5:37 PM, Sri <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Carlos,
>> 
> Sri> The SHOULDs are part of the recommended solution. That does not imply that this draft is a protocol specification. The documents draft-xu-ospf-mpls-elc and draft-xu-isis-mpls-elc are the protocol specifications and those are used in the recommended solution. They ELC is required anytime EL is used. There is no implication in this doc that ELC is not required. If it is not clear the the determination in the pseudocode of whether a label is EL-capable can be done through ELC, I can modify the first sentence in the second last para of section 4 to read "The RLD and ELC can be advertised via protocols and …"

I’m still having trouble parsing some of this. The RLD and ELC are not global variables. They are per-node (it seems, as defined at draft-*-mpls-elc). The ELC is relevant in the context of the node popping ELI/EL. This is not clear in the doc or in the pseudocode (esp. using a different name for the variable). The RLD relevant to the calculation seems to be a characteristic of the path on a segment, spanning multiple nodes. Is this the case? Perhaps a topology diagram and a stack diagram can clarify. The pseudocode seems to be treating the RLD as a constant.

Further, saying "The RLD and ELC can be advertised via protocols and …” seems to also confuse the context of these, and seems to be not enough. It is not as if they can (and cannot) be advertised a specific way. It is that are REQUIRED for the calculation.

Also, the algorithm assumes an LSR knows how many ELI/ELs can insert. Does an LSR know instead the max number of labels it can push?

Also, looking at the design principles, the first bullet says:

   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.

Why is that? If the top segment traverses 15 LSRs and the next-to-bottom segment traverses 1 hop, and the source can only afford a single ELI;EL, are we missing a LB opportunity?

Lastly, the algorithm does not consider Node SIDs versus Adjacency SIDs. Why would you want to add an ELI/EL in an Adjacency SID?

> Sri> Note that it is REQUIRED to follow and comply with the recommendation (not requirements). RLD is advertised (learned) via the extensions in draft-xu-ospf-mpls-elc and draft-xu-isis-mpls-elc, used as described in the pseudocode and calculated as described in the second para of sec 4 (i.e. based on the hardware limitations)
> 

Are RLDs and ELCs required to use the mechanism in this draft?

Note that the section you point to says “within the RLD of LSRs along the path corresponding to a label stack”. How are the RLDs of LSRs along the path contemplated in the pseudocode?

> Sri> I don't think so. I can remove the second sentence and add a reference to draft-ietf-spring-sr-oam-requirement and refer to it in the first sentence right after RFC6790.
> 

These two features seem to be quite entangled. Is SR-EL adding requirements to SR-OAM, or viceversa? Or both?

> Sri> Does the explanation to the earlier comments suffice?

Not to me, sorry.

> Sri> Does the explanation to the earlier comments suffice?

Sorry, it is not clear to me. Perhaps a diagram might help.

> Sri> Does the explanation to the earlier comments suffice?

Nope.

> Sri> Ok. I can change MAY to may. Does earlier explanation about ELC suffice?
> 

I’ve not changed my mind on the same question :-)

> Sri> Yes, it is part of the calculation. But it not being available at the headend is presumably due to the appropriate protocol extensions not being implemented in that intermediate node and would suggest that the best course of action be some kind of default value determined by the headend.
> 

Making an assumption about RLD is a big difference from what the document says. That has risks.