Hi Ketan,
Thanks for your quick reply and the detailed suggestions. They look good
overall. We'll incorporate them in next update and upload once the submission
window opens.
Best regards,
Weiqiang
---原始邮件---
发件人: Ketan Talaulikar <[email protected]>
发送时间: 2026-03-03 21:40:32
收件人: Weiqiang Cheng <[email protected]>
抄送: hanruibo <[email protected]>
The IESG <[email protected]>
"aretana.ietf" <[email protected]>
buraglio <[email protected]>
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
<[email protected]>
spring-chairs <[email protected]>
spring <[email protected]>
主题: Re: [spring] Re: Ketan Talaulikar's Discuss on
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13:(with DISCUSS and COMMENT)
Hi Weiqiang,
It seems like some of my comments were skipped over. Please check below. It
would be great if you can share the diff of the proposed changes (or via github
or any other way) so we can converge on this quickly.
1) (problem with new text - not from my comments) Section 5.2.
After obtaining the SRv6 Locator assigned by the DHCPv6 server, how to assign
local SRv6 SIDs based on this SRv6 Locator, how to use multiple assigned SRv6
Locators, and how to advertise these SRv6 SIDs to the rest of the network are
not within the scope of this document. In certain scenarios where multiple
allocations are required—for example, when supporting the allocation of
multiple SRv6 compressed Locators [RFC9800], or when SRv6 Locators for SRv6 VPN
services need to be assigned separately—the allocation policy between the
DHCPv6 client and DHCPv6 server MUST be consistent.
I am not following the reference to RFC9800 here and the multiple SRv6
compressed Locator. Is there such a thing as "SRv6 compressed locators"? Aren't
they just SRv6 Locators? I would suggest the following for the new text in bold
above that was introduced. I don't know if this satisfies the person that you
made these changes for (I have not checked all the threads), but at least you
don't introduce/use wrong terms.
However, in certain scenarios where multiple allocations are required (e.g.,
when multiple SRv6 Locators for say best-effort and low latency services with
different algo are needed), the allocation policy between the DHCPv6 client and
DHCPv6 server needs to be consistent.
2) (problem with new text - not from my comments) Section 5.3. Again, I am not
aware of the discussion but the text does not make sense.
CURRENT
Note that the configuration behavior of the server and client SHOULD be
consistent (e.g., "Clients and Servers new assign a single locator unless
explicitly configured").
PERHAPS
Note that the configuration behavior of the server and client SHOULD be
consistent (e.g., "Clients and Servers assign a single locator unless
explicitly configured").
3) You missed my comment for section 4.2
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?
To make it easier for you, let me suggest the following and let me know if I am
missing something.
CURRENT
SRv6-Locator: 0–16 octets.
SUGGEST
SRv6-Locator: 1–16 octets.
CURRENT
The sum of LB-Len, LN-Len, Fun-Len, and Arg-Len MUST NOT exceed 128 bits. If
the sum exceeds 128 bits, the IA_SRV6_LOCATOR option MUST be marked as invalid,
and the remainder of the message SHOULD be processed as if the packet did not
include this option.
SUGGEST
The sum of LB-Len, LN-Len, Fun-Len, and Arg-Len MUST NOT exceed 128 bits. The
sum of LB-Len and LN-Len MUST NOT be zero. If either of these conditions are
violated, the IA_SRV6_LOCATOR option MUST be marked as invalid, and the
remainder of the message SHOULD be processed as if the packet did not include
this option.
I hope this helps us close quickly.
In the meantime, I am clearing my DISCUSS ballot since those points have been
addressed.
Thanks,
Ketan
On Tue, Mar 3, 2026 at 4:38PM Weiqiang Cheng <[email protected]>
wrote:
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:02PM han <[email protected]> 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 protected]]
发送时间: 2026年1月21日 19:53
收件人: The IESG
抄送: [email protected] [email protected]
[email protected]
[email protected] [email protected]
主题: 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>
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
