Hi Sasha,

Many thanks for your valuable comments!

Please see my responses inline...

> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander
> Vainshtein
> Sent: Sunday, March 11, 2018 9:44 PM
> To: draft-cheng-spring-mpls-path-segm...@ietf.org
> Cc: spring@ietf.org; Shell Nakash <shell.nak...@ecitele.com>; Michael
> Gorokhovsky <michael.gorokhov...@ecitele.com>; Dmitry Valdman
> <dmitry.vald...@ecitele.com>; Stewart Bryant <stewart.bry...@gmail.com>;
> Ron Sdayoor <ron.sday...@ecitele.com>; Hemmy Yona
> <hemmy.y...@ecitele.com>
> Subject: [spring] Comments on draft-cheng-spring-mpls-path-segment-01
> Dear authors of draft-cheng-spring-mpls-path-segment-01, and I have a few
> comments.
> 1. From my POV, the draft addresses the problem of identifying an incoming SR
> LSP at the tail-end node.
> a. This problem is real because SR LSPs, by their very nature, are MP2P
> (merging) LSPs.
> b. The draft does not try to solve the problem of SR LSP identification in 
> transit
> nodes.

Yes, that's the intention.

> 2. The draft proposes two solutions (one-label and two-label) for the above-
> mentioned problem, and the authors expect the WG to discuss these solutions
> and to select the preferred one. As I see it:
> a. Both uses cases discussed in Section 3 of the draft can be addressed with 
> any
> of these solutions b. IMHO and FWIW, as long as SR-MPLS leaves multicast out
> of scope (as mentioned in Section 6 of the SR Architecture draft), any future
> issue with identification of SR LSPs that can be addressed with the two-label
> solution can also be addressed with the one-label solution c. The two-label
> solution requires support of upstream-allocated labels and context-specific
> label spaces, i.e., adds substantial implementation complexity. The one-label
> solution can be implemented using just per platform label space of
> downstream-allocated labels.
> d. Based on these considerations, my preference (FWIW) is for one-label
> solution.

I also have the same preference as yours. 

> 3. The draft lists both the already mentioned SR Architecture draft and the 
> SR-
> MPLS draft as Informative references, but the SRV6 Routing Header draft
> appears as a Normative reference. From my POV, the first two documents
> MUST be Normative references and the last one - an Informative reference,
> because the draft only deals with SR-MPLS.

Agree, will update it in the next revision.

> Hopefully,  these notes can be useful.

Very useful, as always!


> Regards,
> Sasha
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   alexander.vainsht...@ecitele.com

spring mailing list

Reply via email to