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 <[email protected]> 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 <[email protected] > > <mailto:[email protected]>> 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 > > <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Greg,____ > > > > Thanks a lot for your comments.____ > > > > My comments are in-line.____ > > > > __ __ > > > > B.R.____ > > > > Weiqiang Cheng____ > > > > __ __ > > > > *发件人:*Greg Mirsky [mailto:[email protected] > > <mailto:[email protected]>] > > *发送时间:*2019年2月15日3:37 > > *收件人:*Alexander Vainshtein > > *抄送:*[email protected] <mailto:[email protected]>; Stewart Bryant; > > [email protected] > > <mailto:[email protected]>; > > [email protected] <mailto:[email protected]>; 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 > > <[email protected] > > <mailto:[email protected]>> 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: [email protected] > > <mailto:[email protected]>____ > > > > ____ > > > > -----Original Message----- > > From: spring <[email protected] > > <mailto:[email protected]>> On Behalf Of Stewart > Bryant > > Sent: Wednesday, February 13, 2019 12:48 PM > > To: Loa Andersson <[email protected] <mailto:[email protected]>>; > > [email protected] <mailto:[email protected]>; > > [email protected] > > <mailto:[email protected]> > > 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____ > > > > [email protected] <mailto:[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] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/spring____ > > > > _______________________________________________ > > spring mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/spring > > > > -- > > > Loa Andersson email: [email protected] > Senior MPLS Expert > Bronze Dragon Consulting phone: +46 739 81 21 64 >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
