[dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments

["Dave Thaler" <[e-mail]>]

I'll put the larger meta issues in this message, and the specific
technical comments on the draft in a separate message. I pretty much
agree with Pekka's comments.

We have a proposed standard protocol (MADCAP) that does everything this
draft can, but is more complex.  The main question is whether there is
sufficient justification to create another slightly better way of doing
the same thing?

Two types of issues that are not relevant:
* Config issues, since MADCAP admin can be (and is)
integrated with DHCP, and the set of things to configure/administer
is unchanged in this proposal.
* Application API issues, since this is again the same between MADCAP
and this draft.

Complexity issues ARE relevant.  MADCAP was designed to be able to
share database-type code with a DHCP implementation, but 
parsing-type code is different.  This draft doesn't require 
parsing-type code to be different (other than a couple new 
options).

Let's first recall a bit of history to see where we're at today:

>From minutes of December 1998 IETF
(http://www.icir.org/malloc/minutes.98.12.html) there was a survey of
DHCP implementers, regarding MADCAP (formerly known as MDHCP):
	5 DHCP implementors responded. 

	Do you think that you might implement an MDHCP client or server?

	3 Yes, 1 will accept mods, 1 if there's demand 

	If you were to do so, would you attempt to share code with your
DHCP
	client or server? 
	3 Yes, 1 Maybe, 1 Little 

	Do you think that we should continue to maintain a similarity
	between MDHCP and DHCP? 
	3 Yes, 1 No Opinion, 1 Do The Right Thing

Now we have at least 2 implementations of MADCAP (Windows and Linux) for
IPv4, but no implementations of MADCAP that I'm aware of for IPv6 (yes
the RFC covers both).  However, although there have been deployments, we
have not seen lots of deployments of it.  If there were major blocking
issues specific to the protocol, one would think the current
implementers would be aware of them.  Instead, there is just lack of
customer demand.  

Next, what has changed in the world between 1998 and 2004?
1) We have SSM, and the majority of the application drivers of multicast
usage fit into that model.  This reduces the need for anything new in
this space, since both MADCAP and this draft are specific to ASM.
2) The expectation that interdomain multicast will become ubiquitous has
gone down somewhat.  Again this reduces the need for anything in this
space.
3) We have Unicast-Prefix-Based Multicast Addresses for IPv6.  This
reduces 
again the need for server-based allocation, since techniques on a LAN
may be used instead (like random allocation, or perhaps something like
ZMAAP).
4) Because multicast connectivity is not ubiquitous, application-layer
multicast solutions and infrastructures are now common.  This again
reduces the demand for IP multicast to cases with efficiency issues,
such as those with a huge number of receivers, which is often the same
class of applications wanting SSM.
5) MADCAP implementations are available.
6) DHCPv6 implementations are available.

Is there anything above that would suggest that creating another
solution  would be sufficient to generate more customer demand?  At the
moment, I'm not seeing it, even taking #6 into account, and so this is
the first question that needs to be answered before committing to invest
significant effort.  Are we just hoping that if the widget is painted
green instead of red, that people will buy it because green is a nicer
color and green means go?  Or is the color not that important because
it's still just a widget?  

Next question: do we expect ASM to be deployed in a given network
a) not at all
b) only for IPv6
c) for both IPv4 and IPv6
d) only for IPv4

If (a) or (d), then this draft is moot.  
If (b), then this draft is nice.
If (c), then there's one argument that the same solution should be used
for both IPv4 and IPv6 to provide consistency and ease of management
(admins don't have to learn two different things).  MADCAP was designed
for this, whereas DHCPv4 can't be used.  Hence this argues that MADCAP
is a better fit for (c).

Final high-level point: the draft states that DHCPv6 is expected to be
widely deployed, which I agree with.  However, the use of DHCPv6 for
address allocation will be less widely deployed.  In an environment
using stateless addr conf for address allocation, some of the reasons
why the DHCPv6 solution is desirable go away, since the mechanism will
be new to the admins regardless of whether one uses existing MADCAP or
new DHCPv6 stuff. 

-Dave


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg