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

On Jan 22, 2008, at 10:39 AM, Dino Farinacci wrote:

>> On Tue, Jan 22, 2008 at 04:51:39AM -0800, Dino Farinacci wrote:
>>>> tjc@ecs.soton.ac.uk 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?

A decent proportion of the Multicast address assignment requests IANA  
gets is from organizations that have used
up their GLOP space.

Regards
Marshall

>
>> 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?
>
>> 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?
>
> Dino
>
>
> _______________________________________________
> 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