Subject: Re: imad: Re: mboned: brief IMAD BOF summary

From: Marshall Eubanks <[email-masked]>
Date: Tue, 9 Aug 2005 07:59:25 -0400

Dear Jeremy;

With SSM, you do not need MSDP. The ability to deploy interdomain 
multicast without
MSDP would be  a plus.

Regards
Marshall

On Aug 9, 2005, at 7:53 AM, Jeremy Hall wrote:

> Hello,
>
> please xpost to mboned your reply and include this text
>
> I was unable to participate in the discussions thus far, but I am
> assuming the reluctance is that ISPs won't deploy the necessary
> multicast goo in order to support pim-ssm.  Since you have to configure
> all the same crap for pim-ssm as you do for pim-sm, with the exception
> of an RP (big deal) I can see why people are hard-pressed to do it.
>
> IGMPV3 has been in linux for years, a nd I THINK it is in XP as
> well--but I might not be correct on that--so what are we waiting for to
> get IGMPV3 on the desktop?
>
> _J
>
>>>> Colin Perkins <[email-masked]> 8/9/2005 6:26:29 AM >>>
> Hi,
>
> On 9 Aug 2005, at 10:43, Leymann, Nicolai wrote:
>>>     Again, we were just brainstorming the problem, and this
>>>     arose as a possible way to deal with the lack of SSM
>>>     deployment.
>>>
>> I'm not quite sure if a "new" IGMP version is the right way to go
>> (even if it extends IGMPv2 only with a handful of features). From
>> my point of view IGMPv3 is a solutions which solves a lot of
> problems
>> we had with IGMPv2. For ISPs and content providers the combination
>> of IGMPv3 and PIM-SSM provides a platform for the deployment of
>> multicast
>> services (e.g. live streaming) and the protocols are also supported
>
>> by a
>> (growing) number of equipment vendors.
>>
>> I think we should push the deployment of SSM forward. An IGMPv2.1
> will
>> result in even less SSM/IGMPv3 depoyment because it's a step back
> from
>> IGMPv3 (SSM) towards IGMPv2 (SM) and therefore will slow down
>> IGMPv3/SSM.
>
> The suggestion was to make IGMPv2.1 a compatible subset of IGMPv3,
> implementing the minimum set of features needed to support SSM. I
> don't know how feasible that is -- it's been too many years since I
> read the spec in detail -- but an easy to implement subset might
> speed deployment.
>
> Colin
> _______________________________________________________________
> user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
> web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
>
>
>

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: "Jeremy Hall" <[email-masked]>
Date: Tue, 09 Aug 2005 07:53:01 -0400

Hello,

_J

Hi,

problems

will
from

Colin

---

From: "Jeremy Hall" <[email-masked]>
Date: Tue, 09 Aug 2005 08:43:32 -0400

uh right... :)

but you still need to get the BGP4++ and the mrouting core going.  That
is largely what people are excited about when they deploy a
multicast-specific train of code.  I don't know what the state of PIM is
in mainline--maybe it's better now--but the added overhead of the
multicast core makes people nervous.

I can tell you that were I to suggest we deploy multicast, I'd have to
have a business case for doing so, and right now I can't see one.

_J

>>> Marshall Eubanks <[email-masked]> 8/9/2005 7:59:25 AM >>>
Dear Jeremy;

Regards
Marshall