RTG Dir review in Working Group Last Call

Reviewer: Adrian Farrel
Review result: Has issues

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir

This is an "early review" coinciding with working group last call. It
would be helpful if you could consider them along with any other working
group last call comments that you receive, and strive to resolve them
through discussion or by updating the draft.

Cheers,
Adrian

Document: draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-09
Reviewer: Adrian Farrel
Review Date: 2025-09-07
Intended Status: Standards Track

= Summary:

This document is easy enough to understand, and the protocol elements
seem well defined, with error cases called out. I believe interoperable
implementation would not be hard.

However, there is one major issue of clarity (which is hopefully easy to
resolve) and a number of minor issues/nits that would be nice to fix.

= General:

I trust this document has been reviewed by the DHC WG. If not, it would
be worth sending them a heads-up.

---

It seems to me that there is more background information than is needed.
It is not necessary to explain how SRv6 works, because that is already 
covered in other documents. If you have time to edit down the 
Introduction, that would be nice - but it is not a critical issue.

= Major:

I think that the Introduction describes a problem, but then proposes
DHCP to address a different problem.

The problem you seem to describe is:
   A CPE that does not run an IGP cannot distribute or receive SRv6
   locators.

The solution provided seems to address the following problem:
   An SRv6 Segment Endpoint Node needs to determine its own SRv6
   locator through some form of distribution or configuration.

This is compounded by section 3 which basically says:
   - SR configuration at he CPE can be complex
   - Discovery by the BRAS of routes to CPEs cannot always be achieved
     using an IGP.

The problem description in Section 3 seems much more accurate. Perhaps
you can reflect it in the text in the Introduction.

That said, I think that the material in Sections 4 and 5 only addresses
the first of the two problems described in Section 3.

Further, Figure 4 includes "Distribute Locator Route" but there is no
description of this.

Perhaps there is an assumption that the BRAS is the DHCP server or relay
so that the routes are automagically learned, but there seems to be no
statement of this, and so no consideration of what happens if the BRAS
is just passing DHCP packets through unexamined.

There is just a single sentence in 5.3 about routes and BRAS acting as
DHCP server:
   If the BRAS
   device acts as a DHCPv6 server, the server also MUST delete the
   corresponding SRv6 locator route locally.
While 5.4 has two sentences about the DHCP relay (without reference to
the BRAS):
   The first
   DHCPv6 relay agent needs to record the SRv6 locator assigned by the
   DHCPv6 server, including SRv6 locator information, lifetime, etc. and
   generates SRv6 locator route locally.

   After receiving the DHCPv6 Release or Decline messages from the
   client, or the valid lifetime of SRv6 Locator prefix expires, the
   DHCPv6 relay agent MUST delete the SRv6 locator route locally.

= Minor:

You should review the text to check that all uses of lower case "must",
"should", and "may" are really intended to be lower case and not use
BCP 14 upper case.

---

Section 6

Thanks for including this. It is helpful.
It would be nice to clarify whether the implementations are client, 
relay, or server.

=  Nits:

4.2 has "IA SRv6 Locator Option" but 4.1 names the field as
"IA_SRV6_LOCATOR-Options"

And you need to decide between:
- IA SRv6 Locator option
- IA SRv6 Locator-option
- IA SRv6 Locator Option

This is particularly sensitive in the context of:
   More than one IA SRv6 Locator option can appear in a single
   IA_SRV6_LOCATOR option.