Hi Bernie, Thank you very much for your thorough review and comments. Please see my comments in-line.
B.R. Weiqiang From: Bernie Volz Date: 2025-09-03 23:01 To: Alvaro Retana CC: draft-ietf-spring-dhc-distribute-srv6-locator-dhcp; spring-chairs; buraglio; spring; dhcwg; dhc-chairs Subject: [spring] Re: WG Last Call: draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-09 (Ends 2025-09-11) Hi: While I am not a SRv6 expert, I think I understand the essentials. And I am writing this with dhc wg co-chair hat off. In terms of DHCPv6 aspects, I do have two issues to point out: 1. In section 4.2, “When the sum LB-len, LN-len, Fun-len, and Arg-len exceeds 128 bits, the packet is deemed erroneous and must be discarded.” This kind of goes against the norm for DHCPv6. And is different for T1 greater than T2 and preferred vs valid lifetime handling in the document. Instead, this should just invalidate that particular option and processing should continue. A “minor” configuration or implementation issue should not prevent other DHCPv6 data in the packet from not being used and can cause a packet storm as clients keep sending messages without making (at least some) progress. [WQ] Thank you for highlighting the DHCPv6 design principle. In fact, we did debate the "discard" approach ourselves when we design it. Now we totally agree with you and will align the text with your comments in the next revision. 2. For Prefix Delegation, which seems to be the model for SRv6 locators, Confirm messages are not used. Hence, it should be removed from section 5.2? [WQ] agree, we will remove it in the new version. And a couple of minor nits … 1. In section 4.2 there is a reference to 8415bis section 10.2.10.1. The “The details about use of these values…” is a bit underclear as to whether it is referring to infinity values (which are never mentioned in 10.2.10.1) or just the lifetime values in general. Perhaps replace “these” with “lifetime”? [WQ] Got it. 2. In section 5.1, first paragraph it might be better to use Solicit, Request, Advertise, and Reply instead of lowercase? [WQ] Will modify them. Thanks. - Bernie Volz On Aug 28, 2025, at 4:22 PM, Alvaro Retana <[email protected]> wrote: [cc’iing the dhc WG. Sorry for the extra message, but the datatracker doesn’t have a way to add recipients to the automated message.] On August 28, 2025 at 4:20:21 PM, Alvaro Retana via Datatracker ([email protected]) wrote: Subject: WG Last Call: draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-09 (Ends 2025-09-11) This message starts a 2-week WG Last Call for this document. 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. File can be retrieved from: https://datatracker.ietf.org/doc/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp/ Please review and indicate your support or objection to proceed with the publication of this document by replying to this email keeping [email protected] in copy. Objections should be motivated and suggestions to resolve them are highly appreciated. Authors, and WG participants in general, are reminded again of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [1]. Appropriate IPR disclosures required for full conformance with the provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. Sanctions available for application to violators of IETF IPR Policy can be found at [3]. Thank you. [1] https://datatracker.ietf.org/doc/bcp78/ [2] https://datatracker.ietf.org/doc/bcp79/ [3] https://datatracker.ietf.org/doc/rfc6701/
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
