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

[Alexandru Petrescu <[e-mail]>]

Le 07/12/2013 20:56, Andrew Yourtchenko a écrit :
> 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.

I agree.  This is a good double point that deserves being mentioned.

Alex

>
>>
>>
>>> 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.
>>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>