Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

[Alexander Vainshtein <[e-mail]>]

Uma,

Lots of thanks for bringing the draft in question<https://www.ietf.org/id/draft-ct-isis-nspfid-for-sr-paths-00.txt> to my attention.



Regards,

Sasha



Office: [phone]

Cell:      [phone]

Email:   [e-mail]





-----Original Message-----
From: Uma Chunduri [mailto:[e-mail]]
Sent: Tuesday, March 13, 2018 5:52 PM
To: Alexander Vainshtein <[e-mail]>; Mach Chen <[e-mail]>
Cc: [e-mail]; Shell Nakash <[e-mail]>; Michael Gorokhovsky <[e-mail]>; Dmitry Valdman <[e-mail]>; [e-mail]; Stewart Bryant <[e-mail]>; Ron Sdayoor <[e-mail]>; Hemmy Yona <[e-mail]>
Subject: RE: 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:[e-mail]] On Behalf Of Alexander Vainshtein

Sent: Tuesday, March 13, 2018 4:30 AM

To: Mach Chen <[e-mail]<mailto:[e-mail]>>

Cc: [e-mail]<mailto:[e-mail]>; Shell Nakash <[e-mail]<mailto:[e-mail]>>; Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>; Dmitry Valdman <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; Ron Sdayoor <[e-mail]<mailto:[e-mail]>>; Hemmy Yona <[e-mail]<mailto:[e-mail]>>

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: [phone]

Cell:      [phone]

Email:   [e-mail]<mailto:[e-mail]>



-----Original Message-----

From: spring [mailto:[e-mail]] On Behalf Of Mach Chen

Sent: Tuesday, March 13, 2018 1:22 PM

To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>; Shell Nakash <[e-mail]<mailto:[e-mail]>>; Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>; Dmitry Valdman <[e-mail]<mailto:[e-mail]>>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; Ron Sdayoor <[e-mail]<mailto:[e-mail]>>; Hemmy Yona <[e-mail]<mailto:[e-mail]>>

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:[e-mail]] On Behalf Of Alexander

> Vainshtein

> Sent: Sunday, March 11, 2018 9:44 PM

> To: [e-mail]<mailto:[e-mail]>

> Cc: [e-mail]<mailto:[e-mail]>; Shell Nakash <[e-mail]<mailto:[e-mail]>>; Michael

> Gorokhovsky <[e-mail]<mailto:[e-mail]>>; Dmitry Valdman

> <[e-mail]<mailto:[e-mail]>>; Stewart Bryant

> <[e-mail]<mailto:[e-mail]>>; Ron Sdayoor <[e-mail]<mailto:[e-mail]>>;

> Hemmy Yona <[e-mail]<mailto:[e-mail]>>

> 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: [phone]

> Cell:      [phone]

> Email:   [e-mail]<mailto:[e-mail]>

>

>



_______________________________________________

spring mailing list

[e-mail]<mailto:[e-mail]>

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

[e-mail]<mailto:[e-mail]>

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