Dear Adrian, Happy New Year! Thank you for your detailed review and valuable comments on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-12. They are greatly appreciated. We have addressed all your comments inline with [co-authors] and incorporated the updates in version draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13.
Best regards, Weiqiang From: Adrian Farrel via Datatracker Date: 2025-12-13 21:21 To: [email protected] CC: draft-ietf-spring-dhc-distribute-srv6-locator-dhcp.all; last-call; spring Subject: [spring] draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-12 ietf last call Rtgdir review Document: draft-ietf-spring-dhc-distribute-srv6-locator-dhcp Title: Distribute SRv6 Locator by DHCP Reviewer: Adrian Farrel Review result: Has Nits Hi, I did an "early" Routing Directorate review of this draft at -09, and I have been asked to do another review consistent with IETF Last Call. I apologise that this request did not reach me until after the end of that last call, but I have done my review as quickly as I could after getting the request. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Normally I would write: It would be helpful if you could consider these comments along with any other IETF last call comments that you receive, and strive to resolve them through discussion or by updating the draft. Obviously, the last call having completed, that doesn't apply, but the AD may well want to pick up any comments and add them to his processing, so addressing them now may save time later. Cheers, Adrian =========== Draft: draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-12 Review Date: 2025-12-13 Reviewer: Adrian Farrel ([email protected]) Review Result: Ready with nits Intended Status: Standards Track = Summary This document describes how to use DHCPv6 to assign SRv6 locators (that is routable IPv6 prefixes) to SRv6 segment endpoints. This document is easy enough to understand, and the protocol elements seem well defined, with error cases called out. I believe interoperable implementation would not be hard. Thanks to the authors for making document updates and clarifications to address the concerns I raised in my earlier review. On this reading I find only nits (or points so minor that we should call them nits). = Nits 3. s/BRAS(Broadband/BRAS (Broadband/ --- [Co-authors] We've updated it. 3. After the DHCPv6 server allocates PD, BRAS will add a network route corresponding to PD to local routing table and distribute the network route to the upstream routers. Possibly the language is slightly wrong here. PD is a process. What you name "PD" in this paragraph is the "delegated prefix". [Co-authors] Yes. We've fixed it. --- 3. The SRv6 Locator should be configured on CPE. Other devices in the network learn the SRv6 Locator route of the CPE. Is that s/CPE/CPE2/ in both cases? Or possibly, given the subsequent paragraph, s/on CPE/on the CPEs/ and s/of the CPE/of the CPEs/ [Co-authors] Agree, We've fixed it. --- 3. s/In Metro network/In a Metro network/ Or, better, s/In Metro network/In a MAN/ --- [Co-authors] We've changed it as "In a Metro network". 3. s/mobility requirements of CPE/mobility requirements of CPEs/ --- [Co-authors] Updated. 3. OLD CPE can be connected to the BRAS of local MAN NEW A CPE can be connected to the BRAS of the local MAN END --- [Co-authors] Updated. 3. s/could not be distributed/cannot be distributed/ s/routes to CPE on BRAS/routes to the CPE on the BRAS/ --- [Co-authors] We've fixed it. Section 3 formatting I believe that the paragraphs following the bullet points need to be indented so that the final paragraph ("To solve these") is not indented and clearly applies to both bullets. --- [Co-authors] Got it. 4.1 It would be wise to state that the length is a count of octets. E.g., - Option-Len: 12 + the length of IA_SRV6_LOCATOR-Options field in octets. --- [Co-authors] Fixed. 4.1 Although I don't think you need to give an example of the other IA option types ("i.e., IA_TA, IA_NA and IA_PD"), if you do, I think you should give a reference. --- [Co-authors] Updated. 4.2 Given that all the other lengths are counted in bits, you should indicate the units of Option-Len. --- [Co-authors] Updated. Section 5 You say: This document assumes that a single transaction for all of the IA options required on an interface is used, as recommended in Section 18.1 of [I-D.ietf-dhc-rfc8415bis]. Section 18.1 of [I-D.ietf-dhc-rfc8415bis] says: This document assumes that a client SHOULD use a single transaction for all of the IA options required on an interface I asked the authors of draft-ietf-dhc-rfc8415bis to clarify this for me, and it appears that the intention here is to guide implementers on the wise course of action, but there is no implication for interop or bits on the wire. Anyway, notwithstanding the use of "SHOULD", it is perfectly possible and legal for multiple transactions to be used. That means that your draft needs to support multiple transactions even if it is suboptimal or self-harm for an implementation. What do you think? Is this support automatic in your spec? If so, I think you might clarify this text as (note lower case usage): This document recommends the use of a single transaction for all of the IA options required on an interface is used, as recommended in Section 18.1 of [I-D.ietf-dhc-rfc8415bis]. This simplifies the client implementation and reduces the potential number of transactions required. However, a client may use multiple transactions and the processes described in this document will funciton correctly. --- [Co-authors]： Thank you, Adrian and Michael. Based on the discussion in the following link, we have revised the text. https://mailarchive.ietf.org/arch/msg/spring/Eg8ZrTuMEBfbFwG7W96-kdnirjA/ 5.1 OLD Upon receiving the Release message, the server MUST removes the lease and frees the locator, making it available for allocation to other clients. NEW Upon receiving the Release message, the server MUST remove the lease and free the locator, making it available for allocation to other clients. END [Co-authors]：Updated. --- 5.1 s/IGP protocol/IGP/ --- [Co-authors]：Got it. 5.2 The next hop of this route SHOULD point to the requesting client. This means it is allowed that the BRAS installs a local SRv6 Locator route that points somewhere else. Should you describe this "MAY" and explain why it would be done? [Co-authors]：Got it. We add following text: ”Through this route, the BRAS can access the Host under the CPE“ --- 5.3 The client SHOULD NOT send an IA_SRv6_LOCATOR option with 0 in the "LB-Len" and "LN-Len" fields (and an unspecified value (::) in the "SRv6-Locator" field). Two points here: 1. I wonder if you mean "and" or "or". That is, as currently written, the "SHOULD NOT" applies to ((LB-Len == 0) && (LN-Len == 0)). That is, of course, quite different to ((LB-Len == 0) || (LN-Len == 0)). [Co-authors]：Modified. 2. You have used "SHOULD NOT" which allows "MAY" do something different. You need to either change to "MUST NOT" or explain the "MAY" case. --- [Co-authors]：Updated. 5.4 s/searches SRv6 Locator prefix/searches the SRv6 Locator prefix/ [Co-authors]：Got it. --- 5.4 Upon receiving the Release message from the client or when the SRv6 Locator lease expires, the server reclaims the SRv6 Locator prefix resource and deletes the SRv6 Locator binding entry. If the DHCPv6 server functions as a BRAS device, the server also MAY delete the corresponding SRv6 Locator route locally. This feels a little odd. What would it mean to not delete the local route when the use of the prefix has gone away (and potentially been assigned to another use)? Which makes me wonder, as well, if there needs to be a hold-off before re-assigning a Locator for another use since the IGP (or other advertisement mechanism) might not have convered after the previous use was deleted. Similar text at the end of 5.5 [Co-authors]：We've modifed the text as suggestion. --- 5.5 the layer 3 network nodes close to the CPE I wonder whether "close to" has a more specific meaning than "in the same geographic neighborhood." [Co-authors]：Got it and modified the text as "the Layer 3 network node that is directly connected to the CPE." -- 5.5 s/via IGP../via IGP./ s/expires, If/expires, if/ --- [Co-authors]：Got it. 7. Any reason why you use "NO" and not "No"? [Co-authors]：Updated. --- 8. I wonder whether a reference for SRv6 security considerations wouldn't also be useful since an attack on the configuration of SRv6 Locators would surely be an attack on SRv6. --- 8. If not all parties use this mechanism to obtain an SRv6 Locator from the DHCPv6 server, there is the possibility of the same SRv6 Locator being used by more than one device. Note that this issue would exist on these networks even if DHCP were not used to obtain the SRv6 Locator. I think s/would/could/ because if you move from just one mechanism (that is not DHCP) to two mechanisms (one of which is DHCP) you are increasing the risk. But there is a mitigation which is to partition the available prefixes so that the different mechanisms can only assign Locators from non- intersecting pools. You might mention this. [Co-authors]：Got it and we've updated the text accordingly. _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
