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

[Mark ZZZ Smith <[e-mail]>]

>________________________________
> From: Lorenzo Colitti <[e-mail]>
>To: Nick Hilliard <[e-mail]> 
>Cc: "[e-mail] WG" <[e-mail]> 
>Sent: Friday, 20 December 2013 3:25 AM
>Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
> 
>
>
>On Thu, Dec 19, 2013 at 11:46 PM, Nick Hilliard <[e-mail]> wrote:
>
>> But what you propose is not simple. In fact, far from it. What you propose
>>> requires a DHCPv6 server that's always up and perpetually maintains state,
>>> and it requires that you run VRRP between the routers because DHCPv6.
>>
>>Probably I'm not alone in considering dhcp servers to be critical to a
>>functional DHCP based network.  But as I said, I need DHCPv6 anyway and things will break if it's not available.
>>
>
>
>Fine, but please don't say it's simpler. It's not - it has way more moving parts.
> 
>> If you were designing a system from the ground up I'd wager you'd never
>>> design it like that. So why do it like that, then?
>>
>>Can we stick to technical discussion?
>>
>
>
>We can, but it won't get us anywhere. You've said that you want to run your network with DHCPv6 because RAs don't suit your requirements, and I'll say that I want to run my network with RAs because DHCPv6 doesn't suit my requirements. We will both have valid reasons, and probably we'll even concede that in each other's networks the other's solution might be better.
>
>
>But once we reach that point, we're still stuck. Because the only way forward from there is to conclude that we need to define two completely autonomous and competing systems to provision the same protocol on the same host implementations, and choose one or the other depending on the deployment scenario. This is a bad outcome, because hosts that want to work everywhere (and what host doesn't?) need to implement both protocols. The resulting complexity - which is more than 2x, because in addition to the two protocols you have to define and implement rules to deal with their interaction - pushes costs up for everyone, because everyone uses hosts, including me and you.
>

I agree with this. Removing RAs and replacing them with DHCPv6 from a network might appear to be reducing complexity, but it is only really shifting it and creating more. Host and router implementations become more complex because they'd be expected to support both; during a transition period both methods need to be enabled and supported; network design decisions become more complex because a choice will usually have to be made as to which method to support, perhaps involving a survey of host capabilities; and troubleshooting becomes more complex because there is a chance of disagreement when both RAs and DHCPv6 are run concurrently.

I'd also question the criteria of "one protocol" being a goal. If RAs are to be shifted into DHCPv6 to achieve this goal, why isn't ND and MLD also proposed to be moved into DHCPv6? If the problems are different enough, different protocols are created. If the problems are similar enough, they're solved with a single protocol.

I consider RAs to be solving the problem of link specific layer 3 configuration, and DHCPv6 to be solving the problem of layer 4 and more often higher application oriented configuration. A very good reason (perhaps the primary?) to create two protocols is so that one can be replaced without impacting the other (which is why I think DNS in RAs and IPv6 addressing in DHCPv6 are mistakes). If an alternate application configuration protocol is developed, DHCPv6 can be replaced without disrupting layer 3 configuration. 


>
>That's why I say this is a dead horse - because there *is* no single technically correct answer. The community has been through this exercise many times. People who want to put routing in DHCP and people who don't have had arguments in several working groups, each time with no conclusion, resulting in a waste of everyone's time. Let's not repeat that, because it isn't really in anybody's interest.
>
>
>Instead, what we can do is document the semantic differences and properties of the two protocols. After that, what we might be able to do is get consensus on criteria for what should go into RA and into DHCPv6 in the future. I think those are much mpre useful goals to pursue.
>

I put some text in my "DHCPv6 option transparency" draft which I think would be useful in pursuing that goal. I described why I think the network needs to be application configuration transparent, and therefore why a DHCPv6 client/server in the network model reduces transparency. Further layer 4+ parameters in RAs have the same problem.
 

"Internet Transparency and Application Configuration"
http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2


Regards,
Mark.