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 <c...@huawei.com> wrote: > Hi Francois, > > > > In order to have more discussions on the lists, I share my comments > directly here instead of the author list. > > > > 1. 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! > 2. 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? > 3. Should clarify the Endpoint type in each section of the > behavior. END.AS, END.AD, END.AM…… also only appear once in IANA > section, text of definition and usage should be added. > [FC] Agreed. I’ll fix this. > 4. 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. > 5. 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. > 6. 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 <fclad.i...@gmail.com> > *Sent:* Monday, May 12, 2025 12:25 PM > *To:* spring <spring@ietf.org> > *Cc:* m...@ietf.org; 6man <i...@ietf.org> > *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 -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
