[spring] Gunter Van de Velde's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS)
Gunter Van de Velde via Datatracker <noreply@ietf.org> Wed, 21 January 2026 11:16 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: spring@ietf.org
Delivered-To: spring@mail2.ietf.org
Received: from [10.244.6.159] (unknown [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id 27D11AADDE26; Wed, 21 Jan 2026 03:16:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Gunter Van de Velde via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.56.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <176899416197.1092530.13152390613283012897@dt-datatracker-865585c994-4fgh4>
Date: Wed, 21 Jan 2026 03:16:01 -0800
Message-ID-Hash: 22EFA2WXGV62XVAVZTRM5U63O4R7DOIL
X-Message-ID-Hash: 22EFA2WXGV62XVAVZTRM5U63O4R7DOIL
X-MailFrom: noreply@ietf.org
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: aretana.ietf@gmail.com, buraglio@forwardingplane.net, draft-ietf-spring-dhc-distribute-srv6-locator-dhcp@ietf.org, spring-chairs@ietf.org, spring@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Gunter Van de Velde <gunter.van_de_velde@nokia.com>
Subject: [spring] Gunter Van de Velde's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS)
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/_mifJ1edipWPGUfiHlW9OvA9oDo>
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>
Gunter Van de Velde has entered the following ballot position for draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13 # # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13.txt # This document describes a method for assigning SRv6 locators to SRv6 Segment Endpoint Nodes using DHCPv6. [DISCUSS#1] One thing I found myself wondering about is how these locators relate to the IGP algorithms they’re associated with. It may very well be that the current proposal is intentionally algorithm-agnostic, and that’s perfectly fine. With this DISCUSS, I’m mainly trying to better understand how this approach aligns with IGP flexible algorithms and to understand if this may be potentially described within the document. [DISCUSS#2] In addition, I’d like to get a sense of whether it would be considered good or bad practice for the SRv6 locator of algorithm 0 (assuming, as I suspect, that non-zero algorithms are not applicable here) to have a portion of its address space carved out and used for direct DHCP-based assignment to attached hosts. Operational guidance on this may be useful. [DISCUSS#3] in the security section i find no discussion on the risk of having locators or sub-sets of locators leak to hosts? This could pose a serious infrastructure security concern when the CPE is located at customer premise. [DISCUSS#4] The document does not talk about SRv6 csid locators and csid structures (RFC9800). Is that intentional? I’m looking forward to your thoughts and clarification on this. Gunter Van de Velde, Routing AD
- [spring] Gunter Van de Velde's Discuss on draft-i… Gunter Van de Velde via Datatracker
- [spring] Re: Gunter Van de Velde's Discuss on dra… Weiqiang Cheng
- [spring] Re: Gunter Van de Velde's Discuss on dra… Gunter van de Velde (Nokia)
- [spring] Re: Gunter Van de Velde's Discuss on dra… Gunter van de Velde (Nokia)
- [spring] Re: Gunter Van de Velde's Discuss on dra… Weiqiang Cheng
- [spring] Re: Gunter Van de Velde's Discuss on dra… Weiqiang Cheng
- [spring] Re: Gunter Van de Velde's Discuss on dra… Gunter van de Velde (Nokia)