Re: mboned: RE: [magma] suggestion for simplifying IGMPV3/MLDV2 to discard EXCLUDEmode

Just for the record, the Aug 9, 2005 message is attached below.

Regards
Marshall

On Jun 8, 2006, at 10:38 PM, Hitoshi Asaeda wrote:

>> I think that the way to do this might be to
>> create a profile for "IGMPv3 lite" which does not do (S,G) excludes
>> for ASM.
>
> Maybe it might be my proposal sent to mboned ML on the 9th of Aug
> 2005.
>
>> Clearly, as Dave Thaler said at the last IETF, anything that's done
>> has to interoperate with
>> equipment that implement the full IGMPv3. I worry that if nothing is
>> done here,
>> there will emerge a range of partial implementations, which may not
>> all interoperate.
>
> Right. It may be possible if we carefully support the interoperation
> between full version and Lite.
> --
> Hitoshi Asaeda
> _______________________________________________________________
> user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
> web archive:  http://darkwing.uoregon.edu/~llynch/mboned/


> IGMPv2.1
> --------
> So maybe IGMPv2.1 might have made sense a few years ago but at this
> point, I'm not sure its a step in the right direction.
>

The SSM deployment problem is not due to IGMPv3's development delay.
Talking about the host-side implementation, my original igmpv3 code
was released to public more than three years ago, and KAME has been
supported to apply it for all *BSDs for more than two years. Linux and
Windows XP have already supported it. I heard Solaris too. I'm not
sure about MacOS, but from now on it would be trivial I guess.
Major router vendors have already supported the router-side
implementation. I thought implementation of the snooping function on
switch may be a bit delayed, but now the situation can be slightly
changed since as Tom said upgrades are available in many cases.

On the other hand -- this is the different discussion --, defining
SSM-only IGMP may be beneficial for some small equipment (e.g. PDA or
other mobile terminal).
In fact, in my implementation, the state change procedure between
INCLUDE mode and EXCLUDE mode are fairly complex and the relative code
size is not small. It would be tough work to sprit each function and
discard EXCLUDE mode from the current code; nevertheless, it may be
beneficial for such small equipment to support only INCLUDE mode
because the code size (and thus kernel itself) will be considerably
minimized (less than half, I guess) if we eliminate EXCLUDE mode from
the complete IGMPv3 implementation.

Again, defining IGMPv3-Lite/MLDv2-Lite (*), which only supports
INCLUDE mode, does not solve the current deployment problem. However
it may be able to increase the chance for new users to live with SSM.
(*) A new protocol naming with older version (i.e. IGMPv2.1) puts some
negative image to people who do not know our intention. It's not a
good idea to use older version number here. For me, IGMPv3-Lite/
MLDv2-Lite is much better to work for a positive approach.

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