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: firstname.lastname@example.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! Thanks, Mach > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: alexander.vainsht...@ecitele.com > > _______________________________________________ spring mailing list email@example.com https://www.ietf.org/mailman/listinfo/spring