Dear Mohamed, Thank you for your insightful suggestions.
We have carefully considered your comments and uploaded version 14, please find our inline replies below for details. Please let us know if you have any further comments. B.R. Ruibo 发件人: [email protected] [mailto:[email protected]] 发送时间: 2026年2月3日 19:13 收件人: Weiqiang Cheng 抄送: aretana.ietf; buraglio; draft-ietf-spring-dhc-distribute-srv6-locator-dhcp; spring-chairs; spring; The IESG 主题: RE: [spring] Mohamed Boucadair's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS and COMMENT) Hi Weiqiang, Thank you for the follow-up. Apologies for the delay to replay as I was out last week. Please see inline. Cheers, Med De : Weiqiang Cheng <[email protected]> Envoyé : jeudi 22 janvier 2026 12:48 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; The IESG <[email protected]> Cc : aretana.ietf <[email protected]>; buraglio <[email protected]>; draft-ietf-spring-dhc-distribute-srv6-locator-dhcp <[email protected]>; spring-chairs <[email protected]>; spring <[email protected]> Objet : Re: [spring] Mohamed Boucadair's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS and COMMENT) 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 <mailto:[email protected]> Date: 2026-01-16 23:46 To: The IESG <mailto:[email protected]> CC: aretana.ietf <mailto:[email protected]> ; buraglio <mailto:[email protected]> ; draft-ietf-spring-dhc-distribute-srv6-locator-dhcp <mailto:[email protected]> ; spring-chairs <mailto:[email protected]> ; spring <mailto:[email protected]> 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. [Med] OK. Please add some text to call out these assumptions. You may consider delimiting the administration perimeters (customer, provider) in your figure as well. [Co-authors][v2]thanks, we updated it in chapter 3 of version 14. ## 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. [Med] This one can be achieved with automation. [Co-authors] [v2] Yes, the basic resources like IPv4/IPv6 address/locators needs to be allocated firstly, then the customer-side devices could be connected remotely, then other configurations could be achieved with automation. Second, on the BRAS side, SRv6 Locator routes cannot be dynamically distributed to WAN. [Med] Do you mean at the routing level? [Co-authors] [v2] Yes. ## 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. [Med] Noted. My comment was whether we have an operational solution if only the DHCP extension is in place? There is a dependency that I think we need to clarify in this spec. [Co-authors] [v2]Yes, if only the DHCP extension is in place for locators, an operational solution is to add other configurations via CLI, NETCONF/YANG, APIs, etc. We added some descriptions in chapter 3 of version 14. 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. [Med] I still see a tension here between the part where we say that “additional configuration is indeed required” and argument here. A way to close this is to have some text that says that there are deployment cases where having a mix of solutions to supply portions of required SR configuration may (or may not) be operationally viable. Such assessment is out of scope of this document. [Co-authors] [v2] Thanks, we updated it in chapter 3 of version 14 about adding configurations via CLI, NETCONF/YANG, APIs, etc. ## 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. [Med] Thanks. ## Some of these issues can be fixed by having less words in Section 3. [Co-authors] We will optimize the text of section 3. [Med] ACK # 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> https://datatracker.ietf.org/doc/html/draft-ietf-dhc-rfc8415bis-12#name-multiple-addresses-and-pref. [Med] Thanks, but my comment is about the new option defined in this spec. [Co-authors] [v2] Thanks, we updated it in chapter 4 and chapter 5 of version 14 based on the ietf-dhc-rfc8415bis(now it is RFC9915. ## 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. [Med] Thanks # "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. [Med] ACK. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # General: please update all DHCP occurrences to DHCPv6. [Co-authors] Got it. [Med] Thanks. # You may cite RFC 7084 for considerations related to PD support. [Co-authors] Will update. [Med] ACK # Several of the considerations in RFC 8987 can be leveraged here are well [Co-authors] Will update. [Med] Thanks. Specifically, I would mirror the following Operational ones from RFC 8987 (replace delegated prefix with locator): [Co-authors] Will update. [Med] Thanks 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. [Med] ACK/ ## 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. [Med] ACK. Cheers, Med ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
