[IPv6]Re: [Teas] Re: New Version Notification for draft-cheng-spring-srv6-encoding-network-sliceid-12.txt
Adrian Farrel <adrian@olddog.co.uk> Tue, 13 January 2026 12:10 UTC
Return-Path: <adrian@olddog.co.uk>
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 8CBFCA6F463F; Tue, 13 Jan 2026 04:10:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk
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 1uOHQ9XZTbYt; Tue, 13 Jan 2026 04:10:53 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 54814A6F4621; Tue, 13 Jan 2026 04:10:53 -0800 (PST)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 60DC8u7X030592; Tue, 13 Jan 2026 12:08:56 GMT
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D916A4604C; Tue, 13 Jan 2026 12:08:55 +0000 (GMT)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CA9104604A; Tue, 13 Jan 2026 12:08:55 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs4.iomartmail.com (Postfix) with ESMTPS; Tue, 13 Jan 2026 12:08:55 +0000 (GMT)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 60DC8rFH020515 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Jan 2026 12:08:54 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Liyan Gong' <gongliyan@chinamobile.com>, spring@ietf.org, '6man' <6man@ietf.org>, 'TEAS WG' <teas@ietf.org>, 'IPv6 List' <ipv6@ietf.org>
References: <176829842431.890869.7698440402790102786@dt-datatracker-5656579b89-r5kdq> <2afe696617762a5-0006b.Richmail.00004002254980008077@chinamobile.com>
In-Reply-To: <2afe696617762a5-0006b.Richmail.00004002254980008077@chinamobile.com>
Date: Tue, 13 Jan 2026 12:08:54 -0000
Organization: Old Dog Consulting
Message-ID: <019001dc8485$63cd54b0$2b67fe10$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0191_01DC8485.63D17360"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKOY0a/uExl9NDnlrU7w0SHqUwcuAG6HcU1s95uNTA=
Content-Language: en-gb
X-Originating-IP: 82.69.109.75
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=kiSZmHk40ocAsr2M/zLMw kPw6OZ84hDAgpK7i95Hy/A=; b=Nh+QMfeU27QsOnCZADDjkyF3sng1McX4ec4us bry76jqjRYQln0STWPbVlwnLbnGieHGzWdj+Vcqpqq90Tf/amTRCYeGNX9HtyFAK 3YzH+3BfmtBiPyx5IdW85mkiJR4gC9nRDC9itM5Xu6ERts02rMyqX+e3pG76YAGo v4G+0gFhCLhopKCniCTIgJ7qtvF7gsCGNu4xOiOvQhVICQvchIRyqr4NPb7pejze GlHKvr52wajUvB7gdqfD42UycLgeVvlm3eGRpeLiss9/1f/bhYE0xkdj3r/aQsby jpaJ0Aa5y1lr9XISgQlbinMMImI8WP7njKxAcd+8q9nFgR8vA==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1006-29464.005
X-TM-AS-Result: No--46.717-10.0-31-10
X-imss-scan-details: No--46.717-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1006-29464.005
X-TMASE-Result: 10--46.716800-10.000000
X-TMASE-MatchedRID: MZa17WpznP2N/VCJeShKRsfUN8L5A1DElxt9C6/8ucloyabnzqjiAM+W Yjg3WzyKESnP3J1QtqclCspsrTdIZr9PvFElCPTz+fCnS6ApknxFl9A34VWpsE+crEA4+nhZFXX sIV9lgAGMUr81xLsbiVIKqQUV7LKDpxmXmu3IpnXsrfmvTLX/ngrcxrzwsv5uC//1TMV5chNj6F lbTHljFgqYvLVBPXt5q/t8RQsHcFS/WlDWXBiGUNKXV89hdXtBX9knSHW8uXX2W3gEBC4gVHxIq QDhGF3sBKGWoFvqHjcUdVFYQdhblbLpO/F/qIdJHU6vnrTGfsbcnfzpNQnhvJIONJNyvJzUCs/d L4+vaSSKgkajXbcV3TU6ZG9uVWmEb3nQ9wmEox28IDbRgxhC7TllFsU0CXSPqqAda2WWSiuRdpE USo1EPRxqdt22rdOgofcTdSXIk73va4n8G0RwqKqClr/8PQ1OL9PWvrwT+NYRVuFekDGWuZ3A0h zVN/6KbKU12tKxoELMw7EtH+LN5kpJ0yjIJLUd72DTxTde6URvQcDgU8ITR45W0+D2JuwaebU/x PBdG2K0ibUqPtLyGrod396eFw9AMHMsPySKXp1dInhzedP5BysIuzCLc2mN6SmFaeUM9vfAuQ0x DMaXkL0h4a7VzXxjetAc7hM+LwFbyD9/tjDgUERfCdMIZ+bd/Sl5cYQQGW+uiAW0p38/t7Kw8Hx 0EGitZ2uNmQkKXF6ndn/LfNMv34Pbw023vELIhbTQ15Ff4GvfSQNpZkETVNBO21OxlsovB4N9b2 b2Ot66k6Ky999wUGCNbd4UoEC1UYDNjFXKL9Nj1vXr7GCgWkbgTmf4sxQ0mkCGwliFomubKItl6 1J/yZUdXE/WGn0FSlnU38LCY8sSsYwLhH7g0cj4n/1zCcLSA+LvZtjTX+dSjKiHjrLYn+gDx7ON z5ZW5yM0c1ktj9M=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Message-ID-Hash: F2LGHDYJYTBFVE5XJBFOB5J3ZBGV3KBL
X-Message-ID-Hash: F2LGHDYJYTBFVE5XJBFOB5J3ZBGV3KBL
X-MailFrom: adrian@olddog.co.uk
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: 'Changwang Lin' <linchangwang.04414@h3c.com>, 'Fenghua Ren' <renfh3@chinaunicom.cn>, 'Mingyu Wu' <wumy@centec.com>, 'Peiyong Ma' <mapeiy@chinatelecom.cn>, 'Xuewei Wang' <wangxuewei1@ruijie.com.cn>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: adrian@olddog.co.uk
Subject: [IPv6]Re: [Teas] Re: New Version Notification for draft-cheng-spring-srv6-encoding-network-sliceid-12.txt
List-Id: "IPv6 Maintenance Working Group (6man)" <ipv6.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/w_Icp8ALUR18S3ag9zjoTZR047Q>
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>
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 <gongliyan@chinamobile.com> Sent: 13 January 2026 10:28 To: spring@ietf.org; 6man <6man@ietf.org>; TEAS WG <teas@ietf.org>; IPv6 List <ipv6@ietf.org> Cc: Changwang Lin <linchangwang.04414@h3c.com>; Fenghua Ren <renfh3@chinaunicom.cn>; Mingyu Wu <wumy@centec.com>; Peiyong Ma <mapeiy@chinatelecom.cn>; Shay Zadok <shay.zadok@broadcom.com>; Weiqiang Cheng <chengweiqiang@chinamobile.com>; Xuewei Wang <wangxuewei1@ruijie.com.cn> 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 document's 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 <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> > 收件人:Changwang Lin <linchangwang.04414@h3c.com <mailto:linchangwang.04414@h3c.com> >,Fenghua Ren <renfh3@chinaunicom.cn <mailto:renfh3@chinaunicom.cn> >,Liyan Gong <gongliyan@chinamobile.com <mailto:gongliyan@chinamobile.com> >,Mingyu Wu <wumy@centec.com <mailto:wumy@centec.com> >,Peiyong Ma <mapeiy@chinatelecom.cn <mailto:mapeiy@chinatelecom.cn> >,Shay Zadok <shay.zadok@broadcom.com <mailto:shay.zadok@broadcom.com> >,Weiqiang Cheng <chengweiqiang@chinamobile.com <mailto:chengweiqiang@chinamobile.com> >,Xuewei Wang <wangxuewei1@ruijie.com.cn <mailto:wangxuewei1@ruijie.com.cn> >,xuewei wang <wangxuewei1@ruijie.com.cn <mailto:wangxuewei1@ruijie.com.cn> > 抄 送: (无) 发送时间:2026-01-13 18:00:24 主题:New Version Notification for draft-cheng-spring-srv6-encoding-network-sliceid-12.txt A new version of Internet-Draft draft-cheng-spring-srv6-encoding-network-sliceid-12.txt has been successfully submitted by Liyan Gong and posted to the IETF repository. Name: draft-cheng-spring-srv6-encoding-network-sliceid Revision: 12 Title: Encoding Network Slice Identification for SRv6 Date: 2026-01-13 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-cheng-spring-srv6-encoding-network-sliceid-12.txt Status: 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.html HTMLized: https://datatracker.ietf.org/doc/html/draft-cheng-spring-srv6-encoding-network-sliceid Diff: https://author-tools.ietf.org/iddiff?url2=draft-cheng-spring-srv6-encoding-network-sliceid-12 Abstract: 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 Subject:New Version Notification for draft-cheng-spring-srv6-encoding-network-sliceid-12.txt A new version of Internet-Draft draft-cheng-spring-srv6-encoding-network-sliceid-12.txt has been successfully submitted by Liyan Gong and posted to the IETF repository. Name: draft-cheng-spring-srv6-encoding-network-sliceid Revision: 12 Title: Encoding Network Slice Identification for SRv6 Date: 2026-01-13 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-cheng-spring-srv6-encoding-network-sliceid-12.txt Status: 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.html HTMLized: https://datatracker.ietf.org/doc/html/draft-cheng-spring-srv6-encoding-network-sliceid Diff: https://author-tools.ietf.org/iddiff?url2=draft-cheng-spring-srv6-encoding-network-sliceid-12 Abstract: 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
- [IPv6]Re: New Version Notification for draft-chen… Liyan Gong
- [IPv6]Re: [Teas] Re: New Version Notification for… Adrian Farrel