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 <l...@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 <l...@pi.nu
> > <mailto:l...@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
> >     <gregimir...@gmail.com <mailto:gregimir...@gmail.com>
> >      > <mailto:gregimir...@gmail.com <mailto:gregimir...@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
> >      >     <chengweiqi...@chinamobile.com
> >     <mailto:chengweiqi...@chinamobile.com>
> >      >     <mailto:chengweiqi...@chinamobile.com
> >     <mailto:chengweiqi...@chinamobile.com>>> wrote:
> >      >
> >      >         Hi Greg,____
> >      >
> >      >         Thanks a lot for your comments.____
> >      >
> >      >         My comments are in-line.____
> >      >
> >      >         __ __
> >      >
> >      >         B.R.____
> >      >
> >      >         Weiqiang Cheng____
> >      >
> >      >         __ __
> >      >
> >      >         *发件人:*Greg Mirsky [mailto:gregimir...@gmail.com
> >     <mailto:gregimir...@gmail.com>
> >      >         <mailto:gregimir...@gmail.com
> >     <mailto:gregimir...@gmail.com>>]
> >      >         *发送时间:*2019年2月15日3:37
> >      >         *收件人:*Alexander Vainshtein
> >      >         *抄送:*spring@ietf.org <mailto:spr...@ietf..org>
> >     <mailto:spring@ietf.org <mailto:spring@ietf.org>>; Stewart Bryant;
> >      > draft-cheng-spring-mpls-path-segm...@ietf.org
> >     <mailto:draft-cheng-spring-mpls-path-segm...@ietf.org>
> >      >         <mailto:draft-cheng-spring-mpls-path-segm...@ietf.org
> >     <mailto:draft-cheng-spring-mpls-path-segm...@ietf.org>>;
> >      > m...@ietf.org <mailto:m...@ietf.org> <mailto:m...@ietf.org
> >     <mailto:m...@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.vainsht...@ecitele..com
> >      >         <mailto:alexander.vainsht...@ecitele.com
> >     <mailto:alexander.vainsht...@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.vainsht...@ecitele.com
> >     <mailto:alexander.vainsht...@ecitele.com>
> >      >             <mailto:alexander.vainsht...@ecitele.com
> >     <mailto:alexander.vainsht...@ecitele.com>>____
> >      >
> >      >             ____
> >      >
> >      >             -----Original Message-----
> >      >             From: spring <spring-boun...@ietf.org
> >     <mailto:spring-boun...@ietf.org>
> >      >             <mailto:spring-boun...@ietf.org
> >     <mailto:spring-boun...@ietf.org>>> On Behalf Of Stewart Bryant
> >      >             Sent: Wednesday, February 13, 2019 12:48 PM
> >      >             To: Loa Andersson <l...@pi..nu <mailto:l...@pi.nu
> >     <mailto:l...@pi.nu>>>;
> >      > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org
> >     <mailto:spring@ietf.org>>;
> >      > draft-cheng-spring-mpls-path-segm...@ietf.org
> >     <mailto:draft-cheng-spring-mpls-path-segm...@ietf.org>
> >      >             <mailto:draft-cheng-spring-mpls-path-segm...@ietf.org
> >     <mailto:draft-cheng-spring-mpls-path-segm...@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: l...@pi.nu <mailto:
> l...@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: l...@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

Reply via email to