Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast

["Eric Levy- Abegnoli (elevyabe)" <[e-mail]>]

Ole,

On 21/02/14 16:39, "Ole Troan" <[e-mail]> wrote:

>Eric,
>
>> DHCP won't work without changes which would be a lot bigger that
>>anything
>> envisioned for ND address registration.
>
>can you elaborate?

This is exactly what I did below :)
Adding link-local support in DHCP would require to change quite
substancially the flows to bootstrap the first address, when the host has
none yet.
Managing bindings requires to collect the information (as I said some bits
are missing today), maintain it, and serve it. That implies more changes.

>
>> DHCP does not maintain link-locals. That would be a major change to fix
>> that, including on hosts, since address requests are responded in
>>unicast.
>
>do we need to care about link-locals? are they part of the problem we
>need to solve?

Yes we do. They are about half the problem, an't they? More if most
traffic is local to the link. Less otherwise.

>
>> DHCP does not maintain <IP, MAC> binding. It does not have the MAC (not
>>to
>> confuse with DUID).
>
>true, but an onlink DHCP server or snooping relay could do an address
>discovery request to populate the ND table.

I will not claim it cannot be done with DHCP. With changes. Like it could
be done with 10 others protocols storing and distributing addresses.
It just sound more difficult to do it there rather than in the place &
module where you already manage bindings.
Eric
 
>
>> DHCP is not on the forwarding path where we need the information quickly
>
>what do you mean by that? if the function is on the first-hop router,
>then that's a deployment choice.
>ND register also needs to solve how to deal with multiple routers. I
>believe -05 proposes that the host maintains the state in all on-link
>routers, but that has quite a few implications too.
>
>cheers,
>Ole