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

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, gregory.mirsky@ztetx.com wrote:
> 
> 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
> 
> 
> 
> 
> <9ae3e214c17d49ed935d87c674ba3ee2.jpg>	<24242e5637af428891c4db731e7765ad.jpg>
> E: gregory.mirsky@ztetx.com <mailto:gregory.mirsky@ztetx.com> 
> www.zte.com.cn <http://www.zte.com.cn/>
> Original Mail
> Sender: StewartBryant
> To: James Guichard;
> CC: Stewart Bryant;spring@ietf.org;spring-chairs@ietf.org;
> Date: 2021/07/22 07:06
> Subject: Re: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
> 
> 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 <james.n.guichard@futurewei.com <mailto:james.n.guichard@futurewei.com>> wrote:
>> 
>> 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 <james.n.guichard@futurewei.com <mailto:james.n.guichard@futurewei.com>> 
>> Sent: Wednesday, July 7, 2021 11:49 AM
>> To: spring@ietf.org <mailto:spring@ietf.org>
>> Cc: spring-chairs@ietf.org
>> Subject: 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
>>  
>> [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
>> spring@ietf.org <mailto:spring@ietf.org>
>> https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>
> 