Hi Sasha, Thanks for your prompt response!
Section 2.1.1 discusses some potential directions for Path segment ID assignment and distribution, there are several ways that can be used. IGP based solution is good for the case where more nodes within the domain needs to learn the Path Segment ID. For the use cases as mentioned in Section 3, the nodes that need to learn the Path Segment ID are mainly the ingress LSR. For a centralized model, the centralized controller may also need to learn the Path Segment ID. So, for these use case, a point-2-point model (e.g., BGP) or request/reply model (e.g., PCEP) seems more suitable. How do you think? Best regards, Mach > -----Original Message----- > From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com] > Sent: Tuesday, March 13, 2018 7:30 PM > To: Mach Chen <mach.c...@huawei.com> > 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>; draft-cheng-spring-mpls-path-segm...@ietf.org > Subject: RE: Comments on draft-cheng-spring-mpls-path-segment-01 > > Mach, > Lots of thanks for a prompt and very encouraging response! > One more question: > > Do you and your colleagues plan to define the mechanism for distribution of > the Path Segment ID in IGP? > (Usually such mechanisms are defined in dedicated drafts separately for OSPF > and ISIS, but, at least, it should be nice to mention the fact in the draft). > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: alexander.vainsht...@ecitele.com > > -----Original Message----- > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Mach Chen > Sent: Tuesday, March 13, 2018 1:22 PM > To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>; 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: Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01 > > 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! > > Thanks, > Mach > > > > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: alexander.vainsht...@ecitele.com > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > ________________________________________________________________ > ___________ > > This e-mail message is intended for the recipient only and contains > information > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this transmission in error, please inform us by e-mail, phone or > fax, and then delete the original and all copies thereof. > ________________________________________________________________ > ___________ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
