I revered this version of the document as I offered at 121. Here is my first pass. (sorry, it's written in MD) Hopefully it is useful:
Review of [Distribute SRv6 Locator by DHCP]( https://datatracker.ietf.org/doc/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp/04/ ) 1. `Segment Routing (SR) [RFC8402] allows a node to steer a packet flow along any path.` This could use some clarification. SR can't really steer a packet flow across *any* path, there are constraints based on which technology a device supports (SRv6, SR-MPLS, etc.). Perhaps something like `Segment Routing (SR) [RFC8402] allows a node to steer a packet flow along any supported path within an SR domain.` Actually, it may be more clear to simply use the definitions from 8402. This would provide consistency in terminology and presentation of the definitions. 3. `The CPE must be operator-managed and is only applicable when different arms of the same company operate their portions of the network separately, but must trust each other.` This is a bit hard to understand. I *think* what you are trying to say is something like `The CPE must be managed by the operator providing services or by a trusted partner.` Suggest `The DHCPv6 server is usually enabled on or relayed by the BRAS.` Suggest adding some references to DHCPv6-PD documents such as https://datatracker.ietf.org/doc/html/rfc8415#section-6.3 5. I think there should be some more documents referenced for the client behavior. Rather than (or in addition to) what you have laid out in 5.1.1, perhaps consider some reference to RFC 8415 if you are going to mention Request, Renew, Rebind, Release and Decline messages. Consider an SRv6OPS document explaining the use cases and operational considerations for this deployment model. Definition of "Client". You mention the terminology is described in RFC 8415, but I still found myself wondering what "client" meant. I went and verified, but perhaps re-iterating would make the readability a bit more smooth. Figure 4 could use some additional detail on where the DHCP locator server exists and what the path takes to the client (CPE?) 9. Security considerations There is no mention of how a compromised controller (possibly out of scope) or DHCP server could potentially impact traffic engineering and path engineering behavior. This is probably worth expanding upon. Overall I think some additional diagrams would be useful in showing the packet flow. Additionally, there is little that I can find here that clearly describes how this DHCP function would interact with existing DHCPv6-PD operations which are meant to provide internal addressing to hosts will interact with the DHCP locator block functions. I read the IA_SRV6_LOCATOR as being the differentiator, but perhaps being more explicit would improve clarity. nb On Thu, Nov 14, 2024 at 7:25 PM <internet-dra...@ietf.org> wrote: > Internet-Draft draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-05.txt is > now available. It is a work item of the Source Packet Routing in Networking > (SPRING) WG of the IETF. > > Title: Distribute SRv6 Locator by DHCP > Authors: Weiqiang Cheng > Ruibo Han > Changwang Lin > Daniel Voyer > Yuanxiang Qiu > Geng Zhang > Name: draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-05.txt > Pages: 18 > Dates: 2024-11-14 > > Abstract: > > In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned > an SRv6 locator, and segment IDs are generated within the address > space of this SRv6 locator. This document describes a method for > assigning SRv6 locators to SRv6 Segment Endpoint Nodes through > DHCPv6. > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp/ > > There is also an HTMLized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-05 > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-05 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > spring mailing list -- spring@ietf.org > To unsubscribe send an email to spring-le...@ietf.org >
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
