Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment
Greg Mirsky <gregimirsky@gmail.com> Sat, 23 February 2019 04:31 UTC
Return-Path: <gregimirsky@gmail.com>
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 6AA80128B33; Fri, 22 Feb 2019 20:31:39 -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 P3Xhd_BGzk52; Fri, 22 Feb 2019 20:31:36 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 A72691228B7; Fri, 22 Feb 2019 20:31:35 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id g2so3225899lfh.11; Fri, 22 Feb 2019 20:31:35 -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=kuSPtQN4RDzVHDf+ZHsA/pUMyR1qmlU7LCgc35R3wSA=; b=ohVxUbzDF9cGnIKXgVBXgfw155OcV8BN85JXsZk3edzuOhBQuoxKkLsSf9YMTQE0aq A4S7V27Lw7WEUSt2AM/IBL1YDhnILWS4o4cnu+wkJUtKl/CK5WLIYF2NL33VtBwel616 1rf1arYhRgFnk/sQ6i/Dh/zaow3Qd+uucJxRRWMZ9yjlcKDAJ6ZC4ksEHPVyUmas55ZC 3w8XXvkjzJN+G8BUzM9mk50EvzaRWzj6Xi2z1hQNafX7ZSrUXu1N09LFpFgPuUEreVFm pgs34wxyi4DKkdLXFXlzS1DiqfvFtrRy2uHUGXWVb5FIhfdyF3/xm6YKxVfg2fUCKCxk 4Lyw==
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=kuSPtQN4RDzVHDf+ZHsA/pUMyR1qmlU7LCgc35R3wSA=; b=DllajXTz9UUcJ6/zbesC5DwlWG1g/M9AsoBJ94wRQ5k6wqNqNujBWoQMmsxV8Mi1MX lfohwBQog5RnMNmy6X+9sVhwmklgtxwyZYkuMNg7DwmHNRn9V72xNW6hcQ8BgzXHwp1a iiZkZ4VPHIa+ihOGOr7yRTgA39BbTDFGcpf+lr68OOoh8lLAekhPmWRxVNI23nBIGFuV C3ld1ILoBp1cuIkWD+NSpZkaPuJKCrJSAi4ORiJqYv9kVa+mExnROodRNalbhoJUrAC+ N8NK3g4xTnXCXJj+uT9VCWfaj9T2nPjtDSaqlE6u+HMJ4erQX9O051wkTB6lxG00Ma24 fFlg==
X-Gm-Message-State: AHQUAuZzHEUBWiVAonZzNmvjW1VMTUuKpDhVtHTVzGFxnj4CUIs74PtH FiceKLNbVt4VRR7ZF67NNt8ZG3Si7qGiIdnLbAU=
X-Google-Smtp-Source: AHgI3IY6NOZOfV7PdU3Vwn9CSN6ww+cXOSgTUDFvkiePIEeYkhZ4Yz5dHhVmxcaJvLLRQeEK1UBoRYxqPcUXH9vC6C8=
X-Received: by 2002:a19:4948:: with SMTP id l8mr4719646lfj.156.1550896293207; Fri, 22 Feb 2019 20:31:33 -0800 (PST)
MIME-Version: 1.0
References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> <AM6PR03MB3830EBBF1D04E91C35E7B8C99D670@AM6PR03MB3830.eurprd03.prod.outlook.com> <CA+RyBmVObxJqsYvntWBR3RWq3=fTs72y-4Zb3mM2aHnmLZZx1A@mail.gmail.com> <050301d4c590$445f5d50$cd1e17f0$@com> <CA+RyBmXjqT385Y5XdrJ++OALNy7QdtDouePM6jt8ZDygAwLxMg@mail.gmail.com> <CAMZsk6fYZ_5aBhNNgOQ7Txvoi9J17D415m_ws5-yQWR2xtn7CA@mail.gmail.com> <9d7a2690-6ef4-438a-6ca8-0548ad2aca0e@pi.nu> <CA+RyBmVnheECq+fJcy27Z3efWuxAdV3tb9aDw_2Rff8aAvksjQ@mail.gmail.com> <13cb42a8-e298-c3cc-d116-219f144f5357@pi.nu>
In-Reply-To: <13cb42a8-e298-c3cc-d116-219f144f5357@pi.nu>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 22 Feb 2019 20:31:22 -0800
Message-ID: <CA+RyBmW0cPfGFcvGG-eAvBZK9RmiATfhTFEymsurE3bUw3g=FQ@mail.gmail.com>
To: Loa Andersson <loa@pi.nu>
Cc: mpls@ietf.org, spring <spring@ietf.org>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Weiqiang Cheng <chengweiqiang@chinamobile.com>, Rakesh Gandhi <rgandhi.ietf@gmail.com>, draft-cheng-spring-mpls-path-segment@ietf.org, Stewart Bryant <stewart.bryant@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a3e39c0582882e44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/oqVX-zaRQTXk-hG5j5npRoHmIeo>
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 <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Feb 2019 04:31:39 -0000
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? Regards, Greg On Fri, Feb 22, 2019 at 8:15 PM Loa Andersson <loa@pi.nu> 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 <loa@pi.nu > > <mailto: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> > > > <mailto: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> > > > <mailto: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> > > > <mailto:gregimirsky@gmail.com > > <mailto:gregimirsky@gmail.com>>] > > > *发送时间:*2019年2月15日3:37 > > > *收件人:*Alexander Vainshtein > > > *抄送:*spring@ietf.org <mailto:spring@ietf.org> > > <mailto: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> > > > <mailto:draft-cheng-spring-mpls-path-segment@ietf.org > > <mailto:draft-cheng-spring-mpls-path-segment@ietf.org>>; > > > mpls@ietf.org <mailto:mpls@ietf.org> <mailto: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 > > <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> > > > <mailto:Alexander.Vainshtein@ecitele.com > > <mailto:Alexander.Vainshtein@ecitele.com>>____ > > > > > > ____ > > > > > > -----Original Message----- > > > From: spring <spring-bounces@ietf.org > > <mailto:spring-bounces@ietf.org> > > > <mailto: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 > > <mailto:loa@pi.nu>>>; > > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org > > <mailto:spring@ietf.org>>; > > > draft-cheng-spring-mpls-path-segment@ietf.org > > <mailto:draft-cheng-spring-mpls-path-segment@ietf.org> > > > <mailto: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> <mailto:spring@ietf.org > > <mailto:spring@ietf.org>>____ > > > > > > https://www..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 > > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org > > <mailto:spring@ietf.org>> > > > https://www.ietf.org/mailman/listinfo/spring____ > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org > > <mailto:spring@ietf.org>> > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > -- > > > > > > Loa Andersson email: loa@pi.nu <mailto: > loa@pi.nu> > > Senior MPLS Expert > > Bronze Dragon Consulting phone: +46 739 81 21 64 > > > > > > _______________________________________________ > > 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 >
- Re: [mpls] [spring] to progress draft-cheng-sprin… Alexander Vainshtein
- Re: [mpls] [spring] to progress draft-cheng-sprin… Greg Mirsky
- [mpls] 答复: [spring] to progress draft-cheng-sprin… Weiqiang Cheng
- Re: [mpls] [spring] to progress draft-cheng-sprin… Greg Mirsky
- Re: [mpls] [spring] to progress draft-cheng-sprin… Rakesh Gandhi
- Re: [mpls] [spring] to progress draft-cheng-sprin… Loa Andersson
- Re: [mpls] [spring] to progress draft-cheng-sprin… Greg Mirsky
- Re: [mpls] [spring] to progress draft-cheng-sprin… Loa Andersson
- Re: [mpls] [spring] to progress draft-cheng-sprin… Greg Mirsky
- Re: [mpls] [spring] to progress draft-cheng-sprin… Loa Andersson
- Re: [mpls] [spring] to progress draft-cheng-sprin… Greg Mirsky
- Re: [mpls] [spring] to progress draft-cheng-sprin… Chengli (Cheng Li)
- Re: [mpls] [spring] to progress draft-cheng-sprin… Royi Zigler