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

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

Hi, Sri,

> On Apr 29, 2016, at 6:51 PM, Sri <[e-mail]> wrote:
> 
> Hi Carlos, pls see inline.
> 
> On Fri, Apr 29, 2016 at 3:08 PM, Carlos Pignataro (cpignata) <[e-mail] <mailto:[e-mail]>> wrote:
> Hi, Sri,
> 
> Thanks for the response — please see inline.
> 
>> On Apr 29, 2016, at 5:37 PM, Sri <[e-mail] <mailto:[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?
> 
> 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?

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

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

> 
>> 
>> 
>> 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.
> 
> Sri> Does the explanation to the earlier comments suffice?
> 

Not to me, sorry.

> 
>> 
>>       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.
> 
> Sri> Does the explanation to the earlier comments suffice?
> 

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

> 
>> 
>> 
>> 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).
> 
> Sri> Does the explanation to the earlier comments suffice?

Nope.

> 
> 
>> 
>> 
>> 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?
> 
> Sri> Ok. I can change MAY to may. Does earlier explanation about ELC suffice?
> 

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

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

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