[IPv6]Re: [spring] Re: [mpls] Resuming discussion on draft-ietf-spring-sr-service-programming
liu.yao71@zte.com.cn Fri, 06 June 2025 10:12 UTC
Return-Path: <liu.yao71@zte.com.cn>
X-Original-To: ipv6@mail2.ietf.org
Delivered-To: ipv6@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 27D1531B289A; Fri, 6 Jun 2025 03:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNOcSVWspoWG; Fri, 6 Jun 2025 03:12:40 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [160.30.148.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 1AEB531B288E; Fri, 6 Jun 2025 03:12:40 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4bDHDy1c1yz8R048; Fri, 6 Jun 2025 18:12:34 +0800 (CST)
Received: from njy2app08.zte.com.cn ([10.40.13.206]) by mse-fl2.zte.com.cn with SMTP id 556ACI10030108; Fri, 6 Jun 2025 18:12:18 +0800 (+08) (envelope-from liu.yao71@zte.com.cn)
Received: from mapi (njy2app03[null]) by mapi (Zmail) with MAPI id mid203; Fri, 6 Jun 2025 18:12:20 +0800 (CST)
Date: Fri, 06 Jun 2025 18:12:20 +0800
X-Zmail-TransId: 2afb6842bf04ffffffffed9-ed82e
X-Mailer: Zmail v1.0
Message-ID: <20250606181220747MM_GQG06m8niU9G-UJW_B@zte.com.cn>
In-Reply-To: <9d126cad47214848a6aa4314d1f77a4b@huawei.com>
References: CAHT6gR9E-fCMJ0mS-t+7Ez3Ozud6W0kREP5CfKqbm9pNpUyEfg@mail.gmail.com,9d126cad47214848a6aa4314d1f77a4b@huawei.com
Mime-Version: 1.0
From: liu.yao71@zte.com.cn
To: fclad.ietf@gmail.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 556ACI10030108
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6842BF12.000/4bDHDy1c1yz8R048
Message-ID-Hash: QKNLVZVCFWUBWXXPB6ROY6ORGXAT6CNX
X-Message-ID-Hash: QKNLVZVCFWUBWXXPB6ROY6ORGXAT6CNX
X-MailFrom: liu.yao71@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: spring@ietf.org, mpls@ietf.org, ipv6@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [IPv6]Re: [spring] Re: [mpls] Resuming discussion on draft-ietf-spring-sr-service-programming
List-Id: "IPv6 Maintenance Working Group (6man)" <ipv6.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/WZPoWYKVVxfQ8ACm0ws4kf3ug84>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Owner: <mailto:ipv6-owner@ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Subscribe: <mailto:ipv6-join@ietf.org>
List-Unsubscribe: <mailto:ipv6-leave@ietf.org>
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.com@dmarc.ietf.org> To: Francois Clad <fclad.ietf@gmail.com>;spring <spring@ietf.org>; Cc: mpls@ietf.org <mpls@ietf.org>;6man <ipv6@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-leave@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.ietf@gmail.com> Sent: Monday, May 12, 2025 12:25 PM To: spring <spring@ietf.org> Cc: mpls@ietf.org; 6man <ipv6@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)
- [IPv6]Resuming discussion on draft-ietf-spring-sr… Francois Clad
- [IPv6]Re: [mpls] Resuming discussion on draft-iet… Cheng Li
- [IPv6]Re: [spring] Re: [mpls] Resuming discussion… liu.yao71
- [IPv6]Re: [mpls] Re: [spring] Re: Resuming discus… Cheng Li
- [IPv6]Re: [spring] Re: [mpls] Re: Re: Resuming di… liu.yao71
- [IPv6]Re: [mpls] Resuming discussion on draft-iet… Francois Clad
- [IPv6]Re: [spring] Re: [mpls] Resuming discussion… Francois Clad
- [IPv6]Re: [mpls] Resuming discussion on draft-iet… Cheng Li
- [IPv6]Re: [spring] Re: [mpls] Resuming discussion… liu.yao71
- [IPv6]Re: [mpls] Resuming discussion on draft-iet… Zafar Ali (zali)