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