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

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

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23406; Wed, 4 Aug 2004 13:52:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPsm-0007Pd-Dn; Wed, 04 Aug 2004 13:48:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPjz-0005qy-IR for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:39:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22155 for <dhcwg@ietf.org>; Wed, 4 Aug 2004 13:39:50 -0400 (EDT)
Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPnG-0004S5-Q9 for dhcwg@ietf.org; Wed, 04 Aug 2004 13:43:18 -0400
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 4 Aug 2004 10:39:26 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 10:39:13 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 10:39:13 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 4 Aug 2004 10:38:59 -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
Subject: RE: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments
Date: Wed, 4 Aug 2004 10:39:09 -0700
Message-ID: <C9588551DE135A41AA2626CB645309370A771A53@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments
thread-index: AcR6SBfZhgW4MGcfTVezxeInAQhuCgAAFRfA
From: "Dave Thaler" <dthaler@windows.microsoft.com>
To: "Ted Lemon" <mellon@nominum.com>
X-OriginalArrivalTime: 04 Aug 2004 17:38:59.0513 (UTC) FILETIME=[ECAC4290:01C47A49]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: quoted-printable
Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu
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

Ted Lemon writes:
> Dave, I think probably the overriding issue that's prevented there
from
> being more widespread implementation of MADCAP is that the internet
> routing infrastructure doesn't support multicast.   So there aren't
any
> customers.   So nobody comes banging on our door asking for MADCAP.
> So there's minimal implementation of MADCAP.

Right.  That's my point precisely.  The blocker is not really the
complexity of the protocol, that's a secondary issue.

> I would say that it was a chicken-and-egg problem except that I think
> that if there were routing infrastructure, people would do multicast
> even if there were no MADCAP.   So this isn't really an obstacle to
> implementation - it's something that would be nice to have if only
> there were a place to use it.

Right.

> The proposal on the table is simpler than MADCAP, not more
complicated.

We're in complete agreement here (for IPv6), I said the same thing in my
email.

>    It might be possible to implement even if there is low demand,
where
> MADCAP, which is a bit fancier, isn't going to get implemented unless
> there is high demand.   So the way I would frame this issue is, if we
> implement the proposal, does that prevent deployment of MADCAP later
> when there's enough demand to support widespread implementation of
> MADCAP.   I think the answer is no.  

Agree, although I think there's little reason to implement MADCAP for
IPv6 if you implement DHCPv6 for multicast.

> And does implementing this help
> people who are trying to solve the real problems in the multicast
world
> to make forward progress?  Apparently some think yes - I have no
> opinion since I'm not a multicast guy myself. 

This is the part I'm pushing on.  This proposal only solves a problem if
you have V6-only multicast (which is indeed the case in the research
network which motivated this proposal).  I'm asking the WGs whether
there's real
customer demand for any-source multicast, which was the issue at the top
of this email, as well as whether the demand would be for v6-only or for
v4/v6 both.  If folks want a v4 solution as well, they'll do MADCAP, in
which case
the incremental complexity of adding IPv6 support is negligible.

Just making a simpler solution that's IPv6-only doesn't necessarily mean
anyone will use it, and I believe we should only spend IETF cycles on
things that people will use.

-Dave

> Finally, is it likely
> that people could justify implementing this who can't yet justify
> implementing MADCAP?   TBF, I don't know.   It does look easier to me,
> but it still requires significant code changes.
> 
> Following this line of reasoning, I have to say that I'm tempted to
ask
> the authors to consider whether or not they can make this even
simpler.
>    Do we really need a new IA type, or can we do this with a regular
IA
> and an option?   The reason I ask is that picking which address
> allocation pool to use based on an option is well-understood
technology
> - I think probably every DHCP server vendor already knows how to do
> this.   And I don't think there are any particularly special
> constraints on how address allocation will be done for multicast
> addresses - you still just pick one out of a pool.   So I think you
can
> go cheaper on this, and maybe it would feel less like we were trying
to
> come up with another MADCAP, which doesn't seem like the right thing
to
> do.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg