Hi Jiaming, Thank you for your email and sorry for the delay in getting back to you.
Yes, I agree that the dynamic proxy could be improved with finer grain caching (e.g., flow-based). In fact, some implementations do that already [1]. Let me propose some text changes in the draft to cover such refinement of the End.AD behavior. Thanks, Francois [1]: https://s3-docs.fd.io/vpp/25.02/developer/plugins/srv6/ad_flow_plugin_doc.html On 27 May 2025 at 13:01:51, 叶佳铭 <yejiam...@chinamobile.com> wrote: > Hi Francois, > > > I've read this draft, the scenarios you've described are quite > comprehensive. After reading it, I have a few comments/questions: > > Is the granularity of indexing SR information from CACHE entries presented > in the pseudocode in 6.2.1 and 6.2.2, interface IFACE-IN, not specific > enough? Due to the constraints, a static proxy segment END.AS has a > one-to-one mapping with a segment list, but the types of packets to which > this segment list is applied can be diverse. While, differenting from the > static proxy approach, there's no need to statically configure parameters > such as CACHE.SA and CACHE.LIST on the specific interface when using the > dynamic proxy. Therefore, under the dynamic approach, i think it is > possible for multiple segment lists to invoke the same END.AD. In this > situation, if the granularity is interface, packets with different > characteristics received from same IFACE-IN will not be re-encapsulated > correctly. > > Hope the comment would be helpful. Additionally, I noticed that the > behaviors of SR-aware services have not been further discussed in the > draft. In some scenarios, the characteristics of packets may overlap, so > if the characteristics such as 5-tuple are same, service nodes might not > to offer customized process. To address this, we posted a draft that covers > the situations: > https://datatracker.ietf.org/doc/html/draft-lin-spring-srv6-aware-context-indicator-04 > > We'd be more than happy if you are interested in it and could give any > feedback, comments, or suggestions. > > > > *Thanks* > ------------------------------ > > *Best regards,* > *叶佳铭/Jiaming Ye* > 中国移动通信有限公司研究院/China Mobile Research Institute > Email: yejiam...@chinamobile.com > Mobile: 18810735331 > > > ----邮件原文---- > *发件人：*Francois Clad <fclad.i...@gmail.com> > *收件人：*spring <spring@ietf.org> > *抄 送: *mpls <m...@ietf.org>,6man <i...@ietf.org> > *发送时间：*2025-05-12 18:24:47 > *主题：* > [spring] 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
