Subject: [spring] Re: Ketan Talaulikar's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS and COMMENT)
From: "Weiqiang Cheng" <[email-masked]>
To: ketant.ietf <[email-masked]>, hanruibo <[email-masked]>
Cc: The IESG <[email-masked]>, "aretana.ietf" <[email-masked]>, buraglio <[email-masked]>, draft-ietf-spring-dhc-distribute-srv6-locator-dhcp <[email-masked]>, spring-chairs <[email-masked]>, spring <[email-masked]>
Date: Tue, 3 Mar 2026 19:07:57 +0800
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>

Hi Ketan,

Thanks a lot for your comments.

We’ve just uploaded the new version of draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-15.

In response to your comments, the key updates are as follows:
1. The references to CPE and BRAS in Section 9 have been updated to be generic to DHCPv6 roles.
2. For non-zero flex-algo, some explanation text has been added.

Best regards,
Weiqiang Cheng

From: Ketan Talaulikar
Date: 2026-02-17 23:09
To: han
CC: The IESG; aretana.ietf; buraglio; draft-ietf-spring-dhc-distribute-srv6-locator-dhcp; spring-chairs; spring
Subject: [spring] Re: Ketan Talaulikar's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS and COMMENT)
Hi Ruibo,

Thanks for posting the update and the responses. Please check inline below for a few follow-up with KT.

Please consider the issues without follow-up as been addressed.

On Fri, Feb 13, 2026 at 11:02 PM han <[email-masked]> wrote:
Dear Ketan,
Thanks for your review and valuable comments., and we uploaded version 14 according to your suggestions. 
Please find our responses inline below.
And please let us know if you have any further comments.
Best regards,
Ruibo

-----邮件原件-----
发件人: Ketan Talaulikar via Datatracker [mailto:[email-masked]] 
发送时间: 2026年1月21日 19:53
收件人: The IESG
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Ketan Talaulikar's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS and COMMENT)
 
Ketan Talaulikar 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:
----------------------------------------------------------------------
 
Thanks to the authors and the WG for their work on this document.
 
I have a few points that I would like to discuss.
 
<discuss-1> Section 3
 
180     However, due to the following reasons, it is difficult to achieve
181     these requirements currently.
 
183     *  The configuration is very complex.
 
185        In a Metro network, the number of CPEs is very large and widely
186        distributed geographically.  Moreover, the mobility requirements
187        of CPEs are relatively high, and the access location of the same
188        CPE often changes, so its IPv6 address cannot be fixed.
 
190        At present, an SRv6 Locator can only be configured on each CPE
191        through a controller or the Command Line Interface (CLI), which
192        increases the configuration complexity.
 
194     *  SRv6 Locator routes cannot be dynamically distributed.
 
196        A CPE can be connected to the BRAS of local MAN through various
197        types of networks, such as leased line, optical fiber, etc.  Due
198        to the diversity of connections, IGP is usually only enabled
199        within the MAN, that is, IGP will not be deployed between CPE and
200        BRAS.
 
202        As a result, the SRv6 Locator route of CPE cannot be distributed
203        to the BRAS node through IGP, and the static route can only be
204        configured manually on the BRAS or the controller.  Configuring
205        routes to the CPE on the BRAS increases the cost and workload of
206        communication and coordination.
 
The first bullet disregards automation. It ignores that
there are several ways of "provisioning" that remove the complexity. This
argument also ignores the part that allocation of SRv6 Locators via DHCPv6
alone is not sufficient and there is still the part of SRv6 Policy provisioning
along with other things to get steering over them working.
 
About the second bullet, it is obvious that IGPs are not enabled towards
broadband CPEs. However, static route is not the only way for injecting customer
routes behind the CPE from the BRAS into the provider network. BRAS
implementations can have other route producers as well - this is a local and
implementation specific matter.
 
I can understand the obvious attraction of using the same DHCPv6 for the
provisioning/allocation of customer IPv6 addresses as well as the SRv6 Locator
to simplify operations and align with existing allocation techniques/mechanism
that are already operational in these networks. But I find all the above
justifications/reasons to not hold much weight. Could you reconsider updating
the motivation?
 
[Co-authors]Thanks, we updated it in chapter 3 of version 14.
 
<discuss-2> Section 5
 
501     For the advertisement of SRv6 locator routes, if the DHCP Relay or
502     DHCP Server device that assigns SRv6 Locators to CPEs is also a BRAS
503     device, it MAY locally advertise the CPE's SRv6 Locator route via the
504     IGP, enabling other SRv6 nodes to obtain the CPE's SRv6 Locator
505     route.
 
When redistributing the SRv6 Locator routes via IGPs, I assume that
they are advertised via the respective OSPF and IS-IS SRv6 Locator reachability
advertisements. I believe this is important to specify with reference to those
IGP RFCs. Further, when it comes to IGPs, there is also the algo associated with
the locators which is not covered by this spec. Does that mean, locators allocated
via DHCP belong only to the default algo 0? Or is there a plan to introduce algo
in the DHCP signaling as well? Regardless, would be good to clarify in this
document. But then they can be also advertised via BGP where there is no
distinction between SRv6 Locators and other IPv6 Prefix reachability (also no
algo).
 
[Co-authors] We added new fields about Flex-Algo in the new option in chapter 4.2 of version 14.

KT> Thanks. Section 5.5 needs to explain that the reachability for the SRv6 Locators with non-zero Algo have to be advertised as Locators - refer RFC9352 and RFC9513 for the specific TLV/LSA to be used. Those also need to be added as references. For Algo zero they can be advertised as normal prefix reachabilities.

<discuss-3> Section 5.2
 
511     As shown in Figure 5, when a BRAS device (functioning as a DHCP relay
512     or DHCP server) receives an SRv6 Locator allocation request from a
513     client, it MAY assign an SRv6 Locator to the client and install a
514     corresponding SRv6 Locator route locally.  The next hop of this route
515     SHOULD point to the requesting client.  Through this route, the BRAS
516     can access the Host under the CPE, while the BRAS MAY then advertise
517     this route via traditional routing protocols (e.g., an IGP) to allow
518     other routers to learn it.
 
520     Upon receiving an SRv6 Locator release request from the client, the
521     BRAS MUST release the allocated SRv6 Locator, remove the local SRv6
522     Locator route, and withdraw the previously advertised SRv6 Locator
523     route via the IGP.
 
525     Client---------------BRAS(Relay/Server)-------------Router
526     Alloc Locator  -->  Add SRv6 locator route
527                         Advertise SRv6 Locator route -->
528     Release Locator-->  Del SRv6 locator route
529                         Withdraw SRv6 Locator route  -->
530                    Figure 5: Advertisement of SRv6 Locator Route
 
The mechanism introduced in this document is a generic DHCPv6 feature.
I can understand the use of the BRAS example as a motivation but this applies
to several other deployment designs - e.g., SD-WAN, SRv6 Locator allocations to
hosts in an operator's DC, etc. As such, it is important to abstract the normative
and procedural text in section 5 from the BRAS-specific example. Can't the
procedures about route advertisement and programming be specified in a manner
that is not tied to BRAS?
 
[Co-authors] Thanks for this useful suggestion, we changed the scenario which is not tied to BRAS in version 14.
 
<discuss-4> Section 5.5
 
657     on the CPE's directly connected router.  This deployment assumes that
658     all relevant components shown in Figure 6 belong to a single trusted
659     SR domain.
 
661                   Client        DHCP Relay   DHCPv6 Server
662     +------+     +------+       +------+     +-----------+
663     | Host +-----+ CPE  +-------+Router+-----+    BRAS   |
664     +------+     +------+       +--+---+     +-----------+
665                                    |
666                                    |
667                             +------+-----+
668                             |  Backbone  |
669                             |  Network   |
670                             +------------+
671                Figure 6: CPE accessed through DHCP relay
 
What is meant by "relevant components"? Are Hosts a part of this?
Why only for the components in this Figure? Is it not applicable for the
others deployments (w/o a relay)? Also consider abstracting from the
BRAS-specific example - a more generic/normative way to say this would be
that the DHCP client, server, and relay all lie within the SR domain.
 
Please move/consolidate all these considerations and definitions of what
lies within the SR domain in the Security Considerations section.
Note that some of such text already exists but is wrongly placed under
Privacy Considerations.
 
Text about DHCP not having encryption is already covered in the security
considerations section but that is not connected to the risks by this new
extension. E.g. Could the customer/home user snoop DHCPv6 packets on CPE's
link to the provider and learn the SRv6 SIDs/Locator of the provider in a
home broadband scenario? What risks does that bring up? And then clarify
their mitigation as indicated by the best practices in section 5.1 of
RFC8754 (this is also touched upon but in section 9). The point is that
the CPE is now the border node (in the BRAS example) and it needs to have
the filtering abilities on internal/external interfaces as per RFC8754.
 
[Co-authors]Thanks, we updated chapter 9, please let us know if you have any further comments.
KT> Thanks. However, there are references to CPE and BRAS in section 9 that also need to be generalized for DHCPv6 roles.

 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 
Please find below some comments on this document inline in the idnits output of
v13. Lookout for the <EoRv13> tag at the end to ensure you are seeing the full
review.
 
90         SR can be instantiated on the IPv6 data plane through the use of the
91         Segment Routing Header (SRH) defined in [RFC8754].  SR instantiation
92         on the IPv6 data plane is referred to as SRv6.
 
<major> Strictly speaking SRH is not required for realization of SRv6. It is
only required when there is more than one segment and then we also have CSID.
Please consider rephrasing.
[Co-authors] Thanks, we added more descriptions in version 14.
 
129        are part of a single trusted SR domain.  The IP network customer
130        provider edge (CPE) must be managed by the operator providing
131        services or by a trusted partner.
 
<minor> Does it affect the document if the "trusted partner" part is removed?
[Co-authors] Thanks, we added more descriptions in chapter3 of version 14.
 
167        In this network, operators hope to achieve interconnection between
168        access users through End-to-End SRv6 tunnels.  Taking the service
169        traffic from Host1 to Host2 as an example, CPE1 is the SRv6 ingress
170        node and CPE2 is the SRv6 egress node.  The SRv6 Locator should be
 
<minor> End-to-End would perhaps mean host to host. Please consider rephrasing
to clarify that SRv6 is CPE to CPE.
 [Co-authors] Thanks, we changed it to CPE-to-CPE in version 14..
 
171        configured on the CPEs.  Other devices in the network learn the SRv6
172        Locator routes of the CPEs.
 
<minor> By "network" you mean the SP network and not the home network. Please
clarify.
[Co-authors] Thanks, we added more descriptions in version 14.
 
174        At the same time, SRv6 policies need to be configured on CPEs to
175        steer the service traffic between CPEs to the specified SRv6
176        forwarding path.  The SRv6 policy can be manually configured
177        statically or issued through the controller, and its specific
178        configuration method is out of the scope of this document.
 
<major> I am guessing this is about "provisioning" of SR Policies. This term
includes local configuration on the CPE (via CLI, NETCONF/YANG, APIs, etc.)
or signaling via a protocol from a controller. Please clarify.
 [Co-authors] Thanks, we changed “The SRv6 policy can be manually configured statically” to “The SRv6 policy can be manually configured statically (via command-line interface (CLI), NETCONF, YANG, APIs, etc.)”.
 
280        An IA_SRV6_LOCATOR option may only appear in the options area of a
281        DHCP message.  A DHCP message may contain multiple IA_SRV6_LOCATOR
282        Options (though each must have a unique IAID).
 
<major> Isn't the use of MAY and MUST appropriate here since it impacts
interoperability (e.g., error handling when the uniqueness check fails).
In general, I found there to be a few places where the use of BCP14 keywords
would be appropriate instead of their lowercase usage - I will leave it to
the authors' call.
 [Co-authors] Thanks, we check it in RFC 9915, and found the same words are used.
 
382           -  SRv6-Locator: 0-16 octets.  This field encodes the SRv6
383              Locator.  The SRv6 Locator is encoded in the minimal number of
384              octets for the given number of bits.  Trailing bits MUST be set
385              to zero and ignored when received.
 
<major> What is "the given number of bits"? Please merge the sentence below into
this field description for clarity. Perhaps:
 
"The SRv6 Locator is encoded in the minimal number of octets for the SRv6 SID
Locator length that is LB-Len plus LN-Len."
 
Then please add validation for these two length fields. Can one or both of them
be non-zero?
 [Co-authors] Thanks, we updated it in version 14.

KT> Can LB-Len + LN-Len be zero? Can SRv6 locator be a default route :: ? If not then the minimum should be 1 octet and hence LB-Len + LN-Len cannot be zero. Am I right?

Thanks,
Ketan

 
387           -  IALocator-Options: Options associated with this SRv6 Locator.
388              A variable-length field (determined by subtracting the length
389              of the SRv6-Locator from the Option-Len minus 12).  The Status
390              code "NoSRv6LocatorAvail" indicate the server has no locators
391              available to assign to the IA_SRv6_LOCATOR(s).
 
<question> I am not a DHCP expert and I am wondering if IALocator-Options is
a new set of options (none of which are introduced by this document) OR
if this is a field where existing DHCP options can be conveyed. If it is the
latter, what options are those? Can these aspects be clarified?
 [Co-authors] Yes, this draft defines two new DHCPv6 options，with two option values assigned by IANA, 149 and 150 (chapter 4 and chapter 8).
 
501        For the advertisement of SRv6 locator routes, if the DHCP Relay or
502        DHCP Server device that assigns SRv6 Locators to CPEs is also a BRAS
503        device, it MAY locally advertise the CPE's SRv6 Locator route via the
504        IGP, enabling other SRv6 nodes to obtain the CPE's SRv6 Locator
505        route.
 
<major> Isn't the above text already covered in the next section (5.2)? If so,
can the above paragraph be deleted? I find there is text related to route
processing in individual sub-sections and then also in section 5.2 which is
needless repetition and also affects the clarity. Please pick one approach
that is then consistently followed throughout section 5.
 [Co-authors] Thanks, we updated it in version 14.
 
507     5.2.  Advertisement of SRv6 Locator Route
 
<minor> If all of the route processing aspects are being consolidated in one
sub-section then please consider moving it as the last sub-section of section 5
after all the DHCP procedures are covered.
 [Co-authors] Thanks, we updated it in version 14.
 
569        After obtaining the SRv6 Locator assigned by the DHCPv6 server, how
570        to assign local SRv6 SIDs based on this SRv6 Locator, how to use
571        multiple assigned SRv6 Locators, and how to advertise these SRv6 SIDs
572        to the rest of the network are not within the scope of this document.
573        If the client uses the assigned SRv6 Locator to configure local SRv6
574        SIDs, the preferred and valid lifetimes of those SRv6 Locators MUST
575        NOT be longer than the remaining preferred and valid lifetimes
576        respectively for the assigned SRv6 Locator at any time.
 
<major> I am not able to follow the last sentence above. Is it meant to say -
"preferred and valid lifetimes of those SRv6 SIDs MUST NOT"? But then there
is no leasing/allocation of SRv6 SIDs. I think I am missing something here ...
 [Co-authors] Thanks, we added more descriptions in version 14.
 
595        DHCP allows a client to request new SRv6 Locators to be assigned by
596        sending additional new IA_SRV6_LOCATOR options.  However, a typical
597        operator usually prefers to assign a single, larger prefix.  In most
598        deployments, it is recommended that the client request a larger SRv6
599        Locator in its initial transmissions rather than request additional
600        SRv6 Locators later on.
 
<minor> Should that be RECOMMENDED - i.e., BCP14 keyword?
 [Co-authors] Thanks, we modified it.
 
622        When operating as a BRAS device, the DHCPv6 server MAY install a
623        local SRv6 Locator route pointing to the CPE and advertise this route
624        via an IGP upon assigning an SRv6 Locator to the CPE.
 
<minor> Please avoid repetition of such text in multiple sections and
consolidate all the route processing in one section. This happens in several
places under section 5 and so I will not point out further such instances.
 [Co-authors] Thanks, we updated it in version 14.
 
816     9.  Privacy Considerations
 
818        See Section 24 of [I-D.ietf-dhc-rfc8415bis] for the DHCP privacy
819        considerations.
 
821        The SR domain is a trusted domain, as defined in [RFC8402], Sections
822        2 and 8.2.  Having such a well-defined trust boundary is necessary in
823        order to operate SRv6-based services for internal traffic while
824        preventing any external traffic from accessing or exploiting the
825        SRv6-based services.  Care and rigor in IPv6 address allocation for
826        use for SRv6 SID allocations and network infrastructure addresses, as
827        distinct from IPv6 addresses allocated for end users and systems (as
828        illustrated in Section 5.1 of [RFC8754]), can provide the clear
829        distinction between internal and external address space that is
830        required to maintain the integrity and security of the SRv6 Domain.
 
832        When assigning SRv6 Locators to SRv6 Segment Endpoint Nodes using
833        DHCPv6 as specified in this document, CPEs and BRAS devices MUST
834        operate within a single trusted SR domain.
 
<major> The above two paragraphs are not privacy but security considerations?
 [Co-authors] Thanks, we changed it to security considerations in version 14.
 
895     11.2.  Informative References
 
897        [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
898                   Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
899                   (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
900                   <https://www.rfc-editor.org/info/rfc8754>.
 
<major> This should be normative reference due to the security considerations.
[Co-authors]Thanks, we updated the references, please let us know if you have any further comments.
 
<EoRv13>