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 <https://www.ietf.org/archive/id/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-15.html#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:38 PM 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 <[email protected]> > *Date:* 2026-02-17 23:09 > *To:* han <[email protected]> > *CC:* 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]> > *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 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]
