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

[Marshall Eubanks <[e-mail]>]

Dino;


On Jan 22, 2008, at 7:41 PM, Dino Farinacci wrote:

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

(There are other problems, but this is a big one.)

Marshall

>> 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.
>
> Right, so does GLOP if you just go apply for an ASN.
>
>>>> 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).
>
> How about this as a proposal to solve all your problems:
>
> 1) Go get an ASN and use GLOP group addresses.
> 2) Each GLOP group address maps to a (S,G) pair where G is the GLOP  
> address.
> 3) Put SSM translation on the last-hop routers directly connected  
> to all
>    potential receivers so when an IGMPv2 report comes to them with  
> a GLOP
>    address, the router does a (S,G) PIM join.
>
> So you run SSM in your site which extends to inter-domain SSM  
> usage. This code is most likely in your routers today. You can do  
> this with uni-based-mcast addresses as well.
>
> So any other issues? Can we now move forward? Can we document this  
> in the HowTo guide and move on?
>
> Dino
>
>
>
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mboned



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