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

On Jan 24, 2008, at 8:43 AM, Tim Chown wrote:

> 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.
>

We expect to have an I-D out in this very shortly. Stay tuned...

Regards
Marshall

> 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

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