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

[Greg Mirsky]

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  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  > > 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  > 
> >  > >> 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
> >  > mailto:gregimir...@gmail.com>
> > >
> >  >  >  >   >  >  >  >
> >  >  > 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

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

[Greg Mirsky]

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  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  > > 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
> > 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
> >  >  > 
> >  >  > >> wrote:
> >  >
> >  > Hi Greg,
> >  >
> >  > Thanks a lot for your comments.
> >  >
> >  > My comments are in-line.
> >  >
> >  > __ __
> >  >
> >  > B.R.
> >  >
> >  > Weiqiang Cheng
> >  >
> >  > __ __
> >  >
> >  > *发件人:*Greg Mirsky [mailto:gregimir...@gmail.com
> > 
> >  >  > >]
> >  > *发送时间:*2019年2月15日3:37
> >  > *收件人:*Alexander Vainshtein
> >  > *抄送:*spring@ietf.org 
> > >; Stewart Bryant;
> >  > draft-cheng-spring-mpls-path-segm...@ietf.org
> > 
> >  >  > >;
> >  > 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 

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

[Loa Andersson]

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

 >         >]
 >         *发送时间:*2019年2月15日3:37
 >         *收件人:*Alexander Vainshtein
 >         *抄送:*spring@ietf.org 
>; Stewart Bryant;
 > draft-cheng-spring-mpls-path-segm...@ietf.org

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

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

[Greg Mirsky]

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  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  > > 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
> >  > > wrote:
> >
> > Hi Greg,
> >
> > Thanks a lot for your comments.
> >
> > My comments are in-line.
> >
> > __ __
> >
> > B.R.
> >
> > Weiqiang Cheng
> >
> > __ __
> >
> > *发件人:*Greg Mirsky [mailto:gregimir...@gmail.com
> > ]
> > *发送时间:*2019年2月15日3:37
> > *收件人:*Alexander Vainshtein
> > *抄送:*spring@ietf.org ; Stewart Bryant;
> > draft-cheng-spring-mpls-path-segm...@ietf.org
> > ;
> > 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
> >  > > 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
> >  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 

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

[Loa Andersson]

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 > 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
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
]
*发送时间:*2019年2月15日3:37
*收件人:*Alexander Vainshtein
*抄送:*spring@ietf.org ; Stewart Bryant;
draft-cheng-spring-mpls-path-segm...@ietf.org
;
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
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
 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
. 

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,

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

[xiong.quan]

+1. Support.

I have read this draft and I think the path segment is reasonable and useful in 
the use cases like PM, Bi-directional SR Path and End-to-end Path Protection.

Thanks,
Quan


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Weiqiang Cheng
Sent: Wednesday, February 13, 2019 11:59 AM
To: 'Loa Andersson' ;; spring@ietf.orgCc: 
draft-cheng-spring-mpls-path-segment@ietf.orgSubject: Re: [spring] to progress 
draft-cheng-spring-mpls-path-segment

Hi Loa,
Thank you very much for your review and comments.
The solution in the draft provides a simple and effective way for E2E FM and PM 
in the Telecom application Scenario.
The requirements are valid and all existing comments have been resolved.
We authors also hope WG can adopt draft-cheng-spring-mpls-path-segment as a 
working group document.

B.R.
Weiqiang Cheng

-邮件原件-
发件人: Loa Andersson [mailto:l...@pi.nu] 
发送时间: 2019年2月10日 16:11
收件人: spring@ietf.org; draft-cheng-spring-mpls-path-segm...@ietf.org主题: to 
progress draft-cheng-spring-mpls-path-segment

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
https://www.ietf.org/mailman/listinfo/spring

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

[Greg Mirsky]

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> wrote:

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

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

[Greg Mirsky]

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 <
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
>
>
>
> -Original Message-
> From: spring  On Behalf Of Stewart Bryant
> Sent: Wednesday, February 13, 2019 12:48 PM
> To: Loa Andersson ; spring@ietf.org;
> 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
>
> https://www..ietf.org/mailman/listinfo/spring
> <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
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Shuo Yang Y]

Hi Working Group,

As we have reviewed the draft, this path segment is an efficient way for tunnel 
layer OAM and could be significantly reduce the resource needed on network 
element for bi-directional/co-routed SR tunnel applications.

I would recommend working group to adopt this draft as a working group 
document, to further consolidate the technology.

BR //
Shuo Yang / 杨硕

-邮件原件-
发件人: Weiqiang Cheng [mailto:chengweiqi...@chinamobile.com] 
发送时间: 2019年2月13日 11:59
收件人: 'Loa Andersson'; 'spring@ietf.org'
抄送: 'draft-cheng-spring-mpls-path-segm...@ietf.org'
主题: Re: [spring] to progress draft-cheng-spring-mpls-path-segment

Hi Loa,
Thank you very much for your review and comments.
The solution in the draft provides a simple and effective way for E2E FM and PM 
in the Telecom application Scenario.
The requirements are valid and all existing comments have been resolved.
We authors also hope WG can adopt draft-cheng-spring-mpls-path-segment as a 
working group document.

B.R.
Weiqiang Cheng

-邮件原件-
发件人: Loa Andersson [mailto:l...@pi.nu] 
发送时间: 2019年2月10日 16:11
收件人: spring@ietf.org; draft-cheng-spring-mpls-path-segm...@ietf.org
主题: to progress draft-cheng-spring-mpls-path-segment

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


Loa Anderssonemail: 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

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

[Linda Dunbar]

Support, 

Linda Dunbar

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, February 13, 2019 5:48 AM
To: Loa Andersson ; spring@ietf.org; 
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
https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Luis M. Contreras]

Hi all,

+1 support for WG adoption of this draft

Best regards

Luis

___
Luis M. Contreras
i...@lmcontreras.com | luismiguel.contrerasmuri...@telefonica.com
Telefonica I+D / Global CTIO unit / Telefonica


On 2019-02-13 14:08, James N Guichard wrote:

+1 support WG adoption.

Jim

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stewart 
Bryant

Sent: Wednesday, February 13, 2019 5:48 AM
To: Loa Andersson ; spring@ietf.org;
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
https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


--

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[James N Guichard]

+1 support WG adoption.

Jim

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, February 13, 2019 5:48 AM
To: Loa Andersson ; spring@ietf.org; 
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
https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Stewart Bryant]

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
https://www.ietf.org/mailman/listinfo/spring

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

[Chengli (Cheng Li)]

+1. 

After reviewing the document , I think the requirement of path segment is clear 
and the solution is reasonable and effective.
Since the content of this draft is stable, I think it is ready for WG adoption 
as well.

Thanks,
Cheng


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Weiqiang Cheng
Sent: Wednesday, February 13, 2019 11:59 AM
To: 'Loa Andersson' ; spring@ietf.org
Cc: draft-cheng-spring-mpls-path-segm...@ietf.org
Subject: Re: [spring] to progress draft-cheng-spring-mpls-path-segment

Hi Loa,
Thank you very much for your review and comments.
The solution in the draft provides a simple and effective way for E2E FM and PM 
in the Telecom application Scenario.
The requirements are valid and all existing comments have been resolved.
We authors also hope WG can adopt draft-cheng-spring-mpls-path-segment as a 
working group document.

B.R.
Weiqiang Cheng

-邮件原件-
发件人: Loa Andersson [mailto:l...@pi.nu] 
发送时间: 2019年2月10日 16:11
收件人: spring@ietf.org; draft-cheng-spring-mpls-path-segm...@ietf.org
主题: to progress draft-cheng-spring-mpls-path-segment

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


Loa Anderssonemail: 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
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Weiqiang Cheng]

Hi Loa,
Thank you very much for your review and comments.
The solution in the draft provides a simple and effective way for E2E FM and PM 
in the Telecom application Scenario.
The requirements are valid and all existing comments have been resolved.
We authors also hope WG can adopt draft-cheng-spring-mpls-path-segment as a 
working group document.

B.R.
Weiqiang Cheng

-邮件原件-
发件人: Loa Andersson [mailto:l...@pi.nu] 
发送时间: 2019年2月10日 16:11
收件人: spring@ietf.org; draft-cheng-spring-mpls-path-segm...@ietf.org
主题: to progress draft-cheng-spring-mpls-path-segment

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


Loa Anderssonemail: 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