Distribute SRv6 Locator by DHCP
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-16

[Ballot comment]
Hi Weiqiang, Ruibo, Changwang, Daniel, and Geng,

The changes made in [1] adequately address the comments in previous ballot [2].

Thank you for the discussion.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13&url2=draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-16&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/spring/DRJRYBrfEdHaY2-xZ0t4_at8Xjw/

[Ballot 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.

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-14

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-14.txt

Thank you for clearing and resolving most of the open discuss’s.
(see: https://mailarchive.ietf.org/arch/msg/spring/OH6glu4n3-PhEXcZDlTLNbHgFRs/)

The remaining discuss standing is:

“
[DISCUSS#3] in the security section i find no discussion on the risk of having
locators or sub-sets of locators leak to hosts? This could pose a serious
infrastructure security concern when the CPE is located at customer premise.

[Co-authors] We fully acknowledge the value of explicitly highlighting such risks. We will add text in the draft as you suggested. This clarification will be included in the Security Considerations section of the next revision.

GV2> Thank you
“

I found in the security section the following new textblob:

“
As a border node device,           
the CPE MUST implement appropriate traffic filtering capabilities on 
both its internal and external interfaces, as required by Section 5.1   
of [RFC8754].
“

While the document notes that filtering is required, it doesn’t explain why extending segment routing to the CPE is risky. Traditionally, SR-MPLS networks terminate MPLS at the BRAS, not at the customer’s CPE. Connecting the core segment-routing backbone directly to a CPE can introduce security concerns. Adding a brief discussion of these risks and their implications in the security section will help clarify the need for the recommended filters and safeguards.

Gunter Van de Velde,
Routing AD

[Ballot comment]
WIT AD comments: Thank you for the work that has been put into this document.

I do not see any transport-protocol related concerns, but I do encourage you to look at the phrase:
/SHOULD consider/
- which seems like a strange protocol requirement (i.e., what action does this require of an implementor/configurer?).

Similarly, the document says: /can be considered as expired/ which seems ambiguous regarding what action is neeeded. Perrhaps in this case, the document can say /has expired/ or similar.

[Ballot comment]
# Éric Vyncke INT AD comments for draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13
CC @evyncke

Thank you for the work put into this document. Due to lack of time, this is only a superficial review.

Thanks to Alvaro for having forwarded the WGLC to the DHC WG. Thanks to the authors for using rfc8415bis as the reference.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## COMMENTS (non-blocking)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

### Section 1

Please add a normative reference to DHCPv6.

### Section 3

`customer provider edge (CPE)` ? While "PE" usually "provider edge", most of the time "CPE" means "Customer-Premises Equipment" though?

`Other devices in the network learn the SRv6 Locator routes of the CPEs` sure but how ?

### Section 4.1

`unless values in those fields are 0` what is the guidance in this case ? The next paragraph gives recommendations for the server but none for the client.

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

I have a few points that I would like to discuss.

Section 3

180   However, due to the following reasons, it is difficult to achieve
181   these requirements currently.

183   *  The configuration is very complex.

185       In a Metro network, the number of CPEs is very large and widely
186       distributed geographically.  Moreover, the mobility requirements
187       of CPEs are relatively high, and the access location of the same
188       CPE often changes, so its IPv6 address cannot be fixed.

190       At present, an SRv6 Locator can only be configured on each CPE
191       through a controller or the Command Line Interface (CLI), which
192       increases the configuration complexity.

194   *  SRv6 Locator routes cannot be dynamically distributed.

196       A CPE can be connected to the BRAS of local MAN through various
197       types of networks, such as leased line, optical fiber, etc.  Due
198       to the diversity of connections, IGP is usually only enabled
199       within the MAN, that is, IGP will not be deployed between CPE and
200       BRAS.

202       As a result, the SRv6 Locator route of CPE cannot be distributed
203       to the BRAS node through IGP, and the static route can only be
204       configured manually on the BRAS or the controller.  Configuring
205       routes to the CPE on the BRAS increases the cost and workload of
206       communication and coordination.

The first bullet disregards automation. It ignores that
there are several ways of "provisioning" that remove the complexity. This
argument also ignores the part that allocation of SRv6 Locators via DHCPv6
alone is not sufficient and there is still the part of SRv6 Policy provisioning
along with other things to get steering over them working.

About the second bullet, it is obvious that IGPs are not enabled towards
broadband CPEs. However, static route is not the only way for injecting customer
routes behind the CPE from the BRAS into the provider network. BRAS
implementations can have other route producers as well - this is a local and
implementation specific matter.

I can understand the obvious attraction of using the same DHCPv6 for the
provisioning/allocation of customer IPv6 addresses as well as the SRv6 Locator
to simplify operations and align with existing allocation techniques/mechanism
that are already operational in these networks. But I find all the above
justifications/reasons to not hold much weight. Could you reconsider updating
the motivation?

Section 5

501   For the advertisement of SRv6 locator routes, if the DHCP Relay or
502   DHCP Server device that assigns SRv6 Locators to CPEs is also a BRAS
503   device, it MAY locally advertise the CPE's SRv6 Locator route via the
504   IGP, enabling other SRv6 nodes to obtain the CPE's SRv6 Locator
505   route.

When redistributing the SRv6 Locator routes via IGPs, I assume that
they are advertised via the respective OSPF and IS-IS SRv6 Locator reachability
advertisements. I believe this is important to specify with reference to those
IGP RFCs. Further, when it comes to IGPs, there is also the algo associated with
the locators which is not covered by this spec. Does that mean, locators allocated
via DHCP belong only to the default algo 0? Or is there a plan to introduce algo
in the DHCP signaling as well? Regardless, would be good to clarify in this
document. But then they can be also advertised via BGP where there is no
distinction between SRv6 Locators and other IPv6 Prefix reachability (also no
algo).

Section 5.2

511   As shown in Figure 5, when a BRAS device (functioning as a DHCP relay
512   or DHCP server) receives an SRv6 Locator allocation request from a
513   client, it MAY assign an SRv6 Locator to the client and install a
514   corresponding SRv6 Locator route locally.  The next hop of this route
515   SHOULD point to the requesting client.  Through this route, the BRAS
516   can access the Host under the CPE, while the BRAS MAY then advertise
517   this route via traditional routing protocols (e.g., an IGP) to allow
518   other routers to learn it.

520   Upon receiving an SRv6 Locator release request from the client, the
521   BRAS MUST release the allocated SRv6 Locator, remove the local SRv6
522   Locator route, and withdraw the previously advertised SRv6 Locator
523   route via the IGP.

525   Client---------------BRAS(Relay/Server)-------------Router
526   Alloc Locator  -->  Add SRv6 locator route
527                       Advertise SRv6 Locator route -->
528   Release Locator-->  Del SRv6 locator route
529                       Withdraw SRv6 Locator route  -->
530                   Figure 5: Advertisement of SRv6 Locator Route

The mechanism introduced in this document is a generic DHCPv6 feature.
I can understand the use of the BRAS example as a motivation but this applies
to several other deployment designs - e.g., SD-WAN, SRv6 Locator allocations to
hosts in an operator's DC, etc. As such, it is important to abstract the normative
and procedural text in section 5 from the BRAS-specific example. Can't the
procedures about route advertisement and programming be specified in a manner
that is not tied to BRAS?

Section 5.5

657   on the CPE's directly connected router.  This deployment assumes that
658   all relevant components shown in Figure 6 belong to a single trusted
659   SR domain.

661                 Client        DHCP Relay  DHCPv6 Server
662   +------+    +------+      +------+    +-----------+
663   | Host +-----+ CPE  +-------+Router+-----+    BRAS  |
664   +------+    +------+      +--+---+    +-----------+
665                                   |
666                                   |
667                           +------+-----+
668                           |  Backbone  |
669                           |  Network  |
670                           +------------+
671               Figure 6: CPE accessed through DHCP relay

What is meant by "relevant components"? Are Hosts a part of this?
Why only for the components in this Figure? Is it not applicable for the
others deployments (w/o a relay)? Also consider abstracting from the
BRAS-specific example - a more generic/normative way to say this would be
that the DHCP client, server, and relay all lie within the SR domain.

Please move/consolidate all these considerations and definitions of what
lies within the SR domain in the Security Considerations section.
Note that some of such text already exists but is wrongly placed under
Privacy Considerations.

Text about DHCP not having encryption is already covered in the security
considerations section but that is not connected to the risks by this new
extension. E.g. Could the customer/home user snoop DHCPv6 packets on CPE's
link to the provider and learn the SRv6 SIDs/Locator of the provider in a
home broadband scenario? What risks does that bring up? And then clarify
their mitigation as indicated by the best practices in section 5.1 of
RFC8754 (this is also touched upon but in section 9). The point is that
the CPE is now the border node (in the BRAS example) and it needs to have
the filtering abilities on internal/external interfaces as per RFC8754.

[Ballot comment]
Please find below some comments on this document inline in the idnits output of v13. Lookout for the  tag at the end to ensure you are seeing the full review.

90   SR can be instantiated on the IPv6 data plane through the use of the
91   Segment Routing Header (SRH) defined in [RFC8754].  SR instantiation
92   on the IPv6 data plane is referred to as SRv6.

Strictly speaking SRH is not required for realization of SRv6. It is only
required when there is more than one segment and then we also have CSID. Please
consider rephrasing.

129   are part of a single trusted SR domain.  The IP network customer
130   provider edge (CPE) must be managed by the operator providing
131   services or by a trusted partner.

Does it affect the document if the "trusted partner" part is removed?


167   In this network, operators hope to achieve interconnection between
168   access users through End-to-End SRv6 tunnels.  Taking the service
169   traffic from Host1 to Host2 as an example, CPE1 is the SRv6 ingress
170   node and CPE2 is the SRv6 egress node.  The SRv6 Locator should be

End-to-End would perhaps mean host to host. Please consider rephrasing
to clarify that SRv6 is CPE to CPE.

171   configured on the CPEs.  Other devices in the network learn the SRv6
172   Locator routes of the CPEs.

By "network" you mean the SP network and not the home network. Please
clarify.

174   At the same time, SRv6 policies need to be configured on CPEs to
175   steer the service traffic between CPEs to the specified SRv6
176   forwarding path.  The SRv6 policy can be manually configured
177   statically or issued through the controller, and its specific
178   configuration method is out of the scope of this document.

I am guessing this is about "provisioning" of SR Policies. This term
includes local configuration on the CPE (via CLI, NETCONF/YANG, APIs, etc.)
or signaling via a protocol from a controller. Please clarify.

280   An IA_SRV6_LOCATOR option may only appear in the options area of a
281   DHCP message.  A DHCP message may contain multiple IA_SRV6_LOCATOR
282   Options (though each must have a unique IAID).

Isn't the use of MAY and MUST appropriate here since it impacts
interoperability (e.g., error handling when the uniqueness check fails).
In general, I found there to be a few places where the use of BCP14 keywords
would be appropriate instead of their lowercase usage - I will leave it to
the authors' call.


382       -  SRv6-Locator: 0-16 octets.  This field encodes the SRv6
383         Locator.  The SRv6 Locator is encoded in the minimal number of
384         octets for the given number of bits.  Trailing bits MUST be set
385         to zero and ignored when received.

What is "the given number of bits"? Please merge the sentence below into
this field description for clarity. Perhaps:

"The SRv6 Locator is encoded in the minimal number of octets for the SRv6 SID
Locator length that is LB-Len plus LN-Len."

Then please add validation for these two length fields. Can one or both of them be
non-zero?


387       -  IALocator-Options: Options associated with this SRv6 Locator.
388         A variable-length field (determined by subtracting the length
389         of the SRv6-Locator from the Option-Len minus 12).  The Status
390         code "NoSRv6LocatorAvail" indicate the server has no locators
391         available to assign to the IA_SRv6_LOCATOR(s).

I am not a DHCP expert and I am wondering if IALocator-Options is
a new set of options (none of which are introduced by this document) OR
if this is a field where existing DHCP options can be conveyed. If it is the
latter, what options are those? Can these aspects be clarified?

501   For the advertisement of SRv6 locator routes, if the DHCP Relay or
502   DHCP Server device that assigns SRv6 Locators to CPEs is also a BRAS
503   device, it MAY locally advertise the CPE's SRv6 Locator route via the
504   IGP, enabling other SRv6 nodes to obtain the CPE's SRv6 Locator
505   route.

Isn't the above text already covered in the next section (5.2)? If so,
can the above paragraph be deleted? I find there is text related to route
processing in individual sub-sections and then also in section 5.2 which is
needless repetition and also affects the clarity. Please pick one approach
that is then consistently followed throughout section 5.

507 5.2.  Advertisement of SRv6 Locator Route

If all of the route processing aspects are being consolidated in one
sub-section then please consider moving it as the last sub-section of section 5 after
all the DHCP procedures are covered.


569   After obtaining the SRv6 Locator assigned by the DHCPv6 server, how
570   to assign local SRv6 SIDs based on this SRv6 Locator, how to use
571   multiple assigned SRv6 Locators, and how to advertise these SRv6 SIDs
572   to the rest of the network are not within the scope of this document.
573   If the client uses the assigned SRv6 Locator to configure local SRv6
574   SIDs, the preferred and valid lifetimes of those SRv6 Locators MUST
575   NOT be longer than the remaining preferred and valid lifetimes
576   respectively for the assigned SRv6 Locator at any time.

I am not able to follow the last sentence above. Is it meant to say -
"preferred and valid lifetimes of those SRv6 SIDs MUST NOT"? But then there
is no leasing/allocation of SRv6 SIDs. I think I am missing something here ...

595   DHCP allows a client to request new SRv6 Locators to be assigned by
596   sending additional new IA_SRV6_LOCATOR options.  However, a typical
597   operator usually prefers to assign a single, larger prefix.  In most
598   deployments, it is recommended that the client request a larger SRv6
599   Locator in its initial transmissions rather than request additional
600   SRv6 Locators later on.

Should that be RECOMMENDED - i.e., BCP14 keyword?

622   When operating as a BRAS device, the DHCPv6 server MAY install a
623   local SRv6 Locator route pointing to the CPE and advertise this route
624   via an IGP upon assigning an SRv6 Locator to the CPE.

Please avoid repetition of such text in multiple sections and consolidate
all the route processing in one section. This happens in several places under
section 5 and so I will not point out further such instances.

816 9.  Privacy Considerations

818   See Section 24 of [I-D.ietf-dhc-rfc8415bis] for the DHCP privacy
819   considerations.

821   The SR domain is a trusted domain, as defined in [RFC8402], Sections
822   2 and 8.2.  Having such a well-defined trust boundary is necessary in
823   order to operate SRv6-based services for internal traffic while
824   preventing any external traffic from accessing or exploiting the
825   SRv6-based services.  Care and rigor in IPv6 address allocation for
826   use for SRv6 SID allocations and network infrastructure addresses, as
827   distinct from IPv6 addresses allocated for end users and systems (as
828   illustrated in Section 5.1 of [RFC8754]), can provide the clear
829   distinction between internal and external address space that is
830   required to maintain the integrity and security of the SRv6 Domain.

832   When assigning SRv6 Locators to SRv6 Segment Endpoint Nodes using
833   DHCPv6 as specified in this document, CPEs and BRAS devices MUST
834   operate within a single trusted SR domain.

The above two paragraphs are not privacy but security considerations?

895 11.2.  Informative References

897   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
898               Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
899               (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
900               .

This should be normative reference due to the security considerations.

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13

# # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13.txt

# This document describes a method for assigning SRv6 locators to SRv6 Segment Endpoint Nodes using DHCPv6.

[DISCUSS#1] One thing I found myself wondering about is how these locators relate to the IGP algorithms they’re associated with. It may very well be that the current proposal is intentionally algorithm-agnostic, and that’s perfectly fine. With this DISCUSS, I’m mainly trying to better understand how this approach aligns with IGP flexible algorithms and to understand if this may be potentially described within the document.

[DISCUSS#2] In addition, I’d like to get a sense of whether it would be considered good or bad practice for the SRv6 locator of algorithm 0 (assuming, as I suspect, that non-zero algorithms are not applicable here) to have a portion of its address space carved out and used for direct DHCP-based assignment to attached hosts. Operational guidance on this may be useful.

[DISCUSS#3] in the security section i find no discussion on the risk of having locators or sub-sets of locators leak to hosts? This could pose a serious infrastructure security concern when the CPE is located at customer premise.

[DISCUSS#4] The document does not talk about SRv6 csid locators and csid structures (RFC9800). Is that intentional?

I’m looking forward to your thoughts and clarification on this.

Gunter Van de Velde,
Routing AD

[Ballot comment]
Thank you to Linda Dunbar for the GENART review.

** To the Responsible AD/WG Chairs: The SPRING charter says “The SPRING WG will manage its specific work items by milestones agreed with the responsible Area Director.”  There is no milestone for this document (or the 12 other documents that are adopted in the WG).  I am assuming there was some kind of agreement since this document advanced to the telechat. Please either adjust the milestones or recharter the WG to remove this explicit step coordinate with the AD (or some other approach consistent with the approved charter).

[Ballot comment]
Section 2, paragraph 0
>    This document leverages the terms defined in
>    [I-D.ietf-dhc-rfc8415bis] and [RFC8986].  The reader is assumed to be
>    familiar with this terminology.

It would be helpful to identify which terms are being reused in this document from these other documents.

Section 4.1, paragraph 0
>    The Identity Association for SRv6 Locator (IA_SRV6_LOCATOR) option is
>    used to carry an IA_SRV6_LOCATOR, the parameters associated with the
>    IA_SRV6_LOCATOR, and the SRv6 Locator associated with the
>    IA_SRV6_LOCATOR.

Not clear this option is part of SRH, DHCP, or something else. This is apparent only later when reading sections, e.g., Section 5.3.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "man"; alternatives might be "individual", "people", "person"
* Term "traditional"; alternatives might be "classic", "classical", "common",
  "conventional", "customary", "fixed", "habitual", "historic",
  "long-established", "popular", "prescribed", "regular", "rooted",
  "time-honored", "universal", "widely used", "widespread"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3, paragraph 6
>    At the same time, SRv6 policies need to be configured on CPEs to
>    steer the service traffic between CPEs to the specified SRv6
>    forwarding path.  The SRv6 policy can be manually configured
>    statically or issued through the controller, and its specific
>    configuration method is out of the scope of this document.

s/manually configured statically/manually configured/.
s/through the controller, and its/through the controller. The specific/

Section 3, paragraph 7
>    *  The configuration is very complex.

The complexity comes from the mobility requirements of CPEs, not from the configuration itself. If anything, the result of mobility is why the configuration is complex. Maybe say:
“Mobility requirement of CPE increases complexity”.

Section 4.1, paragraph 3
>      -  Option-Code: OPTION_IA_SRV6_LOCATOR, the option code for the
>          Identity Association for SRv6 Locator.  The current value early
>          assigned by IANA is 149.

s/The current value early assigned by IANA is 149/The current value of 149 was requested as part of an early assignment from IANA/

Section 7, paragraph 0
>    IANA has early assigned the following new DHCPv6 Option Codes in the
>    "Option Codes" registry maintained at
>    https://www.iana.org/assignments/dhcpv6-parameters.

s/IANA has early assigned/IANA through its early assignment policy assigned/

Section 8, paragraph 1
>    As discussed in Section 23 of [I-D.ietf-dhc-rfc8415bis]: DHCP lacks
>    end-to-end encryption between clients and servers; thus, hijacking,
>    tampering, and eavesdropping attacks are all possible as a result.

s/attacks are all possible/attacks are possible/

These URLs in the document did not return content:

* http://www.iana.org/assignments/dhcpv6-parameters:

Section 4, paragraph 5
> RV6_LOCATOR are in the IA_SRV6_LOCATOR- Options field. An IA_SRV6_LOCATOR opt
>                                ^^^^^^^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

Section 4.2, paragraph 2
> t unsigned integer. - SRv6-Locator: 0-16 octets. This field encodes the SRv6
>                                    ^^^^
If specifying a range, consider using an en dash instead of a hyphen.

[Ballot comment]
# Internet AD comments for draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S3

* "After the DHCPv6 server allocates delegated prefix" ->
  "After the DHCPv6 server allocates any delegated prefix"

  I think if the phrasing is careful we can make sure this reads as applying
  to *each* prefix that a DHCPv6 server might provision (not just one).

[Ballot comment]
I believe there is one (obvious) error in the document:


  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
  .                        SRv6-Locator                          .
  .                      (up to 16 octets)                        .
  .                                                              .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and:

Option-Len: 28 + the length of IALocator-Options field in octets.


The 28 seems only valid when SRv6-Locator is 16, but it is "up to 16",
and is defined as between 0-16 octets.

Perhaps:

Option-Len: 12 + the length of SRv6-Locator + the length of IALocator-Options field in octets.

[Ballot discuss]
Hi Weiqiang, Ruibo, Changwang, Daniel, and Geng,

Thank you for the effort put into this specification.

Thanks to Ran Chen for the OPSDIR review. I would appreciate a reply from the authors.

Please find below some DISCUSSion points:

# Deployment Assumptions, Pre-requisites: Clarity

Other than the need to make it clear this is a sample topology, and not questioning which CPE class will support SR and that many statements here do not apply for Enterprise CEs, Section 3 has several issues that are problematic. Specifically:

## Administrative domains boundaries

CURRENT:
  This
  deployment assumes that all of the relevant components in Figure 1
  are part of a single trusted SR domain. 

It is not clear where the CPE is located (is it within the customer premises or is it within the provider network).

There are several deployments out there for the location of CE/CPE. Note that there might be cases where a managed CE can even be used to service multiple customers (see rfc9889#section-3.3).

If this is within the customer premises, how is this considered as “single trusted SR domain” given the attachment circuit between the Customer and Provider is co-managed and do not technically belong to a single domain?

## If the managed CPE is within the network provider, then what operational issues are solved by mimicking DHCP-PD for SR here?

## Are Locators the only needed provisioning task to CPEs to have intra-access SR service?

CURRENT:
  In this network, operators hope to achieve interconnection between
  access users through End-to-End SRv6 tunnels.  Taking the service
  traffic from Host1 to Host2 as an example, CPE1 is the SRv6 ingress
  node and CPE2 is the SRv6 egress node. 

Unless I’m missing something, extra configuration is needed so that SR source nodes (CPE in this case) can place “End-to-End SRv6 tunnels”. If my understanding is correct, then there will be a need of a mix set of mechanisms to provision the CPE. Is it justified from an operational standpoint to have several mechanisms here instead of using a common provisioning mechanism?

## Mobility Requirements

CURRENT:
      Moreover, the mobility requirements
      of CPEs are relatively high, and the access location of the same
      CPE often changes, so its IPv6 address cannot be fixed.

I fail to understand this.

I don’t see from where we have this “high” requirement for CPE mobility. At least, I don’t see how we can claim that as a general assumption, “access location” of CPEs “often changes”.

## BTW, I don’t see how the use of DHCP solves this issues, especially given the discussion in RFC7225 about “Additional States Considered Harmful”.

## Some of these issues can be fixed by having less words in Section 3.

# Multiple instances and RFC7227 Guidance

CURRENT:
  A client can explicitly request multiple SRv6 Locator prefixes by
  sending multiple IA_SRV6_LOCATOR options. 

and

  A DHCP message may contain multiple IA_SRV6_LOCATOR
  Options (though each must have a unique IAID).

and

  After receiving a DHCP message with multiple IA_SRV6_LOCATOR options
  at the same time, whether the server can assign multiple SRv6
  Locators to the client depends on the server policy, which is out of
  scope for this document. 

This seems to conflict with this RFC 7227 guidance:

  “If multiple instances are allowed, the document MUST explain how to use them.”

## BTW, other guidance from RFC 7227 seems not followed here such as: template for the defining the option (rfc7227#section-21), etc. Please check that guidance, if not done. Thanks

# "Automatic" behaviors are problematic

CURRENT:
  Upon receiving the Release message, the server MUST remove the lease
  and free the locator, making it available for allocation to other
  clients.

This MUST is problematic as it assumes that the message will always be valid and that there is no policy to discard the release.

There are other similar constructs in the document that I think need to be fixed.

[Ballot comment]
# General: please update all DHCP occurrences to DHCPv6.

# You may cite RFC 7084 for considerations related to PD support.

# Several of the considerations in RFC 8987 can be leveraged here are well

Specifically, I would mirror the following Operational ones from RFC 8987 (replace delegated prefix with locator):

  O-1:  The relay SHOULD implement an interface allowing the operator
        to view the active delegated prefixes.  This SHOULD provide
        information about the delegated lease and client details such
        as the client identifier, next-hop address, connected
        interface, and remaining lifetimes.

  O-2:  The relay SHOULD provide a method for the operator to clear
        active bindings for an individual lease, client, or all
        bindings on a port.

  O-3:  To facilitate troubleshooting of operational problems between
        the delegating relay and other elements, it is RECOMMENDED that
        a time synchronization protocol be used by the delegating
        relays and DHCP servers.

# Routing stability as an additional Operational Considerations

In some setups, an aggregate is announced instead of individual prefixes for the sake of optimized RIBs. Withdrawal of specific routes triggered by releases may have lead to shrink announcements. An alternative behavior is to have a policy that governs that behavior. In such cases, the delegating routers will drop packets sent to specific prefix not “delegated” on the customer-facing interface.

# Nits

## What is the purpose of the following?

CURRENT:
  Telecom providers can use their IP Metro and Backbone networks to
  establish connectivity between access users who are located in
  different regions.

Isn’t obvious that a network provider uses its network to provided intra-domain connectivity?

## Paradigm and “any program”

CURRENT:
  The network programming paradigm for SRv6 is specified in [RFC8986].
  It describes how any behavior can be bound to a SID and how any
  network program can be expressed as a combination of SIDs.  It also
  describes several well-known behaviors that can be bound to SRv6
  SIDs.

I suggest to simply state what that spec is about

NEW:
  [RFC8986] introduces the SRv6 Network Programming concept
  and specifies the base set of SRv6 behaviors.


Cheers,
Med

[Ballot comment]
This is outside my area of expertise.

This observation requires no response. Noting that these SR networks are trusted in one breath and then also noting that manual configuration is complex in the next breath is a bit interesting.  The larger the 'trusted network' is, the less trustworthy it becomes, no?

One nit:  Sections 4.1 and 4.2 have statements about IANA early assignments.  These need to be notated so that the Editor can more easily see that they are to be removed/modified.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-11. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the Option Codes registry in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry group located at:

https://www.iana.org/assignments/dhcpv6-parameters/

the temporary registrations for the following option codes will be made permanent and their references changed to [ RFC-to-be ]:

+=======+========================+========+===========+===============+
| Value | Description | Client | Singleton | Reference |
| | | ORO | Option | |
+=======+========================+========+===========+===============+
| 149 | OPTION_IA_SRV6_LOCATOR | NO | No | [ RFC-to-be ] |
+-------+------------------------+--------+-----------+---------------+
| 150 | OPTION_IALOCATOR | NO | No | [ RFC-to-be ] |
+-------+------------------------+--------+-----------+---------------+

Second, in the Status Codes registry in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry group located at:

https://www.iana.org/assignments/dhcpv6-parameters/

a new code will be registered as follows:

Code: [ TBD-at-Registration ]
Name: NoSRv6LocatorAvail
Status:
Reference: [ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
IANA

The following Last Call announcement was sent out (ends 2025-11-25):

From: The IESG
To: IETF-Announce
CC: aretana.ietf@gmail.com, buraglio@forwardingplane.net, draft-ietf-spring-dhc-distribute-srv6-locator-dhcp@ietf.org, james.n.guichard@futurewei.com, spring-chairs@ietf.org, spring@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Distribute SRv6 Locator by DHCP) to Proposed Standard


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'Distribute SRv6 Locator by
DHCP'
  as Proposed
  Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-11-25. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/6065/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was no real opposition to this document. It garnered several suggestions for clarification that were addressed. There was interaction by some WG members. There was not overwhelming debate or discussion.  Additionally, the dhc WG has been cc'd during the process of working through this document.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no notable controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No. There was no discontent or conflict within the discussion regarding this draft. 

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, There is a working implementation of this technology that has been productized in the H3C CR16000, CR19000 series routers.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There are technology overlaps with the dhc WG and potentially v6ops WG. The dhc WG has been involved during the process of working through this document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not Applicable

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not Applicable

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not Applicable
## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is well formatted, clear, and concise. It outlines a specific topic and addresses it in a manner that is easily consumable.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

There is a DHCPv6 option introduced which was discussed and all discussion points were addressed by the authors.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This document proposed a new mechanism for distribution of the SRv6 locator block. It introduces protocol changes (new DHCPv6 option) and techniques for use.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, Authors polled at time of adoption and again during WGLC.
https://mailarchive.ietf.org/arch/msg/spring/uVwqxBYn0Fsqz1qHiaVMr2_pZR4/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, there were conversations with authors during the time of adoption.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No notable NITs.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

15. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Not Applicable.

16. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

17. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

18. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

IANA has assigned values 149 and 150 option codes in reference to this document. There is a further request to assign a value for NoSRv6LocatorAvail which is requested in the IANA section of the draft. IANA registry is clearly identified. The references (both already assigned and requested) are reasonably named and identified.

20. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was no real opposition to this document. It garnered several suggestions for clarification that were addressed. There was interaction by some WG members. There was not overwhelming debate or discussion.  Additionally, the dhc WG has been cc'd during the process of working through this document.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no notable controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No. There was no discontent or conflict within the discussion regarding this draft. 

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, There is a working implementation of this technology that has been productized in the H3C CR16000, CR19000 series routers.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There are technology overlaps with the dhc WG and potentially v6ops WG. The dhc WG has been involved during the process of working through this document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not Applicable

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not Applicable

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not Applicable
## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is well formatted, clear, and concise. It outlines a specific topic and addresses it in a manner that is easily consumable.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

There is a DHCPv6 option introduced which was discussed and all discussion points were addressed by the authors.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This document proposed a new mechanism for distribution of the SRv6 locator block. It introduces protocol changes (new DHCPv6 option) and techniques for use.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, Authors polled at time of adoption.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, there were conversations with authors during the time of adoption.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No notable NITs.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

15. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Not Applicable.

16. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

17. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

18. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

IANA has assigned values 149 and 150 option codes in reference to this document. There is a further request to assign a value for NoSRv6LocatorAvail which is requested in the IANA section of the draft. IANA registry is clearly identified. The references (both already assigned and requested) are reasonably named and identified.

20. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There is a further request to assign a value for NoSRv6LocatorAvail which is requested in the IANA section of the draft.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was no real opposition to this document. It garnered several suggestions for clarification that were addressed. There was interaction by some WG members. There was not overwhelming debate or discussion.  Additionally, the dhc WG has been cc'd during the process of working through this document.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no notable controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No. There was no discontent or conflict within the discussion regarding this draft. 

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, There is a working implementation of this technology that has been productized in the H3C CR16000, CR19000 series routers.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There are technology overlaps with the dhc WG and potentially v6ops WG. The dhc WG has been involved during the process of working through this document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not Applicable

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not Applicable

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not Applicable
## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is well formatted, clear, and concise. It outlines a specific topic and addresses it in a manner that is easily consumable.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

There is a DHCPv6 option introduced which was discussed and all discussion points were addressed by the authors.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This document proposed a new mechanism for distribution of the SRv6 locator block. It introduces protocol changes (new DHCPv6 option) and techniques for use.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, Authors polled at time of adoption.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, there were conversations with authors during the time of adoption.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No notable NITs.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

15. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Not Applicable.

16. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

17. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

18. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

IANA has assigned values 149 and 150 option codes in reference to this document. There is a further request to assign a value for NoSRv6LocatorAvail which is requested in the IANA section of the draft. IANA registry is clearly identified. The references (both already assigned and requested) are reasonably named and identified.

20. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There is a further request to assign a value for NoSRv6LocatorAvail which is requested in the IANA section of the draft.

Dear WG (dhc WG in cc):

This message starts a two-week WG Last Call for draft-ietf-spring-dhc-distribute-srv6-locator-dhcp, ending on September/12. From the 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.

  https://datatracker.ietf.org/doc/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp/


Please review the draft and consider whether it is ready to move towards publication as an RFC. Please share any thoughts with the list to indicate support or opposition -- this is not a vote, and silence is not consent. 

If you are willing to provide an in-depth review, please go ahead.

The chairs are particularly interested in hearing from people who are not authors of the document.  The dhc WG has been cc'ed on this message and throughout the process.


Thanks!

Alvaro (for the spring-chairs)

Request for posting confirmation emailed to previous authors: Changwang Lin , Dan Voyer , Geng Zhang , Ruibo Han , Weiqiang Cheng , Yuanxiang Qiu , spring-chairs@ietf.org