Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC40130EBD; Fri, 22 Feb 2019 19:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_SPAM=2.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NtFJVdRWczE; Fri, 22 Feb 2019 19:56:01 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7B71288BD; Fri, 22 Feb 2019 19:56:00 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id m11so3215018lfc.6; Fri, 22 Feb 2019 19:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=++F7H6NcceQJXOwjR5Ml6zlNL91pRWIGtNW0SEe8Krc=; b=f3eXBtZAaBQTvoaL2ScUkP3arbrGwavuMEmIrbtTvdIvy5gvcbWb6tTVgCOSda2t0O bl4JWI3wML5z9VAeZ1kyo2YwPGs2gQU4hRxVZ5Wxdp4rjTEAhkzYCkk5o57E8fFrfud9 WTCFDdP0Nimknbf1TxMUPRlKmCxhKM4LlcppttVV6sqVdo/eG2M+scd63YJhd6qrLdKk 7uO6Purc2M6thFwRa2imZB3fxhr8OCC4CBlTMPER0HEQeWCPtz4N9Zp2GRA991Kaegqr GOzunb10ikB+mOTuh/fAD9pgvee8Asqc/oSAKs1BUbP4Guze5nt8bmrA7sR5KwhtgSJ3 4X/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=++F7H6NcceQJXOwjR5Ml6zlNL91pRWIGtNW0SEe8Krc=; b=GyJKIKIen9d2dv6FvjnZqq4MXe+itwjKzx6YDMCGC7nxO+cqfZXAqmnduWojXLIaaM NJUv5HvfjV8dFyNKu+cEwZWFoVk8K033IyW08sYT8qnmQxDIxZtXpR0L7JIVrM5VRABt zs/uVPhhSDVi160ZiIIRWkUxhtXo1mCjZS1P9D+ANy6uh9odUDHatMy82c0aYsx2g1/p R6m8b/XQM/b2zgvsum53zPtsgv2M0ITtyxP8b8UzGbDcg4+MErCbCs6puBlKW4RgPe0V 41n4p4/OmDb7G3ZXNT8HIb5Z+8nL1pXFwT6nt4r2J2I/3FomK7kGmLOjXsQtoEL7yt3C BmbQ== X-Gm-Message-State: AHQUAuagvG2EBhDCXEP6zB1IATATitU87o0YfJIf1WwHfUc85R5ld7tH zPT/9q3bmJyof4tU4yhc7tmox4lVIjATnyzOrwM= X-Google-Smtp-Source: AHgI3IYGHwiwF5kS5oZ0T+HtYZqQ9eh9vQNWkNAVPJ8cvn2JJJ+riZWT2UH7HAk9nZsWkxpWcTl8Gci9PsbRaICPrp0= X-Received: by 2002:a19:260e:: with SMTP id m14mr4548024lfm.158.1550894158065; Fri, 22 Feb 2019 19:55:58 -0800 (PST) MIME-Version: 1.0 References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> <050301d4c590$445f5d50$cd1e17f0$@com> <9d7a2690-6ef4-438a-6ca8-0548ad2aca0e@pi.nu> In-Reply-To: <9d7a2690-6ef4-438a-6ca8-0548ad2aca0e@pi.nu> From: Greg Mirsky Date: Fri, 22 Feb 2019 19:55:49 -0800 Message-ID: To: Loa Andersson Cc: Rakesh Gandhi , Weiqiang Cheng , mpls@ietf.org, spring , Alexander Vainshtein , draft-cheng-spring-mpls-path-segment@ietf.org, Stewart Bryant Content-Type: multipart/alternative; boundary="000000000000603427058287af50" Archived-At: Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 03:56:04 -0000 --000000000000603427058287af50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 a= t > > the bottom of the label stack. > > > > Thanks, > > Rakesh > > > > > > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky > > 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 i= n > > SR-MPLS environment. Of course, the type of the encapsulated messag= e > > 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 > > > > wrote: > > > > Hi Greg,____ > > > > Thanks a lot for your comments.____ > > > > My comments are in-line.____ > > > > __ __ > > > > B.R.____ > > > > Weiqiang Cheng____ > > > > __ __ > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:*Greg Mirsky [mailto:gregimirsky@g= mail.com > > ] > > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:*2019=E5=B9=B42=E6=9C=881= 5=E6=97=A53:37 > > *=E6=94=B6=E4=BB=B6=E4=BA=BA:*Alexander Vainshtein > > *=E6=8A=84=E9=80=81:*spring@ietf.org ; = Stewart Bryant; > > draft-cheng-spring-mpls-path-segment@ietf.org > > ; > > mpls@ietf.org ; Loa Andersson > > *=E4=B8=BB=E9=A2=98:*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 solutio= n > > 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 > > > > 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 basi= c > > requirements for the WG adoption:____ > > > > 1.It addresses a real and relevant problem, namely the MPLS > > Flow Identification problem discussed in general in RFC 837= 2 > > and scoped to SR-MPLS > > LSPs in this draft. Specifics of SR-MPLS include the need t= o > > provide end-to-end liveness check that is one of the > > requirements explicitly specified in Section 2 of RFC 8355 > > . ____ > > > > 2.It provides a reasonable (from my POV) approach to > > solution of this problem.____ > > > > ____ > > > > I also concur with Stewart=E2=80=99s comment about strong s= imilarity > > 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 thi= s > > is yet another indication that the draft should be > adopted.____ > > > > ____ > > > > My 2c,____ > > > > Sasha____ > > > > ____ > > > > Office: +972-39266302____ > > > > Cell: +972-549266302____ > > > > Email: Alexander.Vainshtein@ecitele.com > > ____ > > > > ____ > > > > -----Original Message----- > > From: spring > > On Behalf Of Stewart > Bryant > > Sent: Wednesday, February 13, 2019 12:48 PM > > To: Loa Andersson >; > > spring@ietf.org ; > > 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 ____ > > > > 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. I= f > > 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____ > > > > _______________________________________________ > > spring mailing list > > 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 > --000000000000603427058287af50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 b= y node C. But GAL will still be BoS.

Regards,
Greg.=C2=A0

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:
>
>=C2=A0 =C2=A0 =C2=A0Hi=C2=A0Weiqiang Cheng,
>=C2=A0 =C2=A0 =C2=A0thank you for your expedient response to my questio= ns. The document
>=C2=A0 =C2=A0 =C2=A0states that one of the use cases for the Path segme= nt is to be used
>=C2=A0 =C2=A0 =C2=A0as a performance, packet loss and/or delay, measure= ment session
>=C2=A0 =C2=A0 =C2=A0identifier. I think that RFC 6374 is the most suita= ble for PM OAM in
>=C2=A0 =C2=A0 =C2=A0SR-MPLS environment. Of course, the type of the enc= apsulated=C2=A0message
>=C2=A0 =C2=A0 =C2=A0can be identified using the destination UDP port nu= mber with IP/UDP
>=C2=A0 =C2=A0 =C2=A0encapsulation. But another option is to use G-ACh e= ncapsulation.
>=C2=A0 =C2=A0 =C2=A0That would require the use of GAL. And that is how = I've arrived at
>=C2=A0 =C2=A0 =C2=A0my original question (I should have explained it be= tter, my apologies):
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0How the Path segment and GAL are plac= ed relative to each other
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the SR-MPLS label stack?
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng
>=C2=A0 =C2=A0 =C2=A0<chengweiqiang@chinamobile.com
>=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobile.com>> wrote:=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Greg,____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks a lot for your comments.____ >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0My comments are in-line.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B.R.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Weiqiang Cheng____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E5=8F=91=E4=BB=B6=E4=BA=BA:*Greg Mi= rsky [mailto:gre= gimirsky@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4= :*2019=E5=B9=B42=E6=9C=8815=E6=97=A53:37
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E6=94=B6=E4=BB=B6=E4=BA=BA:*Alexand= er Vainshtein
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E6=8A=84=E9=80=81:*spring@ietf.org <mailto:spring@ietf.org>; Stew= art Bryant;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-cheng-spring-mpls-path-= segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring= -mpls-path-segment@ietf.org>;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mpls@ietf.org <mailto:mpls@ietf.org>; Loa Andersson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E4=B8=BB=E9=A2=98:*Re: [spring] to = progress
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-cheng-spring-mpls-path-segment_= ___
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear All,____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I concur with all what has been said = in support of the adoption
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of this draft by SPRING WG. The docum= ent is well-written,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses the real problem in SR-MPLS= , and the proposed solution
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is technically viable.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0My comments and questions are entirel= y for further discussion:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* would the=C2=A0draft be expa= nded to demonstrate how "the Path
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Segment may be used to = identify an SR-MPLS Policy, its
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Candidate-Path (CP) or = a SID List (SL)"?____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Weiqiang] Yes, It is necessary and= =C2=A0we will add some text to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0demonstrate this in the future versio= n. ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* as many use cases for the Pa= th Segment are related to OAM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operations, it would be= helpful to expand on the use of GAL
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the Path Segment.__= __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Weiqiang] It is always helpful to ha= ve more use cases. However,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The GAL is used today in MPLS-TP LSPs= to flag the G-Ach and is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0used for OAM packets only while the P= ath segment is used for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data packets for the each traffic flo= w. It is a little bit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different. ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Thu, Feb 14, 2019 at 1:12 AM Alexa= nder Vainshtein
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<Alexander.Vainshtein@ecitele..com=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.co= m>> wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+1.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I have been following t= his draft from its -00 revision. The
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0current revision has re= solved most of the issues I (and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0others) have been raise= d (e.g., elimination of excessive
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0options).____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 From my POV, in its cu= rrent state the draft meets two basic
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requirements for the WG= adoption:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01.It addresses a real a= nd relevant problem, namely the MPLS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Flow Identification pro= blem discussed in general in RFC 8372
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://t= ools.ietf.org/html/rfc8372> and scoped to SR-MPLS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LSPs in this draft. Spe= cifics of SR-MPLS include the need to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0provide end-to-end live= ness check that is one of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requirements explicitly= specified in Section 2 of RFC 8355
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://t= ools.ietf.org/html/rfc8355>. ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02.It provides a reasona= ble (from my POV) approach to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0solution of this= problem.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I also concur with Stew= art=E2=80=99s comment about strong similarity
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0between the approach ta= ken in this draft for SR-MPLS and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generic work in progres= s on synonymous flow labels
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-0= 4>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that has been already a= dopted as a MPLS WG item.=C2=A0 To me this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is yet another indicati= on that the draft should be adopted.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0My 2c,____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sasha____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Office: +972-39266302__= __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cell:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +972-549266302____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Email: Alexander.Vainshtein@= ecitele.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainsht= ein@ecitele.com>____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----Original Message--= ---
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: spring <spring-bounces@ietf.= org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org>> On Behalf Of Stewart Bryant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sent: Wednesday, Februa= ry 13, 2019 12:48 PM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Loa Andersson <l= oa@pi..nu <mailto:loa@pi.= nu>>;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spring@ietf.org <mailto:spring@ietf.org>;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-cheng-spr= ing-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:draf= t-cheng-spring-mpls-path-segment@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: Re: [spring] t= o progress
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-cheng-spring-mpls= -path-segment____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I have just read the dr= aft and agree that it should be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0adopted by the WG. It s= olves an important problem in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0instrumenting and prote= cting an SR path.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It should be noted that= we needed to do something very
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0similar in mainstream M= PLS via the synonymous label work
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which is already adopte= d. ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0However SL did not addr= ess the SR case.. We therefore need
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this path label work to= be progressed.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Stewart____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 10/02/2019 08:11, Lo= a Andersson wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Working Group,____=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I have reviewed dr= aft-cheng-spring-mpls-path-segment and as far as I ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> can see, it is rea= dy for wg adoption.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> There were some co= mments in Bangkok, but due to the many collisions ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> between working gr= oups at that meeting I couldn't attend the SPRING ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> f2f.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> The minutes are no= t clear, but as far as I understand, there is ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> nothing that can&#= 39;t be resolved in the wg process.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> /Loa____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ____________________________
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spring mailing list____=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spring@ietf.org <mailto:spring@ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www..i= etf.org/mailman/listinfo/spring____
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ____________________________________________________
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This e-mail message is = intended for the recipient only and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0contains information wh= ich is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CONFIDENTIAL and which = may be proprietary to ECI Telecom. If
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you have received this<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transmission in error, = please inform us by e-mail, phone or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fax, and then delete th= e original
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and all copies thereof.=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________________________________________
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spring mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://www.ietf.org/mailman/listinfo/spring____
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0spring mailing list
>=C2=A0 =C2=A0 =C2=A0spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/lis= tinfo/spring
>

--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pho= ne: +46 739 81 21 64
--000000000000603427058287af50--