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

On Thu, Jan 24, 2008 at 04:55:50AM -0800, Dino Farinacci wrote:
> >>But you can go get an ASN and not use it for BGP purpose but do use  
> >>it for GLOP addressing. Then you decouple yourself from your  
> >>upstream provider.
> >>
> >
> >I think that there is a big problem with this suggestion :
> >
> >Soon, 16 bit ASN will become unavailable. (January, 2009, the RIRs  
> >will only give them out by request,
> >January 2010, they will not distinguish between the 16 and 32 bit  
> >pools, which means in practice you
> >will get a 32 bit one.)
> >
> >There is no GLOP space for 32 bit ASN. We are working on a I-D to  
> >address this, but it is not there yet.
> 
> Use eGLOP ...

So where do I get my eGLOP allocation today?

eGLOP just seems complicated.  Lots of paperwork (initially and presumably 
recurrent), coordination between RIRs (or management by IANA), etc.

This proposal however is simple, comparatively 'elegant', minimises
paperwork, and allows a reasonable allocation size to an enterprise that
has a /16 for unicast.   

> ... and/or draft-ietf-mboned-ipv6-uni-based_mcast-04.txt.

We use that today, for IPv6.   Though in practice embedded-RP is more 
popular on more global scope IPv6 networks because the (now RFC) you 
mention only really works with one pre-configured RP (like in m6bone), 
whereas embedded RP allows any content provider to implictly define the 
RP for the group (usually but not always locally).   So we tend to use
embedded RP group addresses a lot at present, whether scoped locally 
or wider.  (Most of that currently is organisation scope IPv6 IPTV,
but we have services offered externally as well, and we expect external
services to grow as universities become more competitive in offering
material globally.)

Having said that, I appreciate multicast is many things to many people,
and demands and requirements will vary.   We're probably not typical.

> >(There are other problems, but this is a big one.)
> 
> I want to start solving the problems so there are no excuses. But my  
> interpretation of all this is that we have solved the problems so why  
> are there still obstacles.

We'd like to use SSM.   Vendor shortcomings currently make that somewhat
impractical, for IPv4 and IPv6, at least from the enterprise perspective
we're looking from :(   

Tim

_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www1.ietf.org/mailman/listinfo/mboned