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

"Chengli (Cheng Li)" <chengli13@huawei.com> Mon, 25 February 2019 02:32 UTC

Return-Path: <chengli13@huawei.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 7FDCA130E98; Sun, 24 Feb 2019 18:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_SPAM=2.5] autolearn=no autolearn_force=no
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 OcYn-NgsJcB6; Sun, 24 Feb 2019 18:32:49 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E452128BCC; Sun, 24 Feb 2019 18:32:49 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7B3435978DEFE0CF7E90; Mon, 25 Feb 2019 02:32:46 +0000 (GMT)
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 25 Feb 2019 02:32:45 +0000
Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.187]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0415.000; Mon, 25 Feb 2019 10:32:42 +0800
From: "Chengli (Cheng Li)" <chengli13@huawei.com>
To: Loa Andersson <loa@pi.nu>, Greg Mirsky <gregimirsky@gmail.com>
CC: "mpls@ietf.org" <mpls@ietf.org>, spring <spring@ietf.org>, Weiqiang Cheng <chengweiqiang@chinamobile.com>, "draft-cheng-spring-mpls-path-segment@ietf.org" <draft-cheng-spring-mpls-path-segment@ietf.org>
Thread-Topic: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment
Thread-Index: AQHUyzC/3+4K0aHNrUy+2rVERdsXgKXsg4cAgANJb0A=
Date: Mon, 25 Feb 2019 02:32:41 +0000
Message-ID: <C7C2E1C43D652C4E9E49FE7517C236CB01AE856E@dggeml529-mbx.china.huawei.com>
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> <CA+RyBmW0cPfGFcvGG-eAvBZK9RmiATfhTFEymsurE3bUw3g=FQ@mail.gmail.com> <886d0aeb-281e-984a-9c9d-645101d4d02b@pi.nu>
In-Reply-To: <886d0aeb-281e-984a-9c9d-645101d4d02b@pi.nu>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.185.75]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/7W_lEbzI6Otlrf1wLqGgIjnSN2w>
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: Mon, 25 Feb 2019 02:32:52 -0000

Hi Loa and Greg,

Yes, you are right.

The "B->C SubPath" in the first figure needs to be identical to the "B->C SubPath" in the second.

Many thanks for your discussion on this, a very interesting question!

Thanks,
Cheng

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Saturday, February 23, 2019 4:16 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: mpls@ietf.org; spring <spring@ietf.org>; Weiqiang Cheng <chengweiqiang@chinamobile.com>; draft-cheng-spring-mpls-path-segment@ietf.org
Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment

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 <loa@pi.nu 
> <mailto: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>
>      > <mailto: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>>
>      >      > <mailto: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>>
>      >      >     <mailto: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>>
>      >      >         <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>>
>      >     <mailto: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>>
>      >      >       
>       <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
>     <mailto:draft-cheng-spring-mpls-path-segment@ietf.org>>>;
>      >      > mpls@ietf.org <mailto:mpls@ietf.org> <mailto:mpls@ietf.org
>     <mailto:mpls@ietf.org>> <mailto: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>
>      >     <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>>
>      >      >             <mailto: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>>
>      >      >             <mailto: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>
>      >     <mailto:loa@pi.nu <mailto:loa@pi.nu>>>>;
>      >      > spring@ietf.org <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org <mailto:spring@ietf.org>>
>     <mailto: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>>
>      >      >           
>       <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
>     <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>>
>     <mailto: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____>
>      >     <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>>
>     <mailto: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>>
>     <mailto: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> <mailto: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 <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

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls