Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment

Hi Loa,
I think it will be similar to SPME and we'll need to have another SR-tunnel
B-C with its own Path segment allocated by node C. But GAL will still be
BoS.

Regards,
Greg.

On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson <loa@pi.nu> wrote:

> Rakesh, authors,
>
> I have not been thinking about this too much. But if you look at fig 2
> of draft-cheng-spring-mpls-path-segment, and you need a GACh between
> A and D, I'd say that the GAL will be at the bottom of stack.
>
> What if you need the CACh for the sub-path B to C, where will the GAL
> go?
>
> /Loa
>
>
>
> On 2019-02-23 09:25, Rakesh Gandhi wrote:
> > Hi Greg,
> >
> > I am not sure if the question has been answered. I would think GAL is at
> > the bottom of the label stack.
> >
> > Thanks,
> > Rakesh
> >
> >
> > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky <gregimirsky@gmail.com
> > <mailto:gregimirsky@gmail.com>> wrote:
> >
> >     Hi Weiqiang Cheng,
> >     thank you for your expedient response to my questions. The document
> >     states that one of the use cases for the Path segment is to be used
> >     as a performance, packet loss and/or delay, measurement session
> >     identifier. I think that RFC 6374 is the most suitable for PM OAM in
> >     SR-MPLS environment. Of course, the type of the encapsulated message
> >     can be identified using the destination UDP port number with IP/UDP
> >     encapsulation. But another option is to use G-ACh encapsulation.
> >     That would require the use of GAL. And that is how I've arrived at
> >     my original question (I should have explained it better, my
> apologies):
> >
> >         How the Path segment and GAL are placed relative to each other
> >         in the SR-MPLS label stack?
> >
> >     Regards,
> >     Greg
> >
> >     On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng
> >     <chengweiqiang@chinamobile.com
> >     <mailto:chengweiqiang@chinamobile.com>> wrote:
> >
> >         Hi Greg,____
> >
> >         Thanks a lot for your comments.____
> >
> >         My comments are in-line.____
> >
> >         __ __
> >
> >         B.R.____
> >
> >         Weiqiang Cheng____
> >
> >         __ __
> >
> >         *发件人:*Greg Mirsky [mailto:gregimirsky@gmail.com
> >         <mailto:gregimirsky@gmail.com>]
> >         *发送时间:*2019年2月15日3:37
> >         *收件人:*Alexander Vainshtein
> >         *抄送:*spring@ietf.org <mailto:spring@ietf.org>; Stewart Bryant;
> >         draft-cheng-spring-mpls-path-segment@ietf.org
> >         <mailto:draft-cheng-spring-mpls-path-segment@ietf.org>;
> >         mpls@ietf.org <mailto:mpls@ietf.org>; Loa Andersson
> >         *主题:*Re: [spring] to progress
> >         draft-cheng-spring-mpls-path-segment____
> >
> >         __ __
> >
> >         Dear All,____
> >
> >         I concur with all what has been said in support of the adoption
> >         of this draft by SPRING WG. The document is well-written,
> >         addresses the real problem in SR-MPLS, and the proposed solution
> >         is technically viable.____
> >
> >         My comments and questions are entirely for further
> discussion:____
> >
> >           * would the draft be expanded to demonstrate how "the Path
> >             Segment may be used to identify an SR-MPLS Policy, its
> >             Candidate-Path (CP) or a SID List (SL)"?____
> >
> >         [Weiqiang] Yes, It is necessary and we will add some text to
> >         demonstrate this in the future version. ____
> >
> >           * as many use cases for the Path Segment are related to OAM
> >             operations, it would be helpful to expand on the use of GAL
> >             and the Path Segment.____
> >
> >         [Weiqiang] It is always helpful to have more use cases. However,
> >         The GAL is used today in MPLS-TP LSPs to flag the G-Ach and is
> >         used for OAM packets only while the Path segment is used for
> >         data packets for the each traffic flow. It is a little bit
> >         different. ____
> >
> >         Regards,____
> >
> >         Greg____
> >
> >         __ __
> >
> >         On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein
> >         <Alexander.Vainshtein@ecitele..com
> >         <mailto:Alexander.Vainshtein@ecitele.com>> wrote:____
> >
> >             +1.____
> >
> >             ____
> >
> >             I have been following this draft from its -00 revision. The
> >             current revision has resolved most of the issues I (and
> >             others) have been raised (e.g., elimination of excessive
> >             options).____
> >
> >             ____
> >
> >              From my POV, in its current state the draft meets two basic
> >             requirements for the WG adoption:____
> >
> >             1.It addresses a real and relevant problem, namely the MPLS
> >             Flow Identification problem discussed in general in RFC 8372
> >             <https://tools.ietf.org/html/rfc8372> and scoped to SR-MPLS
> >             LSPs in this draft. Specifics of SR-MPLS include the need to
> >             provide end-to-end liveness check that is one of the
> >             requirements explicitly specified in Section 2 of RFC 8355
> >             <https://tools.ietf.org/html/rfc8355>. ____
> >
> >             2.It provides a reasonable (from my POV) approach to
> >               solution of this problem.____
> >
> >             ____
> >
> >             I also concur with Stewart’s comment about strong similarity
> >             between the approach taken in this draft for SR-MPLS and
> >             generic work in progress on synonymous flow labels
> >             <
> https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04>
> >             that has been already adopted as a MPLS WG item.  To me this
> >             is yet another indication that the draft should be
> adopted.____
> >
> >             ____
> >
> >             My 2c,____
> >
> >             Sasha____
> >
> >             ____
> >
> >             Office: +972-39266302____
> >
> >             Cell:      +972-549266302____
> >
> >             Email: Alexander.Vainshtein@ecitele.com
> >             <mailto:Alexander.Vainshtein@ecitele.com>____
> >
> >             ____
> >
> >             -----Original Message-----
> >             From: spring <spring-bounces@ietf.org
> >             <mailto:spring-bounces@ietf.org>> On Behalf Of Stewart
> Bryant
> >             Sent: Wednesday, February 13, 2019 12:48 PM
> >             To: Loa Andersson <loa@pi..nu <mailto:loa@pi.nu>>;
> >             spring@ietf.org <mailto:spring@ietf.org>;
> >             draft-cheng-spring-mpls-path-segment@ietf.org
> >             <mailto:draft-cheng-spring-mpls-path-segment@ietf.org>
> >             Subject: Re: [spring] to progress
> >             draft-cheng-spring-mpls-path-segment____
> >
> >             ____
> >
> >             I have just read the draft and agree that it should be
> >             adopted by the WG. It solves an important problem in
> >             instrumenting and protecting an SR path.____
> >
> >             ____
> >
> >             It should be noted that we needed to do something very
> >             similar in mainstream MPLS via the synonymous label work
> >             which is already adopted. ____
> >
> >             However SL did not address the SR case.. We therefore need
> >             this path label work to be progressed.____
> >
> >             ____
> >
> >             - Stewart____
> >
> >             ____
> >
> >             On 10/02/2019 08:11, Loa Andersson wrote:____
> >
> >             > Working Group,____
> >
> >             > ____
> >
> >             > I have reviewed draft-cheng-spring-mpls-path-segment and
> as far as I ____
> >
> >             > can see, it is ready for wg adoption.____
> >
> >             > ____
> >
> >             > There were some comments in Bangkok, but due to the many
> collisions ____
> >
> >             > between working groups at that meeting I couldn't attend
> the SPRING ____
> >
> >             > f2f.____
> >
> >             > ____
> >
> >             > The minutes are not clear, but as far as I understand,
> there is ____
> >
> >             > nothing that can't be resolved in the wg process.____
> >
> >             > ____
> >
> >             > /Loa____
> >
> >             ____
> >
> >             ___________________________________________________
> >
> >             spring mailing list____
> >
> >             spring@ietf.org <mailto: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 <mailto:spring@ietf.org>
> >             https://www.ietf.org/mailman/listinfo/spring____
> >
> >     _______________________________________________
> >     spring mailing list
> >     spring@ietf.org <mailto:spring@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/spring
> >
>
> --
>
>
> Loa Andersson                        email: loa@pi.nu
> Senior MPLS Expert
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>