Hi Loa, picture is worth a thousand words, thank you! I think that OAM packet on A-D A-D tunnel will be like this: Couple notes:
- not sure we need s-PSID(B->C) (assuming it is Path SID for the B-C segment); - encapsulation for an OAM packet on the segment B-C must include s-PSID(B->C); - I agree that B->C SubPath must be the same in both cases. Regards, Greg On Sat, Feb 23, 2019 at 12:16 AM Loa Andersson <[email protected]> wrote: > Greg, > > > > On 2019-02-23 12:31, Greg Mirsky wrote: > > Hi Loa, > > another tunnel with the Path segment from node C is, in my view, very > > close to SPME tunnel. The Path segment from C is needed because Path > > segment from D is not known to the node C, cannot be associated with the > > right SR-tunnel segment, i.e., tunnel B-C. The fate sharing may be > > achieved by using exactly the same SIDs as in the A-D tunnel for the B-C > > segment. And GAL is still BoS on B-C tunnel. Are we getting closer? > > Not sure, you lose me somewhere between the "B", "C", "D", "from" and > "another". > > So let me check I was talking about > > So the stack transporting payload from B-C looks like this: > > +------------+ > ~B->C SubPath~ > +------------+ > |s-PSID(B->C)| > +------------+ > | BSID(C->D) | > +------------+ > |e-PSID(A->D)| > +------------+ > figure 1 > > The "~" at the top means that there might be more than one label that > can be popped or swapped, right? > > So the stack transporting GACh from B-C looks like this: > > +--------------+ > ~ B->C SubPath ~ > +--------------+ > | GAL | > +--------------+ > | GACh info-1 | > +--------------+ > | GACh info-2 | > +--------------+ > figure 2 > > Now my question is the "B->C SubPath" in the first figure identical > to the "B->C SubPath" in the second figure? > Now > -- > > > > > > > Regards, > > Greg > > > > On Fri, Feb 22, 2019 at 8:15 PM Loa Andersson <[email protected] > > <mailto:[email protected]>> wrote: > > > > Greg, > > > > We are close, though I hope the rules are that GAL is bottom of > stack, > > and that a packet with a GACh does not carry user payload. > > > > I should have said that "if you want a GACg for the > > > > I don't understand why we need a "new" SR tunnel, the GAL/GACh can > > ride with the GAL as bottom of stack with the label stack for > > Sub-path(B->C), right? If you put it on "another" tunnel, how do > > you guarantee fate sharing? > > > > /Loa > > > > /Loa > > > > On 2019-02-23 11:55, Greg Mirsky wrote: > > > 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] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[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]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[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]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[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]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected] > >>>] > > > > *发送时间:*2019年2月15日3:37 > > > > *收件人:*Alexander Vainshtein > > > > *抄送:*[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>; Stewart Bryant; > > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>>; > > > > [email protected] <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> > > > <mailto:[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] > > <mailto:[email protected]> > > > <mailto:[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]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>>____ > > > > > > > > ____ > > > > > > > > -----Original Message----- > > > > From: spring <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto: > [email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[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] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>>>; > > > > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>>; > > > > [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[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]> > > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>>____ > > > > > > > > https://www..ietf.org/mailman/listinfo/spring____ > > <http://ietf.org/mailman/listinfo/spring____> > > > <http://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]> > > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> > > > > https://www.ietf.org/mailman/listinfo/spring____ > > > > > > > > _______________________________________________ > > > > spring mailing list > > > > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > > -- > > > > > > > > > Loa Andersson email: [email protected] > > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > > > Senior MPLS Expert > > > Bronze Dragon Consulting phone: +46 739 81 21 64 > > > > > > > > > _______________________________________________ > > > spring mailing list > > > [email protected] <mailto:[email protected]> > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > -- > > > > > > Loa Andersson email: [email protected] <mailto: > [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 > > > > -- > > > 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
