Re: [dhcwg] Adoption Call for draft-fkhp-dhc-dhcpv6-pd-relay-requirements - Respond by Jan 14, 2020

[[e-mail]]

Hi Erik,

I’m just going through the outstanding points on this draft and it seems your comment got overlooked. My apologies.

There’s an change in the wording for G-5 (in response to a question from Bernie) that will be in the next update which might be relevant:

If a device has multiple interfaces that implement
a delegating relay function, the device SHOULD allow the same
client identifier (DUID) to have active delegated prefix leases on
more than one interface simultaneously, unless client DUID
uniqueness is necessary for the functioning or security of the
network.  This is to allow client devices with duplicate DUIDs to
function on separate broadcast domains. 


To clear up your question, we could add the following new routing requirement:

For devices with multiple interfaces implementing a delegating relay function:
If a Relay-reply message is received containing an instance of OPTION_IAPREFIX with 
a prefix that already has an active lease /route on one interface, but with an
interface identifier (e.g. the Link Address) that is for a different interface, 
then the relay should remove the existing lease / route and bind it to the 
new interface.

Does that cover it for you?

Thanks,
Ian

> On 15. Jan 2020, at 02:03, Erik Kline <[e-mail]> wrote:
> 
> I support adoption.
> 
> I am confused about some things though.  Specifically related to 3.4 and 4.1 G-5.  Should the delegating relay support a client moving from one interface to another (presumably this just means honoring a request with previously allocated IA_PDs in it, updating the routes accordingly)?  I guess, what's the guidance for supporting a duplicate versus detecting a migration?
> 
> [nits]
> S2.1: s/should be understand/should be understood/
> 
> S2.1: s/specificcally/specifically/
> 
> On Sun, Dec 29, 2019 at 8:03 AM Bernie Volz (volz) <[e-mail] <mailto:[e-mail]>> wrote:
> Hello:
> 
>  
> 
> As follow up from the IETF-106 DHC WG meeting, we are initiating the WG call for adoption on https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/ <https://datatracker.ietf..org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/> (DHCPv6 Prefix Delegating Relay). This document was presented at IETF-106 – seehttps://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00 <https://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00>.
> 
>  
> 
> This starts the call for Adoption of this document. Please respond by January 14, 2020.
> 
>  
> 
> Thanks in advance for your consideration of whether the WG should or should not adopt this document as a work item.
> 
>  
> 
> And, Happy New Year!
> 
>  
> 
> Tomek & Bernie
>  
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>