Hi Cheng,
I'll read it. Thanks.
Yao
Original
From: ChengLi <c.l=40huawei....@dmarc.ietf.org>
To: 刘尧00165286;fclad.i...@gmail.com <fclad.i...@gmail.com>;
Cc: spring@ietf.org <spring@ietf.org>;m...@ietf.org
<m...@ietf.org>;i...@ietf.org <i...@ietf.org>;
Date: 2025年06月06日 20:13
Subject: [spring] Re: [mpls] Re: Re: Resuming discussion on
draft-ietf-spring-sr-service-programming
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
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: liu.ya...@zte.com.cn <liu.ya...@zte.com.cn>
Sent: Friday, June 6, 2025 12:12 PM
To: fclad.i...@gmail.com
Cc: spring@ietf.org; m...@ietf.org; i...@ietf.org
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=40huawei....@dmarc.ietf.org>
To: Francois Clad <fclad.i...@gmail.com>;spring <spring@ietf.org>;
Cc: m...@ietf.org <m...@ietf.org>;6man <i...@ietf.org>;
Date: 2025年06月02日 22:14
Subject: [spring] Re: [mpls] Resuming discussion on
draft-ietf-spring-sr-service-programming
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
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 <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
