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

[Erik Nordmark <[e-mail]>]

On 2/26/14 3:31 AM, Ole Troan wrote:
>
> there is work apparently on failover:
> RFC7031
> draft-ietf-dhc-dhcpv6-failover-design
Good to know.
>
> by moving the state into the network, maintaining that state on all first-hop router is going to be a challenge. that is the same problem, if you use DHCP or if you use ND.

The difference being that for ARO there is a draft which specifies all 
the details for how to do it.

With DHCP there is at best a requirements and design document. And those 
do not address state sharing between DHCP relay, which we need if we 
want a complete solution (re)using DHCP.

>
>>> with regards to your legacy point, with DHCP we can "declare" that there is no legacy. if you want to connect to networks like these, then DHCP is the only option for address assignment. just like there are networks deployed like that today.
>>>
>> I fear you are equating DHCPv6 as implemented by hosts today, and the extensions on the hosts necessary to use DHCP for address registrations. If you say that you will only support hosts that implement DHCP address registrations (for all addresses SLAAC - 4941, stable-privacy, microsoft privacy addresses, etc) then you will support no hosts at all on those links.
>>
>> That sounds like a non starter to me.
> you are quick to jump to conclusions. ;-)
Not conclusions - but assumed requirements that incremental deployment 
is critical otherwise protocols don't get deployed.

You said "declare that there is no legacy" which sounds like an approach 
where only green-field deployment makes sense.
That is a non-starter to me  and not worth while.
> I think we need to separate what _can_ be done within the protocol and how the protocol is deployed today.
There are definitely separable considerations around reuse - one is 
reusing existing protocols without extensions. Another is to avoid 
modifying existing implementations of said protocols. A third is not 
modifying existing deployment practices.
>
> in DHCP as deployed today, you get address assignment. what addresses are assigned to hosts is defined in the address assignment policy on the DHCP server. just like on any other network that uses DHCP for address assignment.
>
> is it really a requirement that hosts must generate addresses? if so why? what problem does that solve in this context?
Privacy. (which is why we did RFC 3041 and stable-privacy-addr).

But we've only concluded in this thread that there is no addition needed 
to the DHCP standard to register host generated addresses using IA_TA.

There is a host implementation issue AFAICT - at least in ISC DHC it is 
not possible to feed a host generated address into the DHC client - it 
can only request that the server to *create* and assign temporary 
addresses (by using the '-T' option). I don't have source access to 
other DHC client code to check.

But the hosts would presumably need to change for other reasons if we go 
the DHCP path. There is no need to multicast DAD probes in that case, 
and getting rid of those multicasts would be helpful.
>
>>
>> When the DHCP server or router crashes it typically starts clean, hence it doesn't know whether it lost state, or is a newly installed/configured node. Thus it wouldn't be "fall back" AFAICT, but actually a requirement to always start in normal ND behavior and then somehow move towards DHCP address registrations.
>>
>> You probably want to walk through all the details and write down the proposal - more efficient than me trying to guess and second guess how you think it might work and poke holes at my own guesses.
> right, maintaining this state is the crux of the problem. which is also the main reason why I'm skeptical about efficient ND.
There is an internet draft for that.

I'm waiting for the similarely detailed draft for how to do this with 
DHCP ;-)

More seriously, I have spent the last day sketching on how this can be 
done reusing DHCP but it seems like either we need to invent  of new 
protocol mechanisms here and there, or we end up restricting things 
severely. The restrictions seem to be:
     - no support for DHCP relays - MUST have a DHCP server on every link
     - no support for redundant DHCP servers (until some standard DHC 
failover protocol has been specified and implemented)
     - can only support unmodified host implementations that have DHCP 
on the links that enable "efficient-dhcp"
     - can not support temporary addresses in unmodified hosts

I think we at least need to do better in terms of legacy host support.

>> efficient-nd (that you like to call nd register) is robust against database inconsistencies - eventual consistency.
>>
>> If a new router appears and there are no use of multicast NS then the router needs to get the NCE database in any approach.
>> That could be using a yet-to-be-invented-and-standardized db sync protocol, vendor proprietary protocol, using unicast NS/NA between the routers, or involving the hosts as in ARO.
>>
>> In all of those cases the new router might be asked to forward packets before it has a complete db. Might result in packets being dropped on the floor, or fallback to multicast NS to the hosts.
> yes, it is the yet-to-be-invented that scares me.
I don't know if you intended that comment as a critizism of efficient-nd 
or a more general comment. Efficient-nd is fully specified and ready for 
review. Much of it has already been implemented and tested in the form 
of RFC 6775.

The DHCP state sharing is yet-to-be-invented.

>
>>> a fallback to normal ND is the only approach I can see off hand. for any solution we propose here.
>>>
>> I want to verify that I understand the context. Are you saying that any time there are two or more routers on the link we can not use the new scheme and can only use 4861? That doesn't make sense - we must aim higher.
> write it down.
Huh? The above refers to your proposal in email about reusing DHCP. 
Seems like you should write down how you intended it to work so we can 
stop the guesswork.

> might be my Scandinavian pessimism (which I assume you share), I'm not too hopeful on simple solutions here.
If I ever had such pessimism I must have left it behind a long time ago.
It is not the decision to move forward to solve an important problem 
which is the issue - it is to work out the technical details that takes 
work - need to ensure that the protocol is robust, incrementally 
deployable,  introducing minimal complexity, etc.
> if you can assume the routers are wired, then you could run a routing protocol to advertise the bindings between themselves. sounds like we have a bar bof, napkin, pen and beer required for this part of the discussion. ;-)
See above - the devil is in the details.

>> Explain how a host which uses RFC 4941 address does not need changes.
> it uses IA_TA. no change.
Correct - no change to the DHC options, nor server. But the DHC client 
code and behavior needs to change. Needs to detect a duplicate (which 
the client can only tell by comparing the IA_TA it got from the server 
with what it sent in the IA_TA.) We probably also want to clarify that a 
server should honor the suggested IA_TA addresses unless it is a duplicate.

   Erik