Hi Francois, For this point.
END.AN only appear once in the IANA consideration part without any explanation. Text is required to describe this behavior I think. What is the pseudo code of this behavior? Can it combine with other behavior? [FC] Yes, good point. I am working on adding a dedicated section for End.AS, which ensures that the SRv6 segment endpoint operation (decrement SL, update DA, etc.) is properly performed while leaving the service function processing open (since this is service-dependent). [FC] What kind of behavior combination do you have in mind? [Cheng] like END.AN with PSP, USD. What is the code of a SR aware behavior? I do not see the definition of this behavior. If it is a new behavior, can it combine with PSP, USD, PSD, REPLACE, NEXT? Thanks, Cheng From: Francois Clad <[email protected]> Sent: Friday, June 13, 2025 10:14 AM To: Cheng Li <[email protected]> Cc: [email protected]; 6man <[email protected]>; spring <[email protected]> Subject: Re: [mpls] Resuming discussion on draft-ietf-spring-sr-service-programming Hi Cheng, Many thanks for sharing those comments, and sorry for my response delay. Please see inline ([FC]). Thanks, Francois On 2 Jun 2025 at 16:12:10, Cheng Li <[email protected]<mailto:[email protected]>> wrote: Hi Francois, In order to have more discussions on the lists, I share my comments directly here instead of the author list. We should apply for IANA of the Endpoint ASAP in order to support implementation. [FC] Those code points are already allocated (see 161..168 in https://www.iana.org/assignments/segment-routing/segment-routing.xhtml), but indeed section 10.1 of the draft still needs to be updated accordingly. This will be fixed in the next revision. Thanks! END.AN only appear once in the IANA consideration part without any explanation. Text is required to describe this behavior I think. What is the pseudo code of this behavior? Can it combine with other behavior? [FC] Yes, good point. I am working on adding a dedicated section for End.AS, which ensures that the SRv6 segment endpoint operation (decrement SL, update DA, etc.) is properly performed while leaving the service function processing open (since this is service-dependent). [FC] What kind of behavior combination do you have in mind? Should clarify the Endpoint type in each section of the behavior. END.AS<http://END.AS>, END.AD<http://END.AD>, END.AM<http://END.AM>…… also only appear once in IANA section, text of definition and usage should be added. [FC] Agreed. I’ll fix this. If we only have one type of behavior of static and dynamic proxy behaviors, then we might combine the code into one complete pseudo code. Now we have different pseudo code associate with the upper type of the traffic, IPv4, IPv6 or ETH. [FC] Let me see how we could improve that. I cannot find the related text of TBA1-7 End.AM - Masquerading proxy with NAT & Caching, a sub-section 6.4.4 may be needed? [FC] That’s a combination of the base behavior in 6.4.1 with both flavors in 6.4.2 and 6.4.3. Let me see if I can clarify this somehow. It seems that for SR-MPLS data plane, the solution is not that mature, any plan regarding this? [FC] The SR-MPLS part indeed needs to take into consideration the MPLS evolutions that occurred since this draft was first proposed (MNA in particular, as Yao also pointed out). It shouldn’t be too much work to integrate it, though. Thanks, Cheng From: Francois Clad <[email protected]<mailto:[email protected]>> Sent: Monday, May 12, 2025 12:25 PM To: spring <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; 6man <[email protected]<mailto:[email protected]>> Subject: [mpls] Resuming discussion on draft-ietf-spring-sr-service-programming (to: SPRING WG; cc: MPLS and 6MAN WGs) Dear WG, With the renewed interest in service programming at recent IETF meetings, we would like to resume discussion on draft-ietf-spring-sr-service-programming (“Service Programming with Segment Routing”) to progress and complete this work as a solid foundation for future proposals. https://datatracker.ietf.org/doc/draft-ietf-spring-sr-service-programming/ This draft describes the data plane mechanisms required for service segments and service programming in SR-MPLS and SRv6 networks. Its goal is to enable the integration of physical or virtual network functions into SR policies by associating each service with a SID. The draft defines two types of services: SR-aware services, which natively process SR information in packets SR-unaware services, which require an SR proxy to handle or adapt SR headers before the service function processes the packet. To support SR-unaware services, the draft specifies several SR proxy behaviors, outlining their respective benefits and limitations. Finally, the draft describes how service-related metadata can be carried in both SR-MPLS and SRv6 packets. We welcome any feedback, comments, or suggestions you may have on the draft. Thanks, Francois (on behalf of the co-authors)
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
