Dear Mohamed, Thank you very much for your thorough review and insightful comments on our draft. We have carefully considered all of your comments and please see our inline replies below for details. Please let us know if you have any further thoughts or comments. B.R. Weiqiang
From: Mohamed Boucadair via Datatracker Date: 2026-01-16 23:46 To: The IESG CC: aretana.ietf; buraglio; draft-ietf-spring-dhc-distribute-srv6-locator-dhcp; spring-chairs; spring Subject: [spring] Mohamed Boucadair's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS and COMMENT) Mohamed Boucadair 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: ---------------------------------------------------------------------- Hi Weiqiang, Ruibo, Changwang, Daniel, and Geng, Thank you for the effort put into this specification. Thanks to Ran Chen for the OPSDIR review. I would appreciate a reply from the authors. Please find below some DISCUSSion points: # Deployment Assumptions, Pre-requisites: Clarity Other than the need to make it clear this is a sample topology, and not questioning which CPE class will support SR and that many statements here do not apply for Enterprise CEs, Section 3 has several issues that are problematic. Specifically: ## Administrative domains boundaries CURRENT: This deployment assumes that all of the relevant components in Figure 1 are part of a single trusted SR domain. It is not clear where the CPE is located (is it within the customer premises or is it within the provider network). There are several deployments out there for the location of CE/CPE. Note that there might be cases where a managed CE can even be used to service multiple customers (see rfc9889#section-3.3). If this is within the customer premises, how is this considered as “single trusted SR domain” given the attachment circuit between the Customer and Provider is co-managed and do not technically belong to a single domain? [Co-authors] The term 'Trusted Domain' has been discussed many times without a final clear definition. Based on previous discussions, at least one consensus is that all devices within the same operator's administrative domain are considered to be in the 'trusted domain,' where all devices and ports can be monitored and managed by the network management system. Even if the CPE is located within the customer premises, as long as the device itself and its ports are under the operator's administration, the risks remain manageable. However, it is indeed necessary to highlight potential risks. The co-author will add a risk statement regarding 'the attachment circuit between the Customer and Provider' in the new version. ## If the managed CPE is within the network provider, then what operational issues are solved by mimicking DHCP-PD for SR here? [Co-authors] There are two issues we hope to address: First, the number of customer-side devices may be substantial, making manual configuration inefficient. Second, on the BRAS side, SRv6 Locator routes cannot be dynamically distributed to WAN. ## Are Locators the only needed provisioning task to CPEs to have intra-access SR service? [Co-authors] While SRv6 Locator configuration is a key element, a complete provisioning solution encompasses more. It should be noted that this document focuses specifically on the configuration of SRv6 Locators; other aspects of provisioning are outside its current scope. CURRENT: In this network, operators hope to achieve interconnection between access users through End-to-End SRv6 tunnels. Taking the service traffic from Host1 to Host2 as an example, CPE1 is the SRv6 ingress node and CPE2 is the SRv6 egress node. Unless I’m missing something, extra configuration is needed so that SR source nodes (CPE in this case) can place “End-to-End SRv6 tunnels”. If my understanding is correct, then there will be a need of a mix set of mechanisms to provision the CPE. Is it justified from an operational standpoint to have several mechanisms here instead of using a common provisioning mechanism? [Co-authors] As mentioned above, additional configuration is indeed required. However, considering that customer-side devices are often low-cost boxes that may not even support IGP, using DHCP is an economical and straightforward approach. ## Mobility Requirements CURRENT: Moreover, the mobility requirements of CPEs are relatively high, and the access location of the same CPE often changes, so its IPv6 address cannot be fixed. I fail to understand this. I don’t see from where we have this “high” requirement for CPE mobility. At least, I don’t see how we can claim that as a general assumption, “access location” of CPEs “often changes”. ## BTW, I don’t see how the use of DHCP solves this issues, especially given the discussion in RFC7225 about “Additional States Considered Harmful”. [Co-authors] The frequent changes in the access location of the same CPE is indeed not the primary issue to be addressed in this document. As suggested, we will revise the relevant descriptions. ## Some of these issues can be fixed by having less words in Section 3. [Co-authors] We will optimize the text of section 3. # Multiple instances and RFC7227 Guidance CURRENT: A client can explicitly request multiple SRv6 Locator prefixes by sending multiple IA_SRV6_LOCATOR options. and A DHCP message may contain multiple IA_SRV6_LOCATOR Options (though each must have a unique IAID). and After receiving a DHCP message with multiple IA_SRV6_LOCATOR options at the same time, whether the server can assign multiple SRv6 Locators to the client depends on the server policy, which is out of scope for this document. This seems to conflict with this RFC 7227 guidance: “If multiple instances are allowed, the document MUST explain how to use them.” [Co-authors] This document does not change the original DHCPv6 mechanism, please refer to the description in https://datatracker.ietf.org/doc/html/draft-ietf-dhc-rfc8415bis-12#name-multiple-addresses-and-pref. ## BTW, other guidance from RFC 7227 seems not followed here such as: template for the defining the option (rfc7227#section-21), etc. Please check that guidance, if not done. Thanks [Co-authors] We will update the text to ensure it is fully aligned with the guidance from RFC 7227. # "Automatic" behaviors are problematic CURRENT: Upon receiving the Release message, the server MUST remove the lease and free the locator, making it available for allocation to other clients. This MUST is problematic as it assumes that the message will always be valid and that there is no policy to discard the release. There are other similar constructs in the document that I think need to be fixed. [Co-authors] We will revise all similar statements as suggested. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # General: please update all DHCP occurrences to DHCPv6. [Co-authors] Got it. # You may cite RFC 7084 for considerations related to PD support. [Co-authors] Will update. # Several of the considerations in RFC 8987 can be leveraged here are well [Co-authors] Will update. Specifically, I would mirror the following Operational ones from RFC 8987 (replace delegated prefix with locator): [Co-authors] Will update. O-1: The relay SHOULD implement an interface allowing the operator to view the active delegated prefixes. This SHOULD provide information about the delegated lease and client details such as the client identifier, next-hop address, connected interface, and remaining lifetimes. O-2: The relay SHOULD provide a method for the operator to clear active bindings for an individual lease, client, or all bindings on a port. O-3: To facilitate troubleshooting of operational problems between the delegating relay and other elements, it is RECOMMENDED that a time synchronization protocol be used by the delegating relays and DHCP servers. # Routing stability as an additional Operational Considerations In some setups, an aggregate is announced instead of individual prefixes for the sake of optimized RIBs. Withdrawal of specific routes triggered by releases may have lead to shrink announcements. An alternative behavior is to have a policy that governs that behavior. In such cases, the delegating routers will drop packets sent to specific prefix not “delegated” on the customer-facing interface. # Nits ## What is the purpose of the following? CURRENT: Telecom providers can use their IP Metro and Backbone networks to establish connectivity between access users who are located in different regions. Isn’t obvious that a network provider uses its network to provided intra-domain connectivity? [Co-authors] Got it. We will update. ## Paradigm and “any program” CURRENT: The network programming paradigm for SRv6 is specified in [RFC8986]. It describes how any behavior can be bound to a SID and how any network program can be expressed as a combination of SIDs. It also describes several well-known behaviors that can be bound to SRv6 SIDs. I suggest to simply state what that spec is about NEW: [RFC8986] introduces the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors. [Co-authors] Got it. Cheers, Med
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
