[IPv6]Re: [mpls] Resuming discussion on draft-ietf-spring-sr-service-programming

[Cheng Li <[e-mail]>]

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 <[e-mail]>
Sent: Monday, May 12, 2025 12:25 PM
To: spring <[e-mail]>
Cc: [e-mail]; 6man <[e-mail]>
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)