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

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