[spring] Re: [Teas] Re: New Version Notification fordraft-cheng-spring-srv6-encoding-network-sliceid-12.txt

Liyan Gong <gongliyan@chinamobile.com> Wed, 14 January 2026 10:39 UTC

Return-Path: <gongliyan@chinamobile.com>
X-Original-To: spring@mail2.ietf.org
Delivered-To: spring@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 65D9AA77DB43; Wed, 14 Jan 2026 02:39:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.397
X-Spam-Level:
X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=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=fail (1024-bit key) reason="fail (body has been altered)" header.d=chinamobile.com
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 EYXBvL9C3GNA; Wed, 14 Jan 2026 02:39:47 -0800 (PST)
Received: from cmccmta2.chinamobile.com (cmccmta6.chinamobile.com [111.22.67.139]) by mail2.ietf.org (Postfix) with ESMTP id B93BEA77DB24; Wed, 14 Jan 2026 02:39:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chinamobile.com; s=default; l=0; h=from:subject:message-id:to:cc:mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=l+IWgkBNWukyWOqQV96ZryZoMspcDOH3HePJV1c2+2ATA9SeThzHiAySXtl2HG51e/mgISC0LCPbZ Rdq6x5uFHAjl7S5yvo5UzUfKa2ND94fwPSwI3ZnxEoUp2fxXMP3iylI3DJEatNCXab19IJbOuOcw10 DJ/+ba/00q6N97Qc=
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[10.188.0.87]) by rmmx-syy-dmz-app05-12005 (RichMail) with SMTP id 2ee5696772705ae-1b6db; Wed, 14 Jan 2026 18:39:44 +0800 (CST)
X-RM-TRANSID: 2ee5696772705ae-1b6db
X-RM-SPAM-FLAG: 00000000
Received: from gongliyan@chinamobile.com ( [10.2.146.59] ) by ajax-webmail-syy-spmd04-11014 (Richmail) with HTTP; Wed, 14 Jan 2026 18:39:33 +0800 (CST)
Date: Wed, 14 Jan 2026 18:39:33 +0800
From: Liyan Gong <gongliyan@chinamobile.com>
To: adrian <adrian@olddog.co.uk>, spring <spring@ietf.org>, 6man <6man@ietf.org>, TEAS WG <teas@ietf.org>, IPv6 List <ipv6@ietf.org>
Message-ID: <2b06696736dd16f-000f0.Richmail.00002062252930706037@chinamobile.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_832544_331956354.1768387173737"
X-Priority: 3
X-RM-TRANSID: 2b06696736dd16f-000f0
Encrypt-Channel: web
X-RM-OA-ENC-TYPE: 0
X-RM-FontColor: 0
X-CLIENT-INFO: X-TIMING=0&X-MASSSENT=0&X-SENSITIVE=0
X-Mailer: Richmail_Webapp(V2.5.01)
Message-ID-Hash: J6SWXLBX7VKVFOJUNGCWX44SVPWATBFQ
X-Message-ID-Hash: J6SWXLBX7VKVFOJUNGCWX44SVPWATBFQ
X-MailFrom: gongliyan@chinamobile.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.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>, Shay Zadok <shay.zadok@broadcom.com>, Weiqiang Cheng <chengweiqiang@chinamobile.com>, Xuewei Wang <wangxuewei1@ruijie.com.cn>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [spring] Re: [Teas] Re: New Version Notification fordraft-cheng-spring-srv6-encoding-network-sliceid-12.txt
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/DqLAQrkd5L0t0Sy2Bzc3KLP1SLY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>

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 <adrian@olddog.co.uk>收件人:39Liyan Gong39 <gongliyan@chinamobile.com>,spring <spring@ietf.org>,396man39 <6man@ietf.org>,39TEAS WG39 <teas@ietf.org>,39IPv6 List39 <ipv6@ietf.org>抄 送: 39Changwang Lin39 <linchangwang.04414@h3c.com>,39Fenghua Ren39 <renfh3@chinaunicom.cn>,39Mingyu Wu39 <wumy@centec.com>,39Peiyong Ma39 <mapeiy@chinatelecom.cn>,39Shay Zadok39 <shay.zadok@broadcom.com>,39Weiqiang Cheng39 <chengweiqiang@chinamobile.com>,39Xuewei Wang39 <wangxuewei1@ruijie.com.cn>发送时间: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 <gongliyan@chinamobile.com> Sent: 13 January 2026 10:28To: 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 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 <internet-drafts@ietf.org>收件人:Changwang Lin <linchangwang.04414@h3c.com>,Fenghua Ren <renfh3@chinaunicom.cn>,Liyan Gong <gongliyan@chinamobile.com>,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>,xuewei wang <wangxuewei1@ruijie.com.cn>抄 送: (无)发送时间: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