[spring] Fw:New Version Notification fordraft-gong-spring-nd-advertise-srv6-locator-04.txt

Liyan Gong <gongliyan@chinamobile.com> Wed, 25 February 2026 09:55 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 E946CBDC7D3D; Wed, 25 Feb 2026 01:55:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 Xxr9A0BConbo; Wed, 25 Feb 2026 01:55:45 -0800 (PST)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [111.22.67.151]) by mail2.ietf.org (Postfix) with ESMTP id 0D569BDC7C56; Wed, 25 Feb 2026 01:55:14 -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:mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=m3nKdGe0nb431h13eWMWIvFI2OdEf2/LQlZzVT71JFYHsxt4C9BAals6EPrcAZRZdysT3l9NO/xPg ZzbOpYPE7xkvk41owyYi6I9pR1feMqaB4+YLPVYqSbXsVnM3VEnbswWj9MTs5PBv4yg+KGFBeKN6+4 V6KYHiER3+AQ0LRs=
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-app02-12002 (RichMail) with SMTP id 2ee2699ec7003d2-8d4ea; Wed, 25 Feb 2026 17:55:12 +0800 (CST)
X-RM-TRANSID: 2ee2699ec7003d2-8d4ea
X-RM-SPAM-FLAG: 00000000
Received: from gongliyan@chinamobile.com ( [10.2.146.35] ) by ajax-webmail-syy-appsvr05-11005 (Richmail) with HTTP; Wed, 25 Feb 2026 17:55:11 +0800 (CST)
Date: Wed, 25 Feb 2026 17:55:11 +0800
From: Liyan Gong <gongliyan@chinamobile.com>
To: "spring@ietf.org" <spring@ietf.org>, rtgwg <rtgwg@ietf.org>, IPv6 List <ipv6@ietf.org>, 6man <6man@ietf.org>
Message-ID: <2afd699ebc9bd62-000a9.Richmail.00003082153940001067@chinamobile.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1145740_1645374322.1772013311963"
X-Priority: 3
X-RM-TRANSID: 2afd699ebc9bd62-000a9
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: T7MIICR6MWVHEOPGZ6VVCXZWZVJTAADI
X-Message-ID-Hash: T7MIICR6MWVHEOPGZ6VVCXZWZVJTAADI
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [spring] Fw:New Version Notification fordraft-gong-spring-nd-advertise-srv6-locator-04.txt
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/nvRCmRj4C9ZrFJfAr--9ZlN32no>
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 All,





We are sharing an updated version of draft-gong-spring-nd-advertise-srv6-locator(revision-04) for your review and feedback.


This document proposes a method for SRv6 endpoints(e.g., hosts or CPEs) to advertise their SRv6 locators to a neighboring router using IPv6 Neighbor Discovery (ND) extensions.


This approach aims to simplify deployment in controlled scenarios where endpoints do not run traditional routing protocols.


This draft was previously presented at IETF 122 in the SPRING WG. Based on the valuable feedback received, we have revised the document with substantial clarifications and enhancements.


Key updates in version -04 include:


1. Enhanced motivation and applicability section, clarifying use cases such as SRv6 on hosts in data centers and static CPE deployments.


2. Explicit trust boundary and security guidance, emphasizing that the mechanism is designed for single administrative domains and is NOT RECOMMENDED for untrusted environments.


3. Scalability consideration: Added text suggesting that access routers may aggregate fine-grained locators before advertising to the core.


4. Structural improvements: Reorganized sections for better readability (e.g., separating Motivation and Process).


5. Editorial refinements throughout the text for clarity and alignment with RFC language conventions.


Following the suggestion from the meeting, we are also sending this update to the SPRING, RTGWG, and 6MAN mailing lists. 


We welcome your comments on any aspect of the draft.Thank you for your time and consideration.


Best regards,


Liyan



----邮件原文----发件人:internet-drafts <internet-drafts@ietf.org>收件人:Acee Lindem <acee.ietf@gmail.com>,Changwang Lin <linchangwang.04414@h3c.com>,Liyan Gong <gongliyan@chinamobile.com>抄 送: (无)发送时间:2026-02-25 17:31:28主题:New Version Notification for draft-gong-spring-nd-advertise-srv6-locator-04.txtA new version of Internet-Draftdraft-gong-spring-nd-advertise-srv6-locator-04.txt has been successfullysubmitted by Liyan Gong and posted to theIETF repository.Name:     draft-gong-spring-nd-advertise-srv6-locatorRevision: 04Title:    Advertise SRv6 Locator Information by IPv6 Neighbor DiscoveryDate:     2026-02-25Group:    Individual SubmissionPages:    11URL:      https://www.ietf.org/archive/id/draft-gong-spring-nd-advertise-srv6-locator-04.txtStatus:   https://datatracker.ietf.org/doc/draft-gong-spring-nd-advertise-srv6-locator/HTML:     https://www.ietf.org/archive/id/draft-gong-spring-nd-advertise-srv6-locator-04.htmlHTMLized: https://datatracker.ietf.org/doc/html/draft-gong-spring-nd-advertise-srv6-locatorDiff:     https://author-tools.ietf.org/iddiff?url2=draft-gong-spring-nd-advertise-srv6-locator-04Abstract:   In an SRv6 network, each SRv6 segment endpoint has at least one SRv6   Locator.  Through the SRv6 locator routes, other SRv6 segment nodes   can steer traffic to that node.  This document describes a method for   an SRv6 endpoint (e.g., a host or a customer provider edge (CPE)) to   advertise its SRv6 locator to a neighboring SRv6-aware router using   extensions to the IPv6 Neighbor Discovery (ND) protocol.  This   approach eliminates the need to run a full routing protocol stack on   simple endpoints, facilitating SRv6 deployment in controlled, trusted   domains such as data centers and managed access networks.The IETF SecretariatSubject:New Version Notification for draft-gong-spring-nd-advertise-srv6-locator-04.txtA new version of Internet-Draftdraft-gong-spring-nd-advertise-srv6-locator-04.txt has been successfullysubmitted by Liyan Gong and posted to theIETF repository.Name:     draft-gong-spring-nd-advertise-srv6-locatorRevision: 04Title:    Advertise SRv6 Locator Information by IPv6 Neighbor DiscoveryDate:     2026-02-25Group:    Individual SubmissionPages:    11URL:      https://www.ietf.org/archive/id/draft-gong-spring-nd-advertise-srv6-locator-04.txtStatus:   https://datatracker.ietf.org/doc/draft-gong-spring-nd-advertise-srv6-locator/HTML:     https://www.ietf.org/archive/id/draft-gong-spring-nd-advertise-srv6-locator-04.htmlHTMLized: https://datatracker.ietf.org/doc/html/draft-gong-spring-nd-advertise-srv6-locatorDiff:     https://author-tools.ietf.org/iddiff?url2=draft-gong-spring-nd-advertise-srv6-locator-04Abstract:   In an SRv6 network, each SRv6 segment endpoint has at least one SRv6   Locator.  Through the SRv6 locator routes, other SRv6 segment nodes   can steer traffic to that node.  This document describes a method for   an SRv6 endpoint (e.g., a host or a customer provider edge (CPE)) to   advertise its SRv6 locator to a neighboring SRv6-aware router using   extensions to the IPv6 Neighbor Discovery (ND) protocol.  This   approach eliminates the need to run a full routing protocol stack on   simple endpoints, facilitating SRv6 deployment in controlled, trusted   domains such as data centers and managed access networks.The IETF Secretariat