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

["Dave Thaler" <[e-mail]>]

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