[spring] Re: Draft Update & Request for Reviews: draft-i etf-spring-dhc-distribute-srv6-locator-dhcp

All,

If I read the IETF Data Tracker correctly we have a Dynamic Host 
Configuration WG.

Maybe we should tell them about this draft and ask for comments.

/Loa

Den 16/05/2025 kl. 14:14, skrev [email protected]:
> Dear authors,
> 
> 
> I have a few comments on your draft "Distribute SRv6 Locator by DHCP".
> 
> * Section 4.1, the IA_SRV6_LOCATOR option is a new DHCPv6 option 
> introduced by this draft, I suggest to provide an explicit list of DHCP 
> messages in which this new DHCPv6 option can be carried in. A typo needs 
> to be fixed, s/Identify Association/Identity Association, there are 
> three places for this typo.
> 
> * Section 4.2, the field definition for "IALocator-Options" is as following:
> 
> "     -  IALocator-Options: Options associated with this SRv6 locator.
>           A variable-length field (28 octets less than the value in the
>           Option-Len field)."
> 
> It defines some options associated with this SRv6 locator can be placed 
> here, I suggest to provide an explicit list of options if possible.
> 
> Furthermore, it says the length of IALocator-Options is "28 octets less 
> than the value in the Option-Len field", however the length of SRv6- 
> Locator is between 1 octet and 16 octets, it seems to me the length of 
> IALocator-Options is ("Option-Len" - 12 - "length of SRv6-Locator") but 
> not ("Option-Len" - 28).
> 
> * Section 4.2, there are four 1-octet fields LB-Len, LN-Len, Fun-Len, 
> and Arg-Len defined for the IA SRv6 Locator Option. As I understand it, 
> the value of these fields can't be larger than 128, if that's the case, 
> I suggest to add value range for each of these fields and specify how to 
> handle it if the value is over the range.
> 
> * Section 5.1, it says "Upon receiving the Release message, the server 
> removes the lease and frees the locator...", suggest to add normative 
> language MUST into this sentence, that means it should read "Upon 
> receiving the Release message, the server MUST remove the lease and 
> frees the locator...".
> 
> * Section 5.2, it says "In a message sent by a client to a server, the 
> preferred-lifetime and valid-lifetime fields SHOULD be set to 0", why 
> SHOULD but not MUST? Within the next paragraph it says "The client 
> SHOULD NOT send an IA SRv6 Locator option with 0 in the "LB-Len" and 
> "LN-Len" fields", why SHOULD NOT but not MUST NOT?
> 
> * Section 5.4, it says "After receiving the DHCPv6 Release and Decline 
> messages from the client...", suggest to replace "and" with "or", that 
> means it should read "After receiving the DHCPv6 Release or Decline 
> messages from the client...".
> 
> Hope these comments can help to improve this draft.
> 
> 
> Best Regards,
> 
> Xiao Min
> 
> Original
> *From: *WeiqiangCheng <[email protected]>
> *To: *spring <[email protected]>;
> *Cc: *buraglio <[email protected]>;spring-chairs <spring- 
> [email protected]>;dhcwg <[email protected]>;dhc-chairs <dhc- 
> [email protected]>;linchangwang.04414 
> <[email protected]>;danvoyerwork 
> <[email protected]>;zhanggeng <[email protected]>;hanruibo 
> <[email protected]>;
> *Date: *2025年05月07日 12:56
> *Subject: **[spring] Draft Update & Request for Reviews: draft-ietf- 
> spring-dhc-distribute-srv6-locator-dhcp*
> _______________________________________________
> spring mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> Dear All,
> 
> The co-authors have updated draft-ietf-spring-dhc-distribute-srv6- 
> locator-dhcp version -08.
> Draft link：https://www.ietf.org/archive/id/draft-ietf-spring-dhc- 
> distribute-srv6-locator-dhcp-08.html
> This revision addresses all comments received to date, and we believe 
> the document is now ready for Working Group Last Call (WGLC).
> 
> We would like to express our sincere appreciation to Nick for agreeing 
> to serve as the document shepherd.
> 
> Backgroud of the draft:
> - Proposes a mechanism for SRv6 locator assignment to Segment Endpoint 
> Nodes via DHCPv6, applicable within trusted domains.
> - Successfully implemented by H3C and Raisecom.
> - Validated through field testing by China Mobile, confirming full 
> functional and interoperability compliance with requirements.
> 
> Request for Feedback
> To facilitate comprehensive alignment with the broader SPRING and DHC 
> WGs, we kindly request feedback on the following aspects:
> - Further Technical Review
> - Use Case Expansion, such as:
> Are there additional deployment scenarios that should be explicitly 
> addressed?
> - Any other editorial or technical suggestions to improve clarity and 
> interoperability.
> 
> Best regards,
> Weiqiang Cheng
> On behalf of the co-authors
> 
> 
> 
> 
> 
> _______________________________________________
> spring mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[email protected]
[email protected]

_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]