Ketan Talaulikar has entered the following ballot position for draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-15: No Objection
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. Thanks for addressing almost all of my comments in the previous ballot. This is an updated ballot for v15 that lists some comments to fix issues that have either crept in or remained unaddressed. 1) (problem with new text - not from my comments) Section 5.2. After obtaining the SRv6 Locator assigned by the DHCPv6 server, how to assign local SRv6 SIDs based on this SRv6 Locator, how to use multiple assigned SRv6 Locators, and how to advertise these SRv6 SIDs to the rest of the network are not within the scope of this document. In certain scenarios where multiple allocations are required—for example, when supporting the allocation of multiple SRv6 compressed Locators [RFC9800], or when SRv6 Locators for SRv6 VPN services need to be assigned separately—the allocation policy between the DHCPv6 client and DHCPv6 server MUST be consistent. I am not following the reference to RFC9800 here and the multiple SRv6 compressed Locator. Is there such a thing as "SRv6 compressed locators"? Aren't they just SRv6 Locators? I would suggest the following for the new text in bold above that was introduced. I don't know if this satisfies the person that you made these changes for (I have not checked all the threads), but at least you don't introduce/use wrong terms. However, in certain scenarios where multiple allocations are required (e.g., when multiple SRv6 Locators for say best-effort and low latency services with different algo are needed), the allocation policy between the DHCPv6 client and DHCPv6 server needs to be consistent. 2) (problem with new text - not from my comments) Section 5.3. Again, I am not aware of the discussion but the text does not make sense. CURRENT Note that the configuration behavior of the server and client SHOULD be consistent (e.g., "Clients and Servers new assign a single locator unless explicitly configured"). PERHAPS Note that the configuration behavior of the server and client SHOULD be consistent (e.g., "Clients and Servers assign a single locator unless explicitly configured"). 3) You missed my comment for section 4.2 KT> Can LB-Len + LN-Len be zero? Can SRv6 locator be a default route :: ? If not then the minimum should be 1 octet and hence LB-Len + LN-Len cannot be zero. Am I right? To make it easier for you, let me suggest the following and let me know if I am missing something. CURRENT SRv6-Locator: 0–16 octets. SUGGEST SRv6-Locator: 1–16 octets. CURRENT The sum of LB-Len, LN-Len, Fun-Len, and Arg-Len MUST NOT exceed 128 bits. If the sum exceeds 128 bits, the IA_SRV6_LOCATOR option MUST be marked as invalid, and the remainder of the message SHOULD be processed as if the packet did not include this option. SUGGEST The sum of LB-Len, LN-Len, Fun-Len, and Arg-Len MUST NOT exceed 128 bits. The sum of LB-Len and LN-Len MUST NOT be zero. If either of these conditions are violated, the IA_SRV6_LOCATOR option MUST be marked as invalid, and the remainder of the message SHOULD be processed as if the packet did not include this option. _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
