Re: [MBONED] WGLC for <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>

[Tim Chown <[e-mail]>]

On Tue, Jan 22, 2008 at 07:39:19AM -0800, Dino Farinacci wrote:
> >On Tue, Jan 22, 2008 at 04:51:39AM -0800, Dino Farinacci wrote:
> >>>[e-mail] said:
> >>>>It's all very well to try to block this draft on a point of
> >>>>principle,
> >>>>but the reality is that there are issues deploying SSM today, and  
> >>>>in
> >>>>getting globally scoped group addresses for ASM.
> >>>
> >>>>I would in fact probably argue that in order to give multicast a  
> >>>>foot
> >>>>up in general, getting initial services running with ASM, until SSM
> >>>>is
> >>>>ready, could potentially be very useful.
> >>>
> >>>I've been quietly reading all the emails going
> >>>past on this issue.   I too can see the "point of principle",
> >>>but I, like Tim and others, really do think we need
> >>>something that will work in the short to medium
> >>>term for ASM.
> >>
> >>Can you two be a little more specific. Are you saying the network
> >>layer or multicast protocols need to do more (or less) and if so,  
> >>what
> >>do you think they need to do.
> >
> >I can't speak for Dave, but in my view its
> >
> >a) global scope group addresses for end sites to use.   This is  
> >problematic
> >  today for certain scenarios.   But obviously I can only speak with  
> >the
> >  knowledge of the community I'm in (from various BoFs etc we have  
> >had).
> 
> Why isn't GLOP address allocation sufficient?

In the scenario we're in (which may or may not be common in national
research and education networks) the provider (NREN) has an ASN but the
regional networks and end sites invariably do not.   So we can only get
a GLOP allocation from the NREN.   Between a few hundred universities
and thousands of colleges connected to that NREN, a GLOP block doesn't
go far, especially when the NREN itself may wish to 'reserve' addresses
for its own future use (quite reasonably).

In reality there's maybe 100 sites in that NREN's scope that have an
old style Class B allocation for whom the proposal would give up to 256
global scope group addresses.

But the proposal also allows the site to manage it's allocations.  It
doesn't have to go back to the NREN to acquire more, or to perhaps annually
justify what it has been allocated and what it's actually using.

> >b) tools to allow applications to determine available addresses within
> >  the site.   This arises from researchers and students writing (often
> >  but not always IPv6) multicast applications.    There's madcap  
> >but...
> 
> This draft solves that, no?

Sorry, what I meant was ways for applications to get a group address for
short or long term usage, if one isn't administratively allocated and
manually configured.    We're seeing some interest in this on the IPv6
side (e.g. for p2p file sharing applications).
 
> >I think the draft answers a) sufficently well for the short to medium
> >term (beyond which SSM will maybe get more uptake), while b) is a  
> >topic
> >I raised at IETF69(?) and on which I think there was a new draft  
> >posted
> >quite recently.
> 
> So when we get past this, there should be no issues? That is, will the  
> excuses for deploying  multicast go away?

Well no, but as Dave Price said address allocation issues are perhaps the
thorniest ones in writing HowTo's for our community.    My own view is
(as an enterprise person) the enterprise one.    

I agree that using SSM would be preferred, but we see practical issues today,
since as firewall and host OS support issues, that make that challenging
(both for IPv4 and IPv6 SSM).

I certainly appreciate the concerns over MSDP.   I would be interested to
hear more precise concerns on scalability issues, wrt number of peerings and
volumes of groups, but one could say that today in theory 10,000 ASNs are
out there and that could be a LOT of global scope groups.    While this 
proposal increases the potential number of groups in use, it's not clear
how much bigger the 'risk' gets.   

But yes SSM ought to be the end game :)

-- 
Tim


_______________________________________________
MBONED mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mboned