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 xiao.m...@zte.com.cn:
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 <chengweiqi...@chinamobile.com>
*To: *spring <spring@ietf.org>;
*Cc: *buraglio <burag...@forwardingplane.net>;spring-chairs <spring-
cha...@ietf.org>;dhcwg <dh...@ietf.org>;dhc-chairs <dhc-
cha...@ietf.org>;linchangwang.04414
<linchangwang.04...@h3c.com>;danvoyerwork
<danvoyerw...@gmail.com>;zhanggeng <zhangg...@chinamobile.com>;hanruibo
<hanru...@chinamobile.com>;
*Date: *2025年05月07日 12:56
*Subject: **[spring] Draft Update & Request for Reviews: draft-ietf-
spring-dhc-distribute-srv6-locator-dhcp*
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
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 -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
l...@pi.nu
loa.pi....@gmail.com
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
