[dhcwg] Fwd: WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

[[e-mail]]

Hi Ted,

Many thanks for the review.  In addition to Naveen’s comments from 1/8, please see below.

Cheers,
Ian


> 
> In the introduction:
> 
>> Multi-hop relaying is also not considered as the functionality is solely required by a DHCP relay agent that is co-located with the first-hop router that the DHCPv6 client requesting the prefix is connected to
> 
> I didn’t actually see anything in this document that wouldn’t work for stacked relays.


[if - Rewritten to:

    Multi-hop DHCPv6 relaying is not affected, as the requirements
    in this document are solely applicable to the DHCP relay agent
    co-located with the first-hop router that the DHCPv6 client
    requesting the prefix is connected to, no changes to any
    subsequent relays in the path are needed.
]


> 
> 3.1, you introduce the concept here that the delegating router has a “lease”.  This is actually a new concept and should probably be explained. I assume that what’s meant here by “lease” is “route”. Routes can have preferred and valid lifetimes. Does it make sense to just use the term “route” rather than “lease?”  Is there information _other_ than routes bound to these leases?  It seems like you used the term “lease” in 4.1, but then switch to “prefixes and associated next-hops” in 4.2, but you probably mean the same thing in both cases, so defining the term here would help.

[if - In addition to the route for the delegated prefix, the relay also holds information about the client that it is delegated to (client-DUID, IAID) and timers for the delegation.

We use the term ‘lease entry’ in the text as it is a record of the relay relevant info contained in the prefix lease, not just a routing entry. What about the following:

old:
   For example, the delegating router already has an active PD lease
   entry for an existing client on a port.

new:
   For example, the delegating router already has an active PD lease
   entry bound to the client DUID of an existing client on a port.
]

> 
> G-1, you should word this in a way that doesn’t make the reader wonder if encapsulating the message is okay. Obviously that’s the intent, but it would be worth removing that doubt by saying so explicitly. Also, do you mean “delegating router” or “delegating relay?” It doesn’t make sense to me if you really meant “delegating router.”

[if - The above change to the wording for multi-hop relaying above should clear this up.

Delegating router should be delegating relay. Changed.]


> 
> G-6, is a /60 one prefix or sixteen?

[if - One.

Actually, this raised an interesting point about scalability of prefix routing entries in the relay if every shorter prefix is rendered into a set of component /64 (I have a vague memory of seeing this happen somewhere). What about adding an R-5 with:


The delegating relay’s routing entry MUST use the prefix length for the delegated prefix as given in the IA_PD.
]

> 
> G-8, why “at least 8” and not “at least 16” or “at least 4”? Are these /64s, or /56’s, or doesn’t matter?  I ask because one model for doing this would be to just allocate /64s piecemeal to clients that request them, and to layer delegating routers to make the routing work, rather than delegating a whole /56 or /48 to each customer.  Is that what you have in mind?

[if - Originally, the text just said that there should be a configurable limit without suggesting a value. Bernie’s review suggested that a default number should be given and we hit on 8 for want of a better value:

https://mailarchive.ietf.org/arch/msg/dhcwg/sk-IM5gSQPrIistauhD3defIMEo/

Also see comment above.]


> 
> S-1 doesn’t completely solve the problem: there is no required behavior. Do you mean that the relay MUST do one of the two proposed solutions, and MAY do both, or do you really intend to leave this as a potential gap?

[if - S-1 only gives a RECOMMENDED and then 2 possible solutions. RECOMMENDED was used here as some relay devices can be fairly simple wouldn’t be able to implement either of the options.

Suggest that RECOMMENDED in the S-1 text is changed to read:

"the relay SHOULD implement at least one of the following:”

and then remove the MAY/SHOULD from the proposed solution wording.]


> 
> S-3 why MAY and not SHOULD?

[OK]

> 
> O-2: how does this interact with active leasequery?

[if - It doesn’t, AFAICT. I haven’t actually seen a relay which implements active lease query, but the intention behind the requirement is to allow the operator to manually fix sync problems between the relay/server when they occur. Active leasequery may help reduce the occurrences of such problems, but doesn’t offer a mechanism whereby the removal of a lease binding entry on a relay could be used to signal to the server that the client’s lease is released.]

> 
> Thanks for working on this (authors)! Let me know if what I said doesn’t make sense. :)
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg