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:spring-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Tuesday, March 13, 2018 4:30 AM
To: Mach Chen <mach.chen@huawei.com>
Cc: spring@ietf.org; Shell Nakash <Shell.Nakash@ecitele.com>; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>; Dmitry Valdman <Dmitry.Valdman@ecitele.com>; draft-cheng-spring-mpls-path-segment@ietf.org; Stewart Bryant <stewart.bryant@gmail.com>; Ron Sdayoor <Ron.Sdayoor@ecitele.com>; Hemmy Yona <Hemmy.Yona@ecitele.com>
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:   Alexander.Vainshtein@ecitele.com

-----Original Message-----
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Mach Chen
Sent: Tuesday, March 13, 2018 1:22 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>; draft-cheng-spring-mpls-path-segment@ietf.org
Cc: spring@ietf.org; Shell Nakash <Shell.Nakash@ecitele.com>; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>; Dmitry Valdman <Dmitry.Valdman@ecitele.com>; Stewart Bryant <stewart.bryant@gmail.com>; Ron Sdayoor <Ron.Sdayoor@ecitele.com>; Hemmy Yona <Hemmy.Yona@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-bounces@ietf.org] On Behalf Of Alexander 
> Vainshtein
> Sent: Sunday, March 11, 2018 9:44 PM
> To: draft-cheng-spring-mpls-path-segment@ietf.org
> Cc: spring@ietf.org; Shell Nakash <Shell.Nakash@ecitele.com>; Michael 
> Gorokhovsky <Michael.Gorokhovsky@ecitele.com>; Dmitry Valdman 
> <Dmitry.Valdman@ecitele.com>; Stewart Bryant 
> <stewart.bryant@gmail.com>; Ron Sdayoor <Ron.Sdayoor@ecitele.com>; 
> Hemmy Yona <Hemmy.Yona@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.Vainshtein@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