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]
