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

[Loa Andersson <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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
>     <[e-mail] <mailto:[e-mail]>
>      > <mailto:[e-mail] <mailto:[e-mail]>>> 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
>      >     <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
>      >
>      >         Hi Greg,____
>      >
>      >         Thanks a lot for your comments.____
>      >
>      >         My comments are in-line.____
>      >
>      >         __ __
>      >
>      >         B.R.____
>      >
>      >         Weiqiang Cheng____
>      >
>      >         __ __
>      >
>      >         *发件人:*Greg Mirsky [mailto:[e-mail]
>     <mailto:[e-mail]>
>      >         <mailto:[e-mail]
>     <mailto:[e-mail]>>]
>      >         *发送时间:*2019年2月15日3:37
>      >         *收件人:*Alexander Vainshtein
>      >         *抄送:*[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>; Stewart Bryant;
>      > [e-mail]
>     <mailto:[e-mail]>
>      >         <mailto:[e-mail]
>     <mailto:[e-mail]>>;
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>; 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:[e-mail]
>     <mailto:[e-mail]>>> 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: [phone]____
>      >
>      >             Cell:      [phone]____
>      >
>      >             Email: [e-mail]
>     <mailto:[e-mail]>
>      >             <mailto:[e-mail]
>     <mailto:[e-mail]>>____
>      >
>      >             ____
>      >
>      >             -----Original Message-----
>      >             From: spring <[e-mail]
>     <mailto:[e-mail]>
>      >             <mailto:[e-mail]
>     <mailto:[e-mail]>>> On Behalf Of Stewart Bryant
>      >             Sent: Wednesday, February 13, 2019 12:48 PM
>      >             To: Loa Andersson <loa@pi..nu <mailto:[e-mail]
>     <mailto:[e-mail]>>>;
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>;
>      > [e-mail]
>     <mailto:[e-mail]>
>      >             <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >             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____
>      >
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>____
>      >
>      > 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
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/spring____
>      >
>      >     _______________________________________________
>      >     spring mailing list
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/spring
>      >
> 
>     -- 
> 
> 
>     Loa Andersson                        email: [e-mail] <mailto:[e-mail]>
>     Senior MPLS Expert
>     Bronze Dragon Consulting             phone: [phone]
> 
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
> 

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]