Sorry, minor correction: 3GPP SA2 ==> 3GPP CT4
And it helps most of the proposals including SRH, SR-MPLS, LISP, ILA (?) .. Best, -- Uma C. -----Original Message----- From: spring [mailto:[email protected]] On Behalf Of Uma Chunduri Sent: Tuesday, March 13, 2018 8:52 AM To: Alexander Vainshtein <[email protected]>; Mach Chen <[email protected]> Cc: [email protected]; Shell Nakash <[email protected]>; Michael Gorokhovsky <[email protected]>; Dmitry Valdman <[email protected]>; [email protected]; Stewart Bryant <[email protected]>; Ron Sdayoor <[email protected]>; Hemmy Yona <[email protected]> Subject: Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01 We recently published a 00 version, undergoing an update to be published during IETF week (presented @ LSR WG). It addresses label stack reduction for any non-shortest path LSPs including an optional path traffic statistics. https://www.ietf.org/mail-archive/web/dmm/current/msg03162.html It would help for SRH more when it comes to TE path. Check out DMM WG (3GPP SA2 study & proposals) discussions off late. Best, -- Uma C. -----Original Message----- From: spring [mailto:[email protected]] On Behalf Of Alexander Vainshtein Sent: Tuesday, March 13, 2018 4:30 AM To: Mach Chen <[email protected]> Cc: [email protected]; Shell Nakash <[email protected]>; Michael Gorokhovsky <[email protected]>; Dmitry Valdman <[email protected]>; [email protected]; Stewart Bryant <[email protected]>; Ron Sdayoor <[email protected]>; Hemmy Yona <[email protected]> Subject: Re: [spring] 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: [email protected] -----Original Message----- From: spring [mailto:[email protected]] On Behalf Of Mach Chen Sent: Tuesday, March 13, 2018 1:22 PM To: Alexander Vainshtein <[email protected]>; [email protected] Cc: [email protected]; Shell Nakash <[email protected]>; Michael Gorokhovsky <[email protected]>; Dmitry Valdman <[email protected]>; Stewart Bryant <[email protected]>; Ron Sdayoor <[email protected]>; Hemmy Yona <[email protected]> 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:[email protected]] On Behalf Of Alexander > Vainshtein > Sent: Sunday, March 11, 2018 9:44 PM > To: [email protected] > Cc: [email protected]; Shell Nakash <[email protected]>; Michael > Gorokhovsky <[email protected]>; Dmitry Valdman > <[email protected]>; Stewart Bryant > <[email protected]>; Ron Sdayoor <[email protected]>; > Hemmy Yona <[email protected]> > 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: [email protected] > > _______________________________________________ spring mailing list [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
