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

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

Hi, Sri,

Thanks for the response — please see inline.

> On Apr 29, 2016, at 5:37 PM, Sri <[e-mail]> wrote:
> 
> Hi Carlos,
> 
> Thanks for your comments. Pls see inline.
> 
> On Tue, Apr 26, 2016 at 9:29 PM, Carlos Pignataro (cpignata) <[e-mail] <mailto:[e-mail]>> 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:
> 
> 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".
> 
> 
> 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?

> 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.
> 
> Sri> Accepted. These references would be updated.
> 

OK.

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

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?

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

> 
> 
> 3. Intended status:
> 
> 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.
> 
> 
> 
> 4. EL Capability?
> 
> This is probably the most important comment. The document defines the ELC acronym, but it does not use it.
> 
> Sri> ELC is not defined in this draft. It is taken from RFC6790
> 

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.

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

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

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

Currently the draft says:

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

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

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

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

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

> 
> 
> More editorial comments:
> 
> No reference to draft-ietf-spring-segment-routing-mpls?
> 
> Sri> Accepted. Will add it.
> 
> 
> 
>    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?
> 
> Sri> Because Segment Routing is based on Source Routing.
> 
> 
>       OAM - Operation, Administration and Maintenance
> 
> Should be "OAM - Operation, Administration, and Maintenance"
> 
> Sri> Accepted
> 
> 
> 
>    [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.
> 
> Sri> Accepted
> 

Thanks,

— Carlos.

> 
> Thanks!
> 
> — Carlos.
> 
>> On Apr 25, 2016, at 3:19 PM, Gregory Mirsky <[e-mail] <mailto:[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>
> 
> _______________________________________________
> mpls mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
> 
>