Re: [mif] Use case 42 [Re: Use cases for draft-ietf-mif-dhcpv6-route-option needed]

[Brian E Carpenter <[e-mail]>]

On 2011-11-18 15:21, Ted Lemon wrote:
> On Nov 18, 2011, at 9:38 AM, "Brian E Carpenter" <[e-mail]> wrote:
>> Operators say that they want (approximate) feature parity so
>> that they can have (approximate) alignment between their
>> operational procedures for v4 and v6, especially in a dual stack
>> network. I assert that this is a very good engineering reason,
>> and it isn't for the IETF to get on its high horse and say that
>> experienced operators don't know how to manage OPEX.
> 
> This is the exact use case Tomek cited, and is (some of us think) adequately satisfied by a vendor-specific route option in the BBF and/or 3GPP vendor option spaces.   John was pretty sure that there was no demand for this from Cablelabs, although I'd certainly be interested in hearing other opinions on this question.

I didn't read it as the same, and in any case I fail to see how
a solution with some special features for CATV or ADSL or UMTS
can solve the general problem of distributing routing info to
hosts in an arbitary network, very possibly connected by none of
those specific technologies. In any case, three layers of subnet
down from the WAN connection, I hope there will be nothing that
is specific to the tye of WAN connection.

This is not a technology-specfic requirement.

> The question is whether there is some use case that justifies a general-purpose DHCPv6 option that would wind up being widely deployed and likely used *instead* of RA in some network to which arbitrary nodes might need to connect.

I don't know how to say it clearer: the use case is any IPv6
network, such as an enterprise network, whose operator *chooses*
to manage it using DHCPv6. It isn't for the IETF to decide for
these operators, and a technology-specific "vendor" option is
not going to solve the general purpose requirement.

>> I don't know whether my final comment belongs on this thread or
>> the drawbacks thread, but it's clear that a strong constraint on
>> any DHCPv6 option that overlaps in functionality with RA is that
>> it must convey exactly the same semantics or a proper superset
>> of the same semantics. If we do that, DHCPv6 will not undercut
>> RA and a special algorithm for RA vs DHCPv6 conflict resolution
>> will not be needed.
> 
> It's difficult to see how we could ensure that this was true, since the DHCPv6 server and router might actually be operated by independent entities with no coordination.

Sorry, I wasn't quite clear then. I mean semantics in the sense
that Dave Thaler raised - two different ways of conveying route
preferences is a Bad Thing. Obvious, in a situation such as a
homenet where you have uncoordinated sources of configuration,
their actual contents may be inconsistent, which is why you need
an overarching method of resolving inconsistency. But we need
that anyway, regardless of RA vs DHCP.

    Brian