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

[[e-mail]]

Hi Cheng,
I'll read it. Thanks.


Yao

Original


From: ChengLi <c.l=[e-mail]>
To: 刘尧00165286;[e-mail] <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2025年06月06日 20:13
Subject: [spring] Re: [mpls] Re: Re: Resuming discussion on draft-ietf-spring-sr-service-programming

_______________________________________________
spring mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
 

Hi Yao,
 
If you are looking for C-SID for SFC, you might read this document: https://datatracker.ietf.org/doc/html/draft-lh-spring-srv6-sfc-csid-02
 
Thanks,
Cheng
 
 
From: [e-mail] <[e-mail]> 
 Sent: Friday, June 6, 2025 12:12 PM
 To: [e-mail]
 Cc: [e-mail]; [e-mail]; [e-mail]
 Subject: [mpls] Re: [spring] Re: Resuming discussion on draft-ietf-spring-sr-service-programming
 
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.
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. 
 
Regards,
Yao
 
 
 
 

Original

From: ChengLi <c.l=[e-mail]>



To: Francois Clad <[e-mail]>;spring <[e-mail]>;



Cc: [e-mail] <[e-mail]>;6man <[e-mail]>;



Date: 2025年06月02日 22:14



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




_______________________________________________
 spring mailing list -- [e-mail]
 To unsubscribe send an email to [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)