Dear Adrian,
Thank you for your valuable feedback. We will carefully review RFC 9543 and the related drafts to better align the terminology and refine the positioning of our work. Once We have a clearer revision plan, We will follow up for further discussion. Best regards, Liyan ----邮件原文----发件人：Adrian Farrel <[email protected]>收件人：39Liyan Gong39 <[email protected]>,spring <[email protected]>,396man39 <[email protected]>,39TEAS WG39 <[email protected]>,39IPv6 List39 <[email protected]>抄 送: 39Changwang Lin39 <[email protected]>,39Fenghua Ren39 <[email protected]>,39Mingyu Wu39 <[email protected]>,39Peiyong Ma39 <[email protected]>,39Shay Zadok39 <[email protected]>,39Weiqiang Cheng39 <[email protected]>,39Xuewei Wang39 <[email protected]>发送时间：2026-01-13 20:08:54主题：RE: [Teas] Re: New Version Notification for draft-cheng-spring-srv6-encoding-network-sliceid-12.txt Hello, Thanks for continuing to work on your draft. I think it would be really helpful to try to align your terminology with other work on network slicing. For example: A network slice and a network resource partition are not the same thing (RFC 9543). So a slice ID and an NRP ID are different. While it might be possible to have a 1:1 mapping between slice and NRP, this is unlikely to be normal. There may be a difference between a network resource partition identifier (NRP-ID) and a network resource partition selector identifier (NRPS ID) (draft-ietf-teas-nrp-scalability section 5.2 and draft-ietf-teas-ns-ip-mpls) It might also be useful to look at drafts that already exist and have been adopted by working groups to discover where you are “competing” with existing IETF work and where you supplement it. Cheers, Adrian From: Liyan Gong <[email protected]> Sent: 13 January 2026 10:28To: [email protected] 6man <[email protected]> TEAS WG <[email protected]> IPv6 List <[email protected]>Cc: Changwang Lin <[email protected]> Fenghua Ren <[email protected]> Mingyu Wu <[email protected]> Peiyong Ma <[email protected]> Shay Zadok <[email protected]> Weiqiang Cheng <[email protected]> Xuewei Wang <[email protected]>Subject: [Teas] Re: New Version Notification for draft-cheng-spring-srv6-encoding-network-sliceid-12.txt Dear All, We have updated the individual draft **draft-cheng-spring-srv6-encoding-network-sliceid** to version **-12**. We would greatly appreciate your review and comments on this new revision. This document describes a method to encode a Network Slice Identifier(NRP-ID) within the outer IPv6 header of SRv6 packets. It enables routers along a path to identify the slice and apply specific forwarding treatment, facilitating slice-aware traffic steering across an SRv6 domain. The primary goal of this update is to refine the document39s clarity, address security considerations, and enhance its readiness for wider review. **Key updates in version -12 include:** 1. **Security Considerations Section:** Significantly expanded to define a concrete trust model for the proposed encoding methods. It now includes a threat analysis and discusses mitigation strategies relevant to operational deployment. 2. **Clarification on SPI Encoding Options:** Enhanced descriptions for both SPI encoding options (Traffic Class bit and Source Address prefix), with a clearer comparison of their backward compatibility implications. 3. **Backward Compatibility Section:** Updated to more explicitly detail the deployment and interoperability characteristics of each SPI option, helping operators understand the migration path. 4. **Editorial Improvements:** Various text refinements, structure adjustments, and typo fixes throughout the document to improve readability. Furthermore, the proposed encoding mechanism has undergone practical validation.It was successfully applied to realize "Link Slicing over SRv6" (use case 3.21)in the 2024 MPLS&SDN Interoperability Test（EANTC）, enabling cross-vendor source address slicing integration. The insights from this implementation have informed the refinements in this document version. Following advice to socialize this work, we are sending this update to the SPRING, 6MAN, and TEAS mailing lists. Thank you for your time and consideration, looking forward to your feedback. Best Regards, Liyan ----邮件原文----发件人：internet-drafts <[email protected]>收件人：Changwang Lin <[email protected]>,Fenghua Ren <[email protected]>,Liyan Gong <[email protected]>,Mingyu Wu <[email protected]>,Peiyong Ma <[email protected]>,Shay Zadok <[email protected]>,Weiqiang Cheng <[email protected]>,Xuewei Wang <[email protected]>,xuewei wang <[email protected]>抄 送: (无)发送时间：2026-01-13 18:00:24主题：New Version Notification for draft-cheng-spring-srv6-encoding-network-sliceid-12.txtA new version of Internet-Draftdraft-cheng-spring-srv6-encoding-network-sliceid-12.txt has been successfullysubmitted by Liyan Gong and posted to theIETF repository.Name: draft-cheng-spring-srv6-encoding-network-sliceidRevision: 12Title: Encoding Network Slice Identification for SRv6Date: 2026-01-13Group: Individual SubmissionPages: 10URL: https://www.ietf.org/archive/id/draft-cheng-spring-srv6-encoding-network-sliceid-12.txtStatus: https://datatracker.ietf.org/doc/draft-cheng-spring-srv6-encoding-network-sliceid/HTML: https://www.ietf.org/archive/id/draft-cheng-spring-srv6-encoding-network-sliceid-12.htmlHTMLized: https://datatracker.ietf.org/doc/html/draft-cheng-spring-srv6-encoding-network-sliceidDiff: https://author-tools.ietf.org/iddiff?url2=draft-cheng-spring-srv6-encoding-network-sliceid-12Abstract: A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding in a specific NRP, some fields in the data packet are used to identify the NRP the packet belongs to, so that NRP-specific processing can be performed on each node along a path in the NRP. This document describes a novel method to encode NRP-ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP.The IETF SecretariatSubject：New Version Notification for draft-cheng-spring-srv6-encoding-network-sliceid-12.txtA new version of Internet-Draftdraft-cheng-spring-srv6-encoding-network-sliceid-12.txt has been successfullysubmitted by Liyan Gong and posted to theIETF repository.Name: draft-cheng-spring-srv6-encoding-network-sliceidRevision: 12Title: Encoding Network Slice Identification for SRv6Date: 2026-01-13Group: Individual SubmissionPages: 10URL: https://www.ietf.org/archive/id/draft-cheng-spring-srv6-encoding-network-sliceid-12.txtStatus: https://datatracker.ietf.org/doc/draft-cheng-spring-srv6-encoding-network-sliceid/HTML: https://www.ietf.org/archive/id/draft-cheng-spring-srv6-encoding-network-sliceid-12.htmlHTMLized: https://datatracker.ietf.org/doc/html/draft-cheng-spring-srv6-encoding-network-sliceidDiff: https://author-tools.ietf.org/iddiff?url2=draft-cheng-spring-srv6-encoding-network-sliceid-12Abstract: A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding in a specific NRP, some fields in the data packet are used to identify the NRP the packet belongs to, so that NRP-specific processing can be performed on each node along a path in the NRP. This document describes a novel method to encode NRP-ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP.The IETF Secretariat
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
