[spring] Re: Gunter Van de Velde's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS)

[Weiqiang Cheng <[e-mail]>]

Dear Gunter,
Thank you for your review and valuable discussion points. Please find our responses inline below.
Best regards,
Weiqiang
 
From: Gunter Van de Velde via Datatracker
Date: 2026-01-21 19:16
To: The IESG
CC: aretana.ietf; buraglio; draft-ietf-spring-dhc-distribute-srv6-locator-dhcp; spring-chairs; spring
Subject: Gunter Van de Velde's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS)
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.

[Co-authors] The current version does not consider adopting Flex-algo, mainly for two reasons: First, in many application scenarios, customer-side terminals do not support IGP; second, there is currently no clear demand for using Flex-algo. As per your suggestion, the authors will further analyze the value of IGP flexible algorithms in this scenario in subsequent work.

 
[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.
 [Co-authors] As mentioned above regarding the scenario of IGP flexible algorithms, we will analyze the requirements further. In this document, we will add some text on operational guidance in next version.

[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.

[Co-authors] We fully acknowledge the value of explicitly highlighting such risks. We will add text in the draft as you suggested. This clarification will be included in the Security Considerations section of the next revision.
 
[DISCUSS#4] The document does not talk about SRv6 csid locators and csid
structures (RFC9800). Is that intentional?

[Co-authors] This draft can support the csid defined in RFC9800. In Figure 3, the IA Locator Option Format can distinguish between Locator Block and Locator Node, and can handle compressed SID lists. In the new version of the draft, we will add some text, reference RFC9800, and clearly state support for CSID.
 
I’m looking forward to your thoughts and clarification on this.
 
Gunter Van de Velde,
Routing AD