Hi Yao, Thanks for your comments.
Please see inline ([FC]). Thanks, Francois On 6 Jun 2025 at 12:12:20, [email protected] wrote: > Hi Francois, > > > Thanks for bring this draft back. It seems that there's no significant > change of this draft since v-02 about more than 4 years ago. > > I think 2 more aspects need to be considered compared with that time, SRv6 > SID compression and MPLS MNA: > > 1) Since we have SRv6 SID list can be compressed now, are all the > procedures, especially the pseudocodes for SR proxy behavior still > applicable. > [FC] As Cheng pointed out, these aspects are covered in a separate document. > 2) I agree with Chengli that the solution for service programming with > SR-MPLS is not that mature in the draft. Especially on the service metadata > part. MNA-style service metadata carrying mechanism may be taken into > consideration. > [FC ] The text in the draft is based on the options that were available at the time. You’re absolutely right that it needs to be updated to take MNA into consideration. > > Regards, > > Yao > > > > > > Original > *From: *ChengLi <[email protected]> > *To: *Francois Clad <[email protected]>;spring <[email protected]>; > *Cc: *[email protected] <[email protected]>;6man <[email protected]>; > *Date: *2025年06月02日 22:14 > *Subject: **[spring] Re: [mpls] Resuming discussion on > draft-ietf-spring-sr-service-programming* > _______________________________________________ > spring mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > 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. > > 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? > > 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. > > 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. > > 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? > > 6. It seems that for SR-MPLS data plane, the solution is not that > mature, any plan regarding this? > > > > Thanks, > > Cheng > > > > > > > > *From:* Francois Clad <[email protected]> > *Sent:* Monday, May 12, 2025 12:25 PM > *To:* spring <[email protected]> > *Cc:* [email protected]; 6man <[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]
