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

[Dino Farinacci <[e-mail]>]

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

You either get complicated with paperwork or with protocol mechanism.  
We don't need the later or else we go with MASC, MADCAP, or other.

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

Sure, so go with it. My point is there shouldn't be anymore obstacles.

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

Sure, but if you ever want to use Bidir with embedded-RP groups, there  
are going to be major issues. Sender-only branches just don't work  
well, that is, will cause a lot of packet loss.

> 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 :(

It would be good to identify them so vendors have specific data to go  
resolve the issues.

Dino

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



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