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

Greg Mirsky <gregimirsky@gmail.com> Sat, 23 February 2019 16:17 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 687A912958B; Sat, 23 Feb 2019 08:17:30 -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 KwHFNTCxrUEv; Sat, 23 Feb 2019 08:17:26 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 9C0D112426A; Sat, 23 Feb 2019 08:17:25 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id z196so3233656lff.4; Sat, 23 Feb 2019 08:17:25 -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=TE+IhqWup3gNJw00z9WVzdw3CN4hmojA8xZXac/D8IE=; b=NK/fWY7K164Cx0UazVDJ5B/fXsnTWIZZZWus+ZPV9TOi0AUnrkODfu9HGwHukP7MSi +iAYi1l4LyJXuMmOUuGioE3sWYWVQymydn41Xlls5uO7ss1UuuZYCNyq0Rk+ASvhT2O7 v5tfYAnylPjO5kiU1mZGnJaoK7iIUCvf7UV+TgjUXRErA2I2PyzhfGyP0Y57VWhlYYUa 8ZHPplrZ9u2qzFk3ECaNntvS5gyfudBcKKZeALrhg1po6q3bZHldoIwAJBQ9dbCVHwoz BJieVEiKtb5WjwKeEspG0bVQVMEc79lNWZWGsEiBVfJ0sM3eY9hUT0m7+iYDjSxHkgUc qoRA==
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=TE+IhqWup3gNJw00z9WVzdw3CN4hmojA8xZXac/D8IE=; b=SGtuR9LCI9s+klKskJiWmSdtYqX0dXBxJpE1K/gyUjpzrK06oWIaR9hf9S+KVxOK5w p/RbqDTi9WfwRSbCrkNtwZz/gCMLc8Ex+0+gesiRJyLohX4fswX9AnjwDLzzIA+myW1N WIHtb81v/z7j24oJRvZijRTM4yEI5gGsVUrS5oL5nOCYf7GbsuZiDVu0p/eD/1++bZUK 6KohpVSL1mDM6PD8s+rV8K704nMc7cb6N/cFI3vAuWiY/vs+BG99tDCvTqDCC5sXKOWf 16JPq4MGOt8DQfF6WnrbZ2h4XO4VxQZ7fRVwM5C14Btrb/AFgsi0+dTHSYpSVaJKZgWq Hdmw==
X-Gm-Message-State: AHQUAuZpUYIcPIPhKLmM7RgR4n1BX9rpEqr8lAFT2oibkhW2ZAP2WsDg Q4r9QbtotWOurbpNxy/xOKK7Nf5JQxdRhaiROcI=
X-Google-Smtp-Source: AHgI3Ibdk9V+IgkNTnhMw+vfmkfoNvurkio4zr/7sOQyR+YO1WbfUqVHM2bmkn+9uOBioJRSDI/PQ3yKd6g8fQX/BLY=
X-Received: by 2002:a19:f104:: with SMTP id p4mr5538984lfh.37.1550938643067; Sat, 23 Feb 2019 08:17:23 -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> <CA+RyBmW0cPfGFcvGG-eAvBZK9RmiATfhTFEymsurE3bUw3g=FQ@mail.gmail.com> <886d0aeb-281e-984a-9c9d-645101d4d02b@pi.nu>
In-Reply-To: <886d0aeb-281e-984a-9c9d-645101d4d02b@pi.nu>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 23 Feb 2019 08:17:15 -0800
Message-ID: <CA+RyBmXnxkaWFFPVpOLYmWjdMjXRb2SQ46Dh4ruc0Haag4tSbg@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="000000000000e378140582920a57"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/SkelNxnAa0EQJcxVRuLL8o_7r2Y>
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 16:17:31 -0000

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 <loa@pi.nu> 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 <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
>