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
