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

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Feb 2019 09:11:59 +0000

+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:   [email-masked]

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Stewart Bryant
Sent: Wednesday, February 13, 2019 12:48 PM
To: Loa Andersson <[email-masked]>; [email-masked]; [email-masked]
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

[email-masked]<mailto:[email-masked]>

https://www.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.
___________________________________________________________________________

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 14 Feb 2019 11:37:24 -0800

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)"?
   - 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.

Regards,
Greg

On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein <
[email-masked]> 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).
>
>
>
> 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>.
>
> 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
>
> To: Loa Andersson <[email-masked]>; [email-masked];
> [email-masked]
> 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.
>
> [email-masked]
> https://www..ietf.org/mailman/listinfo/spring
> <https://www.ietf.org/mailman/listinfo/spring>
>
> [email-masked]

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Sat, 16 Feb 2019 08:40:49 +0800

Hi Greg,

Thanks a lot for your comments.

My comments are in-line.

B.R.

Weiqiang Cheng

发件人: Greg Mirsky [mailto:[email-masked]] 
发送时间: 2019年2月15日 3:37
收件人: Alexander Vainshtein
抄送: [email-masked]; Stewart Bryant; [email-masked]; [email-masked]; 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.

*	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 <[email-masked]> wrote:

+1.

>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> . 

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

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Stewart Bryant
Sent: Wednesday, February 13, 2019 12:48 PM
To: Loa Andersson <loa@pi..nu <mailto:[email-masked]> >; [email-masked]; [email-masked]
Subject: Re: [spring] to progress draft-cheng-spring-mpls-path-segment

- Stewart

spring mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www..ietf.org/mailman/listinfo/spring> https://www..ietf.org/mailman/listinfo/spring

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 16 Feb 2019 13:24:09 -0800

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 <
[email-masked]> wrote:

> *发件人:* Greg Mirsky [mailto:[email-masked]]
> *发送时间:* 2019年2月15日 3:37
> *收件人:* Alexander Vainshtein
> *抄送:* [email-masked]; Stewart Bryant;
> [email-masked]; [email-masked]; Loa
> Andersson
> *主题:* Re: [spring] to progress draft-cheng-spring-mpls-path-segment
>
>
>
> Dear All,
>
>    - 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
>
>
>
> To: Loa Andersson <loa@pi..nu <[email-masked]>>; [email-masked];

---

From: Rakesh Gandhi <[email-masked]>
Date: Fri, 22 Feb 2019 20:25:00 -0500

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 <[email-masked]> wrote:

>>    - 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)"?
>>
>> Alexander.Vainshtein@ecitele..com <[email-masked]>>
>> wrote:
>>
>> +1.
>>
>>
>>
>> However SL did not address the SR case.. We therefore need this path
>> label work to be progressed.
>>
>>
>>
>> - Stewart
>>
>>
>>

---

From: Loa Andersson <[email-masked]>
Date: Sat, 23 Feb 2019 10:15:50 +0800

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:
> On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky <[email-masked] 
> <mailto:[email-masked]>> 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
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi Greg,____
> 
>         Thanks a lot for your comments.____
> 
>         My comments are in-line.____
> 
>         __ __
> 
>         B.R.____
> 
>         Weiqiang Cheng____
> 
>         __ __
> 
>         *发件人:*Greg Mirsky [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         *发送时间:*2019年2月15日3:37
>         *收件人:*Alexander Vainshtein
>         *抄送:[email-masked] <mailto:[email-masked]>; Stewart Bryant;
>         <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>; 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.____
> 
>         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:[email-masked]>> 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____
> 
>             <mailto:[email-masked]>____
> 
>             ____
> 
>             From: spring <[email-masked]
>             <mailto:[email-masked]>> On Behalf Of Stewart Bryant
>             To: Loa Andersson <loa@pi..nu <mailto:[email-masked]>>;
>             [email-masked] <mailto:[email-masked]>;
>             <mailto:[email-masked]>
>             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____
> 
>             [email-masked] <mailto:[email-masked]>____
> 
>             https://www..ietf.org/mailman/listinfo/spring____
> 
> 
>             _______________________________________________________________________________
> 
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/listinfo/spring____
> 
>     [email-masked] <mailto:[email-masked]>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 22 Feb 2019 19:55:49 -0800

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 <[email-masked]> wrote:

> >             <
> https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04>

---

From: Loa Andersson <[email-masked]>
Date: Sat, 23 Feb 2019 12:15:26 +0800

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Rakesh, authors,
> 
>      > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi Weiqiang Cheng,
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >         Hi Greg,____
>      >
>     <mailto:[email-masked]>
>      >         <mailto:[email-masked]
>     <mailto:[email-masked]>>]
>      >         *发送时间:*2019年2月15日3:37
>      >         *抄送:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>; Stewart Bryant;
>      >         <mailto:[email-masked]
>     <mailto:[email-masked]>>;
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>; Loa Andersson
>      >         <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:____
>      >
>      >             +1.____
>      >
>      >             ____
>      >
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>____
>      >
>      >             ____
>      >
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>> On Behalf Of Stewart Bryant
>      >             To: Loa Andersson <loa@pi..nu <mailto:[email-masked]
>     <mailto:[email-masked]>>>;
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>;
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >             > 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____
>      >
>      >             ____
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>____
>      >
>     <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.
>      >           
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
>     Senior MPLS Expert

--

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 22 Feb 2019 20:31:22 -0800

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 <[email-masked]> wrote:

> >      >             > I have reviewed

---

From: Loa Andersson <[email-masked]>
Date: Sat, 23 Feb 2019 16:16:00 +0800

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 <[email-masked] 
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Rakesh, authors,
>      >
>      >      > 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
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>> 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
>      >      >     <[email-masked]
>     <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >         Hi Greg,____
>      >      >
>      >      >         Thanks a lot for your comments.____
>      >      >
>      >      >         My comments are in-line.____
>      >      >
>      >      >         __ __
>      >      >
>      >      >         B.R.____
>      >      >
>      >      >         Weiqiang Cheng____
>      >      >
>      >      >         __ __
>      >      >
>      >      >         *发件人:*Greg Mirsky [mailto:[email-masked]
>     <mailto:gregimirsky@gmail..com>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >         <mailto:gregimirsky@gmail..com
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>]
>      >      >         *发送时间:*2019年2月15日3:37
>      >      >         *收件人:*Alexander Vainshtein
>      >      >         *抄送:*spring@ietf..org <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; Stewart Bryant;
>      >      > [email-masked]
>      >      >       
>     <mailto:[email-masked]>>>;
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>; 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:[email-masked]
>     <mailto:[email-masked]>>>> 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
>      >      >
>      >      >             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: [email-masked]
>     <mailto:[email-masked]>>
>      >      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>____
>      >      >
>      >      >             ____
>      >      >
>      >      >             -----Original Message-----
>      >      >             From: spring <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>> On Behalf Of Stewart Bryant
>      >      >             Sent: Wednesday, February 13, 2019 12:48 PM
>      >      >             To: Loa Andersson <loa@pi..nu
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>;
>      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>      >      > [email-masked]
>      >      >           
>     <mailto:[email-masked]>>>
>      >      >             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
>      >      >
>      >      >             > 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
>      >      >
>      >      >             > nothing that can't be resolved in the wg
>     process.____
>      >      >
>      >      >             > ____
>      >      >
>      >      >             > /Loa____
>      >      >
>      >      >             ____
>      >      >
>      >      >           
>      >      >
>      >      >             spring mailing list____
>      >      >
>      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>____
>      >      >
>      >      > https://www..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
>      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      > https://www.ietf.org/mailman/listinfo/spring____
>      >      >
>      >      >     _______________________________________________
>      >      >     spring mailing list
>      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      > https://www.ietf.org/mailman/listinfo/spring
>      >      >
>      >
>      >     --
>      >
>      >
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      >     Senior MPLS Expert

--

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 23 Feb 2019 08:17:15 -0800

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 <[email-masked]> wrote:

> >      >      > I am not sure if the question has been answered. I would
> think
> >      >     GAL is at
> >      >      >     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
> >      >      >     identifier. I think that RFC 6374 is the most suitable
> >     for PM
> >      >     OAM in
> >      >      >     can be identified using the destination UDP port
> >     number with
> >      >     IP/UDP
> >      >      >     my original question (I should have explained it
> >     better, my
> >      >     apologies):
> >      >      >
> >      >      >         How the Path segment and GAL are placed relative
> >     to each
> >      >     other
> >      >      >         <mailto:gregimirsky@gmail..com
> >      >     <mailto:[email-masked] <mailto:[email-masked]
> >>>]
> >      >      >         *发送时间:*2019年2月15日3:37
> >      >      >         *抄送:*spring@ietf..org <mailto:[email-masked]>
> >      >      >         I concur with all what has been said in support of
> the
> >      >     adoption
> >      >      >         addresses the real problem in SR-MPLS, and the
> >     proposed
> >      >     solution
> >      >      >             operations, it would be helpful to expand on
> >     the use
> >      >     of GAL
> >      >      >         [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
> >      >      >              From my POV, in its current state the draft
> meets
> >      >     two basic
> >      >      >             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
> >      >      >             requirements explicitly specified in Section 2
> >     of RFC
> >      >     8355
> >      >      >             I also concur with Stewart’s comment about
> strong
> >      >     similarity
> >      >      >             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____
> >      >      >
> >      >      >             ____
> >      >      >
> >      >      >             To: Loa Andersson <loa@pi..nu
> >      >      >             However SL did not address the SR case.. We
> >     therefore
> >      >     need
> >      >      >             > 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.____
> >      >      >
> >      >      >             > ____
> >      >      >

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 25 Feb 2019 02:32:41 +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:[email-masked]] On Behalf Of Loa Andersson
Sent: Saturday, February 23, 2019 4:16 PM
To: Greg Mirsky <[email-masked]>
Cc: [email-masked]; spring <[email-masked]>; Weiqiang Cheng <[email-masked]>; [email-masked]
Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment

Greg,

On 2019-02-23 12:31, Greg Mirsky wrote:
> 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".

                     +------------+
                     ~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?

                     +--------------+
                     ~ 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
--

-- 

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Royi Zigler <[email-masked]>
Date: Tue, 26 Feb 2019 14:11:56 +0200

+1 support WG adoption.
(Sorry for late reply)

On Mon, Feb 25, 2019 at 4:32 AM Chengli (Cheng Li) <[email-masked]>
wrote:

> Cc: [email-masked]; spring <[email-masked]>; Weiqiang Cheng <
> [email-masked]>;

-- 
Thanks,
RoyiJZ