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? ## If the managed CPE is within the network provider, then what operational issues are solved by mimicking DHCP-PD for SR here? ## Are Locators the only needed provisioning task to CPEs to have intra-access SR service? 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? ## 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”. ## Some of these issues can be fixed by having less words in 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.” ## 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 # "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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # General: please update all DHCP occurrences to DHCPv6. # You may cite RFC 7084 for considerations related to PD support. # Several of the considerations in RFC 8987 can be leveraged here are well Specifically, I would mirror the following Operational ones from RFC 8987 (replace delegated prefix with locator): 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? ## 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. Cheers, Med _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
