Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

[Andrew Yourtchenko <[e-mail]>]

On Fri, 6 Dec 2013, Mark ZZZ Smith wrote:

[snip]

>
> So the objections I have are,
>
> - I don't see how anything in DHCPv6 makes it dramatically more 
>reliable than RAs, given that it too uses multicasts for DHCPv6 server 
>discovery. Adding RA functions into DHCPv6 is described or asserted to be 
>the panacea to all issues that RAs could suffer from, yet analysis shows 
>it isn't.

Adding RA functions to DHCP allows to get rid of RAs for the scenarios 
where you have to run DHCP, plain and simple.

>
> - I think it would be better to incrementally tune and optimise the 
>existing designed, standardised, code developed, code debugged and widely 
>deployed mechanism (RAs) to overcome corner cases, and/or to adopt past 
>developed methods such as IPv6 over NBMA, than to spend the next 5 to 10 
>years waiting for the design, standardisation, code development, code 
>debugging and widespread deployment of RA functions to be incorporated 
>into DHCPv6, and then also have to develop methods of conflict resolution 
>when RAs and DHCPv6 options disagree (because they will, unless you don't 
>plan to transition to DHCPv6 only until DHCPv6 RA functions are 
>ubiquitous. RAs and DHCPv6 RA functions will have to co-exist on a link 
>for many years if you can't demand or guarantee DHCPv6 RA functionality 
>from the host implementations.)

Conflict resolution is simple: fix your network. You are describing as a 
problem what isn't.

The http://xkcd.com/927/ is indeed a problem. But, this is a question of 
engineering, and using that as a blanket argument against DHCP-only 
operation is incorrect.

>
> - Using DHCPv6 for RA functionality won't eliminate one of the supposed 
>causes of RA unreliability - multicast unreliability. All of DHCPv6, 
>neighbor discovery and MLD would have to be made more robust against 
>multicast unreliability to truly solve that problem.

Gee, we are stuck on the strawman ureliability - there are *other* reasons 
why one would want to use DHCP, thus being forced to run multiple 
protocols.

>
> - I'm for a single method that works adequately. DHCPv6 with RA options 
>would probably qualify if we didn't already have a existing method. 
>Existing methods that work are always better than non-existent ones that 
>need to be developed, tested and ubiquitously deployed before they become 
>significantly useful and can be assumed to be available.
>
>
>> I think the large part of the tussle comes from the people wanting to 
>> make the functionality of the RA/DHCPv6 more symmetric and being told 
>> "no".
>> 
>
> The thing they need to demonstrate is that the costs of deploying a new 
>and second mechanism that is near functionally equivalent to the first is 
>worth the benefits. Given that the costs of developing and deploying RAs 
>has already been paid, I think the benefits of using DHCPv6 for RA 
>functions have to be very significant before the price should be paid. 
>The benefits of DHCPv6 for RA functions now needs to be compelling. I 
>don't think they are, otherwise I'd be quite happy to advocate for DHCPv6 
>for RA functions.

For some, the benefit would be significant. For some - it 
won't be any benefit at all.

>
>
>> And if we then tell them "Either use RA or no IPv6 for you" they say 
>
>> "fine, I choose no IPv6". And keep stacking on these NATs to support 
>> devices that "do not support IPv6" in that circumstances.
>> 
>
> I don't think RAs are the single reason some people are resisting 
>deploying IPv6 at all. I think some people are resisting deploying IPv6 
>because it needs to do one or both of two things for them - solve a 
>foreseeable problem that will effect them, or provide a tangible benefit. 
>If it won't do either of those things, then they don't currently see any 
>value from the effort involved. What are foreseeable problems or tangible 
>benefits is completely up to the perspective of the decision maker. 
>Eventually they'll see value in it, and deploy it. In some cases, some 
>people who could deploy IPv6 may never see any value in deploying it, so 
>they never will.

It's not binary. You can represent as a number both the amount of pain 
that a given problem (or set of problems) causes, and the amount of pain 
that the big change in the network like adding a new protocol causes.

As soon as the first number is smaller than the second one, nothing gets 
done.

Judging by the feedback I get from talking with people, even the 
possibility of eventually eliminating RAs from their network might make 
the second number smaller for a nontrivial amount folks, whose situation 
dictates the DHCPv6.

>
> There is no single answer to why people might resist deploying IPv6, no single solution, and things that motivate people to deploy or not IPv6 may have nothing to do with how IPv6 itself works.
>
>
>
>> I think in this discussion are again getting into the argument of "the 
>> best solution" instead of trying to collect the properties of the RA and 
>> DHCP.
>> 
>> My position is that single best solution does not exist, because 
>
>> everyone's problems are slightly different. So, rather than preaching for 
>> everyone to adopt the single solution which is the best in one scenario 
>> and suboptimal in the other, we should be engineering a way to be able to 
>> apply different solutions in different circumstances without the 
>> overhead of double work.
>> 
>
> A single solution that solves most cases is better than two different,

That's the point. The single solution that solves most cases, does not 
exist. For a good part of the cases, you need to apply two solutions at 
once. Justifiably, the question is "why", given in legacy IP they did not 
need to do that.

--a

>near functionally equivalent solutions that solve the same cases. 
>Multiple near-equivalent solutions create more code, more bugs and then 
>require conflict resolution mechanisms, creating even more code and more 
>bugs, with very little actual benefit.
>
> There are multiple ways of solving the neighbor discovery/router 
>discovery/host parameter configuration problem (read Radia Perlman's 
>"Interconnections" book as a starting point, and then perhaps "Inside 
>Appletalk", and also look into Novell's IPX and Network Directory 
>Services.). They all have different trade-offs, but fundamentally the 
>trade-offs aren't significantly different or compelling. Yet because 
>there are multiple methods to solve these problems, does that justify 
>implementing all of them because they each have some minor benefits over 
>the others, that different people might prefer?

>
> Regards,
> Mark.
>