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

[Sri <[e-mail]>]

Hi Carlos,

Thanks for your comments. Pls see inline.

On Tue, Apr 26, 2016 at 9:29 PM, Carlos Pignataro (cpignata) <
[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.


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


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


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


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


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


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


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


>
>
> 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.
>
> 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] <[e-mail]>] *On
> Behalf Of *George Swallow
> *Sent:* Monday, April 25, 2016 10:57 AM
> *To:* Stewart Bryant
> *Cc:* [e-mail]; [e-mail];
> [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]>
> 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]).
>
> 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]
> https://www.ietf.org/mailman/listinfo/mpls
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>