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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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:[e-mail] <mailto:[e-mail]>] On Behalf Of George Swallow
> Sent: Monday, April 25, 2016 10:57 AM
> To: Stewart Bryant
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> I support this becoming a WG doc and thereby comming under WG
> control.
> 
> The document is a WG doc.   We are now in WG last call.
> 
> 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?
> 
> 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
> 
> 
> On 23/04/2016 08:53, Loa Andersson wrote:
> 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 ([e-mail] <mailto:[e-mail]>).
> 
> 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
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>