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.

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

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

-----Original Message-----
> From: Jerome Durand [mailto:[email-masked]]
> Sent: Wednesday, August 04, 2004 6:01 AM
> To: Dave Thaler
> Cc: [email-masked]; [email-masked]
> Subject: Re: mboned:
draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00
> comments
> 
> > 1) One of the things that both the API and the MADCAP protocol
provide
> > is
> > allocation of ranges (not "several", but a large number of
addresses,
> > like
> > a block of 400).  This requirement came from applications which want
a
> > larger range to use with things like
> > a) hashing resource ids into groups (I can't remember the specific
> > examples here, but IANA often gets requests for blocks of space, and
I
> > believe many of them are for this reason.  Dave Meyer can probably
> > correct me :),
> > b) assignment to areas inside virtual worlds (from customers in the
DIS
> > industry),
> 
> I don't beleive we really need this feature. A company that wants
plenty
> of addresses can be allocated manually for example a block. But can be
> added to the specs. (prefix delegation for IPv6 multicast address
could
> be the answer)

To be clear, this has nothing to do with company requests.
This was about _application_ requests from the server's address space.

-Dave

---

From: "Dave Thaler" <[email-masked]>
Date: Tue, 10 Aug 2004 09:09:29 -0700

Stig Venaas writes:
> > 2) Another thing that both the API and the MADCAP protocol provide
is
> > the ability to enumerate scopes (specifically, human readable names
for
> > them,
> 
> I'm not sure how important that is for IPv6, if the scoping is to
> strictly follow the scoping defined by the 4-bit scope field. Or do
> you want to allow for scopes defined in other ways? I can see some
> reasons for locally defined names though if the user is to choose
> which scope to use based on the names.

The general point is to get the names when you're multihomed to two
different networks.

-Dave