Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments
Ted Lemon <mellon@nominum.com> Wed, 04 August 2004 17:41 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 NAA22204; Wed, 4 Aug 2004 13:41:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPf5-00056s-GP; Wed, 04 Aug 2004 13:34:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPWZ-0003F0-RH for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:26:00 -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 NAA20993 for <dhcwg@ietf.org>; Wed, 4 Aug 2004 13:25:58 -0400 (EDT)
Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPZs-00049h-PG for dhcwg@ietf.org; Wed, 04 Aug 2004 13:29:26 -0400
Received: from [66.93.162.248] (0127bhost247.starwoodbroadband.com [12.105.247.247]) by toccata.fugue.com (Postfix) with ESMTP id 73E491B2219; Wed, 4 Aug 2004 12:25:00 -0500 (CDT)
In-Reply-To: <C9588551DE135A41AA2626CB645309370A7033EB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
References: <C9588551DE135A41AA2626CB645309370A7033EB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <56D748BC-E63B-11D8-8860-000A95D9C74C@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon <mellon@nominum.com>
Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments
Date: Wed, 04 Aug 2004 10:25:54 -0700
To: Dave Thaler <dthaler@windows.microsoft.com>
X-Mailer: Apple Mail (2.618)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
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: 7bit
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. 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. The proposal on the table is simpler than MADCAP, not more complicated. 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. 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. 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
- [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv… Dave Thaler
- [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv… Dave Thaler
- [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv… Dave Thaler
- Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr… Ted Lemon
- RE: [dhcwg] RE: mboned: draft-jdurand-assign-addr… Dave Thaler
- Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr… Ted Lemon
- [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv… Dave Thaler
- [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv… Jerome Durand
- [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv… Jerome Durand
- Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr… Stig Venaas
- Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr… Stig Venaas
- RE: [dhcwg] RE: mboned: draft-jdurand-assign-addr… Dave Thaler
- Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr… Ted Lemon
- Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr… Stig Venaas