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

From: "Dave Thaler" <[email-masked]>
Date: Wed, 4 Aug 2004 10:39:09 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Aug 2004 10:55:24 -0700

On Aug 4, 2004, at 10:39 AM, Dave Thaler wrote:
> I'm asking the WGs whether
> there's real

Yup.   I'd really like to have any-source multicast, because it would 
require a narrower pipe than the one I have to buy right now to do VoIP 
broadcasts to Regular Folks [tm].   And I don't think I'm alone in 
this.   So there is customer demand at the bottom of the food chain.   
Unfortunately, I haven't seen any customer demand higher up the food 
chain than that.  And of course, times being what they are, I want 
IPv4, but otoh I'm hoping that multicast might grow up in the IPv6 
infrastructure, so my real hopes for some day having multicast rest on 
IPv6, not IPv4.   So a v6-only solution isn't what I want, but it is 
what I think I can get.

It's a complicated issue.   I think that if there are some researchers 
who want a DHCPv6 option to use to do some research and that they'd 
like to deploy, it's okay for them to advance a document that describes 
that option, as long as it really gets them some traction.   I think 
advancing a significant extension to the DHCP protocol probably isn't 
as good of an idea, given that MADCAP already does something similar.   
But the best really is the enemy of good enough, and I don't think we 
should completely poo-poo legitimate useful work that's being done just 
because there's a complex and wonderful alternative.

I guess my point is that I would support doing a DHCP option for this 
if the mboned working group wants it, but I think that your concern is 
legitimate in the case where we are talking about something more 
involved than a DHCP option.