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

Hi Carlos, pls see inline.

On Fri, Apr 29, 2016 at 3:08 PM, Carlos Pignataro (cpignata) <
cpignata@cisco.com> wrote:

> Hi, Sri,
>
> Thanks for the response — please see inline.
>
> On Apr 29, 2016, at 5:37 PM, Sri <sriganeshkini@gmail.com> wrote:
>
> Hi Carlos,
>
> Thanks for your comments. Pls see inline.
>
> On Tue, Apr 26, 2016 at 9:29 PM, Carlos Pignataro (cpignata) <
> cpignata@cisco.com> 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 ..."

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

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

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

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

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

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

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

>
>
>>
>> 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 <gregory.mirsky@ericsson.com>
>> 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:mpls-bounces@ietf.org <mpls-bounces@ietf.org>] *On
>> Behalf Of *George Swallow
>> *Sent:* Monday, April 25, 2016 10:57 AM
>> *To:* Stewart Bryant
>> *Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org;
>>  mpls-chairs@ietf.org
>> *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 <stewart.bryant@gmail.com>
>> 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 (mpls@ietf.org).
>>
>> 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
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>
>