Subject: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

From: James Guichard <[email-masked]>
Date: Wed, 7 Jul 2021 15:48:48 +0000

Dear WG:

This email starts a 2 week Working Group Last Call for draft-ietf-spring-mpls-path-segment [1].

Please read this document if you haven't read the most recent version and send your comments to the SPRING WG list no later than July 21st 2021.

If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributor please response to indicate whether you know of any undisclosed IPR related to this document.

Thanks!

Jim, Joel & Bruno

[1] https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

---

From: JeffT <[email-masked]>
Date: Wed, 7 Jul 2021 11:21:08 -0700

Hi Jim,

I’m aware of IPR related to this document, it has been disclosed in accordance to IETF rules.

Cheers,

Jeff

From: James Guichard
Sent: Wednesday, July 7, 2021 8:49 AM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

Dear WG:

Please read this document if you haven’t read the most recent version and send your comments to the SPRING WG list no later than July 21st 2021.

Thanks!

Jim, Joel & Bruno

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 8 Jul 2021 01:38:46 +0000

As an contributor, I support the WGLC.

I am not aware of any IPR related to this document.

Thanks,
Cheng

From: spring [mailto:[email-masked]] On Behalf Of James Guichard
Sent: Wednesday, July 7, 2021 11:49 PM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Mach Chen <[email-masked]>
Date: Thu, 8 Jul 2021 03:45:12 +0000

Hi Jim,

I am not aware of any undisclosed IPR related to this document.

Best regards,
Mach

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Fri, 16 Jul 2021 09:59:17 +0800

Hi Jim,

I’m aware of IPR related to this document, and it has been disclosed in
accordance to IETF rules.

I am not aware of any other undisclosed IPR related to this document.

B.R.

Weiqiang Cheng

发件人: spring [mailto:[email-masked]] 代表 James Guichard
发送时间: 2021年7月7日 23:49
收件人: [email-masked]
抄送: [email-masked]
主题: [spring] WGLC for
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

Dear WG:

This email starts a 2 week Working Group Last Call for
draft-ietf-spring-mpls-path-segment [1].

Please read this document if you haven’t read the most recent version and
send your comments to the SPRING WG list no later than July 21st 2021. 

If you are raising a point which you expect will be specifically debated on
the mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributor please response to indicate
whether you know of any undisclosed IPR related to this document. 

Thanks!

Jim, Joel & Bruno

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 16 Jul 2021 02:08:25 +0000

Hi WG,
As a co-author, I have read the latest version of the draft and I believe it is ready for publication.

Thanks,
Rakesh

From: spring <[email-masked]> on behalf of James Guichard <[email-masked]>
Date: Wednesday, July 7, 2021 at 11:49 AM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/
Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Wang Lei" <[email-masked]>
Date: Fri, 16 Jul 2021 18:10:57 +0800

Dear Jim,

B.R.

Lei

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: James Guichard <[email-masked]>
Date: Thu, 22 Jul 2021 13:02:33 +0000

Dear WG:

The WGLC for this document will be extended for a further 2 weeks ending August 4th 2021 so that feedback can be obtained from the WG. Other than the authors there has been little input so please respond on the mailing list with any comments etc.

Thanks!

Jim, Joel & Bruno

From: James Guichard <[email-masked]>
Sent: Wednesday, July 7, 2021 11:49 AM
To: [email-masked]
Cc: [email-masked]
Subject: WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

Dear WG:

Thanks!

Jim, Joel & Bruno

[1] https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-mpls-path-segment%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C4336eaaa34f543cc4c9e08d9415ebd06%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637612697462524718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v18Zntmw18jYiIXCNMDa7bYNQMZ90U29GVEkuPh5CjE%3D&reserved=0>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 22 Jul 2021 15:05:41 +0100

Once you find yourself needing to include path identifiers in an SR packet, I begin to wonder whether the segment routing design has gone off track.

In MPLS we have the ability in both PCE and RSVP to lay out end to end paths in such a way that the forwarding label is the path identifier. If you recall the MPLS-TP approach you could deduce everything about the packet’s origin and path from the arrival label which was not PHPed.

Assuming there are technical reasons why such a classic approach is not possible, I wonder why it is necessary to encode the path identifier within label stack itself with all of the constraints that imposes on the size and semantics of the identifier.

An alternative approach is to look at the meta/ancillary data work that is going on in MPLS and carry the path identifier below the bottom of stack.

At  its most basic level this analogous to the approach to constructing a Pseudowires, with an outgoing label stack, a control word (which can be an extended control word carrying the path information) and then the payload.

Such an approach would allow the packet designer to carry either the identity of the path, or the actual set of labels use to construct the path, or the reverse path or some combination of these. The latter two approaches are more dynamic than the approach proposed in this draft and more in keeping with the fundamental design philosophy of SR.

- Stewart

> On 22 Jul 2021, at 14:02, James Guichard <[email-masked]> wrote:
> 
> Dear WG:
>  
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/ <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-mpls-path-segment%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C4336eaaa34f543cc4c9e08d9415ebd06%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637612697462524718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v18Zntmw18jYiIXCNMDa7bYNQMZ90U29GVEkuPh5CjE%3D&reserved=0>
>  
>  
>  
>  
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Fri, 23 Jul 2021 16:05:17 +0800

Hi Stewart,

Thanks a lot for your comments.

Co-authors have discussed the comments and our feedback is inline below.

B.R.

Weiqiang Cheng

发件人: spring [mailto:[email-masked]] 代表 Stewart Bryant
发送时间: 2021年7月22日 22:06
收件人: James Guichard
抄送: Stewart Bryant; [email-masked]; [email-masked]
主题: Re: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

[Co-authors] As we know, the meta/ancillary work just started for now, it may be an alternative solution in the future. The solution proposed in the draft was to address a real-world issue, there have been implementations and deployments.

[Co-authors] From path identification point of view, the Path Segment has the similar function as PW Label, but the control word is not necessary. So, somehow, the path segment is simpler than PW solution, and more important, there is need to construct and maintain a PW for such purpose. 

[Co-authors] The Path segment concept has been actively discussed in SPRING when the idea was proposed, and now SR-MPLS and SRv6 Path segment are adopted by the WG. It is valuable for high quality services of the operators 

- Stewart

Dear WG:

Thanks!

Jim, Joel & Bruno

Dear WG:

Thanks!

Jim, Joel & Bruno

[1]  <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-mpls-path-segment%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C4336eaaa34f543cc4c9e08d9415ebd06%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637612697462524718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v18Zntmw18jYiIXCNMDa7bYNQMZ90U29GVEkuPh5CjE%3D&reserved=0> https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

---

From: <[email-masked]>
Date: Tue, 27 Jul 2021 15:13:16 +0800 (CST)

Hi Stewart & Weiqiang,

Thanks for Mr Stewart's comments, which are valuable for understanding the Path Segment.

And I agree Weiqiang's responses. One more thing I want to notice that Path Segment could balance the philosophy of SR and MPLS for Path capabilities, such as Path Policy or PM. These capabilities are instinct with SR-Path, it's very different with PW.

Regards,

Aihua

原始邮件

发件人：WeiqiangCheng
收件人：'Stewart Bryant';'James Guichard';
抄送人：[email-masked];[email-masked];
日 期 ：2021年07月23日 16:06
主 题 ：Re: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

Hi Stewart,

 

B.R.

Weiqiang Cheng

 

 

 

 

 

 

 

 

 

 

 

- Stewart

 

Dear WG:

 

Thanks!

Jim, Joel & Bruno

 

Dear WG:

 

 

 

 

Thanks!

Jim, Joel & Bruno

---

From: <[email-masked]>
Date: Wed, 28 Jul 2021 05:52:19 +0800 (CST)

Hi Stewart,

I agree with your examples that PCE and RSVP label distribution mechanisms allow egress to deduce the identity of the ingress LER. In MPLS-TP, as I recall, label merge and PHP are prohibited, and that also allows the egress to "know" the particular ingress LER based on the ToS label. But the SID use in SR-MPLS, in my understanding, is not like in any of the abovementioned techniques. The need to identify the source in IP/MPLS has been known from the beginning of active OAM work. Using the IP/UDP encapsulation addresses the need to know the identity of the LER that originated the test packet. For non-IP encapsulation in MPLS-TP, the MEP ID TLVs were defined for MPLS-TP LSP and PW.

I think that using a label to identify the path is a reasonable method of addressing the actual scenario in SR-MPLS.

Regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: StewartBryant
To: James Guichard;
CC: Stewart Bryant;[email-masked];[email-masked];
Date: 2021/07/22 07:06
Subject: Re: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

- Stewart

Dear WG:

Thanks!
 
Jim, Joel & Bruno

From: James Guichard <[email-masked]> Sent: Wednesday, July 7, 2021 11:49 AMTo: [email-masked]: [email-masked]: WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

Dear WG:

 

Thanks!
 
Jim, Joel & Bruno

_______________________________________________spring mailing [email-masked]://www.ietf.org/mailman/listinfo/spring

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 28 Jul 2021 09:28:28 +0100

Hi Greg

In -TP there were cases where we needed to send an OOB reply and we did this by putting the IP address of the return node in the outgoing message.

My concern here is that just because this is an MPLS design, and you can use a label as a proxy for an identifier does not mean that it is the best approach.

I can see a case for a path label is there is a need for the fast path to vector through the path label to take an immediate forwarding action as happens with PW and MPLS-VPN. If that is not the case there are more powerful techniques that do not require control plane pre-work to put in place a label to path mapping.

So this comes back to the intent of the work. If the intent is to pre-install paths, then we have methods to do so and do not need the overhead of SR.

If the intent is to dynamically create paths minimising the pre-agreed state seems a better approach. For example if the outgoing packet carried the source IP address and a key, you could on the fly create a packet that had the desired properties as a one off and immediately send it. That seems much more in keeping with the SR design philosophy.

As I noted earlier you could put either the real outgoing path and or the actual rather than implicit return path in the packet (very useful for reverse path testing, and special policy) if you moved away from using a label representation of a path an actual path or a set of path parameters.

- Stewart

> On 27 Jul 2021, at 22:52, [email-masked] wrote:
> 
> Hi Stewart,
> 
> E: [email-masked] <mailto:[email-masked]> 
> www.zte.com.cn <http://www.zte.com.cn/>
> Original Mail
> Sender: StewartBryant
> To: James Guichard;
>> On 22 Jul 2021, at 14:02, James Guichard <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Dear WG:
>>  
>> From: James Guichard <[email-masked] <mailto:[email-masked]>> 
>> To: [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>
>

---

From: Rakesh Gandhi <[email-masked]>
Date: Wed, 28 Jul 2021 08:54:58 -0400

Hi Stewart,

The SR-MPLS path segment (MPLS label) is used to count received packets on
a particular path on the egress node. This allows us to measure PM packet
loss on a given path. The (incoming) MPLS label as path segment has an
advantage of using existing implementations for RX packet count.

Thanks,
Rakesh

On Thu, Jul 22, 2021 at 10:06 AM Stewart Bryant <[email-masked]>
wrote:

> Once you find yourself needing to include path identifiers in an SR
> packet, I begin to wonder whether the segment routing design has gone off
> track.
>
> In MPLS we have the ability in both PCE and RSVP to lay out end to end
> paths in such a way that the forwarding label is the path identifier. If
> you recall the MPLS-TP approach you could deduce everything about the
> packet’s origin and path from the arrival label which was not PHPed.
>
> Assuming there are technical reasons why such a classic approach is not
> possible, I wonder why it is necessary to encode the path identifier within
> label stack itself with all of the constraints that imposes on the size and
> semantics of the identifier.
>
> An alternative approach is to look at the meta/ancillary data work that is
> going on in MPLS and carry the path identifier below the bottom of stack.
>
> At  its most basic level this analogous to the approach to constructing a
> Pseudowires, with an outgoing label stack, a control word (which can be an
> extended control word carrying the path information) and then the payload.
>
> Such an approach would allow the packet designer to carry either the
> identity of the path, or the actual set of labels use to construct the
> path, or the reverse path or some combination of these. The latter two
> approaches are more dynamic than the approach proposed in this draft and
> more in keeping with the fundamental design philosophy of SR.
>
> - Stewart
>
>
> The WGLC for this document will be extended for a further 2 weeks ending
> August 4th 2021 so that feedback can be obtained from the WG. Other than
> the authors there has been little input so please respond on the mailing
> list with any comments etc.
>
> Thanks!
>
> Jim, Joel & Bruno
>
> *From:* James Guichard <[email-masked]>
> *Sent:* Wednesday, July 7, 2021 11:49 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* WGLC for
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-mpls-path-segment%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C4336eaaa34f543cc4c9e08d9415ebd06%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637612697462524718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v18Zntmw18jYiIXCNMDa7bYNQMZ90U29GVEkuPh5CjE%3D&reserved=0>
>
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 28 Jul 2021 17:28:13 +0100

Hi Rakesh

I can see why you would want to use a label in that application, but using a label has a cost that should be more thoroughly discussed in the text and compared to alternatives.

What I see in the text is a reference to alt-marking, how are you proposing to provide the alt pair?

Thanks

- Stewart

> On 28 Jul 2021, at 13:54, Rakesh Gandhi <[email-masked]> wrote:
> 
> Hi Stewart,
> 
> The SR-MPLS path segment (MPLS label) is used to count received packets on a particular path on the egress node. This allows us to measure PM packet loss on a given path. The (incoming) MPLS label as path segment has an advantage of using existing implementations for RX packet count.
> 
> Thanks,
> Rakesh
> 
> 
> 
> 
> 
> 
> 
> On Thu, Jul 22, 2021 at 10:06 AM Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
>> Cc: [email-masked] <mailto:[email-masked]>
>> Subject: WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/ <https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/>
>>  
>> Dear WG:
>>

---

From: Rakesh Gandhi <[email-masked]>
Date: Wed, 28 Jul 2021 12:54:01 -0400

Hi Stewart,
Many thanks for your comments.
Yes, we can add some text about the RX packet counters using the path
segment. As RX packet counts for incoming labels are typically supported by
most existing implementations, it is a natural choice. Other schemes e.g.
using metadata after BOS of MPLS label stack for RX packet count may need
new implementation.

Thanks,
Rakesh

On Wed, Jul 28, 2021 at 12:28 PM Stewart Bryant <[email-masked]>
wrote:

> Hi Rakesh
>
> I can see why you would want to use a label in that application, but using
> a label has a cost that should be more thoroughly discussed in the text and
> compared to alternatives.
>
>> An alternative approach is to look at the meta/ancillary data work that
>> is going on in MPLS and carry the path identifier below the bottom of stack.
>>

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 29 Jul 2021 11:08:04 +0800

Support its publication.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of James
Guichard
Sent: Thursday, July 22, 2021 9:03 PM
To: James Guichard <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [spring] WGLC for
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

Dear WG:

The WGLC for this document will be extended for a further 2 weeks ending
August 4th 2021 so that feedback can be obtained from the WG. Other than the
authors there has been little input so please respond on the mailing list
with any comments etc. 

Thanks!

Jim, Joel & Bruno

From: James Guichard <[email-masked]
<mailto:[email-masked]> > 
Sent: Wednesday, July 7, 2021 11:49 AM
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: WGLC for
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

Dear WG:

Please read this document if you haven't read the most recent version and
send your comments to the SPRING WG list no later than July 21st 2021. 

Thanks!

Jim, Joel & Bruno

[1] https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fdraft-ietf-spring-mpls-path-segment%2F&data=04%7C01%7Cja
mes.n.guichard%40futurewei.com%7C4336eaaa34f543cc4c9e08d9415ebd06%7C0fee8ff2
a3b240189c753a1d5591fedc%7C1%7C0%7C637612697462524718%7CUnknown%7CTWFpbGZsb3
d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
sdata=v18Zntmw18jYiIXCNMDa7bYNQMZ90U29GVEkuPh5CjE%3D&reserved=0>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 29 Jul 2021 02:12:39 -0400

I support publication of this draft.

I see a lot of value for operators with this draft encoding of the path
into a path segment for end to end 1+1 path protection and PM and path
correlation and bidirectional path instantiation for mobile backhaul.

In section 4 it talks about nesting of path segments. So basically on an
end to end path you with the nesting we can take advantage of SID list
compression by a combination of BSID and PSID allocated for the end to end
path where s-PSID amis the PSID of each sub path snd e-SID is the end to
end E2E path.  As BSID is binds the candidate path to the forwarding plane,
is the Per sub path s-PSID and e-SID included as part of of the SR-TE
policy end to end policy.  I  did not see PSID mentioned in the SR path
Segment Policy draft.

This draft does not mention SRv6 use case, however the SR path policy draft
does mention SRv6 support via sub TLV Segment type flag to support both
SR-MPLS and SRv6.  In this draft it does mention use of the path Segment to
define the sub paths in the SR-TE policy.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment

I found the corresponding path Segment draft for SRv6 path Segment.
Perfect!

https://datatracker.ietf.org/doc/html/draft-li-spring-srv6-path-segment-00

Also the PCE draft for SR path Segment.

https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-path-segment

I see that the PCE draft uses the PCE CC centralized controller CCI object
for the stateful PCE path Segment instantiated.

Makes sense as this is an E2E inter-as end to end path using sub paths
defined in the compressed SID list s-PSID sub paths.

Regards

Gyan

On Wed, Jul 28, 2021 at 11:08 PM Aijun Wang <[email-masked]>
wrote:

> Support its publication.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *James
> Guichard
> *Sent:* Thursday, July 22, 2021 9:03 PM
> *To:* James Guichard <[email-masked]>; [email-masked]
> *Subject:* Re: [spring] WGLC for
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*