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

"Dave Thaler" <dthaler@windows.microsoft.com> Wed, 04 August 2004 16:31 UTC

Received: from megatron.ietf.org (megatron.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16101; Wed, 4 Aug 2004 12:31:05 -0400 (EDT)
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOGT-0004ku-Q9; Wed, 04 Aug 2004 12:05:17 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs5mt-0005sG-Qz for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:21:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08934 for <dhcwg@ietf.org>; Tue, 3 Aug 2004 16:21:30 -0400 (EDT)
Received: from mail2.microsoft.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs5q1-0000gW-GI for dhcwg@ietf.org; Tue, 03 Aug 2004 16:24:47 -0400
Received: from mailout1.microsoft.com ([]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 3 Aug 2004 13:21:19 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 13:21:16 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 13:21:15 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 13:21:00 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Aug 2004 13:20:54 -0700
Message-ID: <C9588551DE135A41AA2626CB645309370A7033EB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments
thread-index: AcR33nZY3AAj1fryQ0q7L/pvAa0hpwBqpQUQ
From: "Dave Thaler" <dthaler@windows.microsoft.com>
To: <mboned@lists.uoregon.edu>, <dhcwg@ietf.org>
X-OriginalArrivalTime: 03 Aug 2004 20:21:00.0547 (UTC) FILETIME=[64729530:01C47997]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 04 Aug 2004 12:05:16 -0400
Subject: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

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 

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
	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
3) We have Unicast-Prefix-Based Multicast Addresses for IPv6.  This
again the need for server-based allocation, since techniques on a LAN
may be used instead (like random allocation, or perhaps something like
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. 


dhcwg mailing list