Subject: mboned: IGMPv3lite et.al: draft-liu-magma-igmpv3-mldv2-lite-02.txt

From: Toerless Eckert <[email-masked]>
Date: Fri, 24 Nov 2006 16:23:01 -0800

So, second mail on this subject:
>     ME: Who thinks this should be adopted by the mboned WG?
>     (Many hands)
>     ME: Those against adopting this? (No hands)
>     ME: We'll now take the question of adoption to the list.

    IGMPv3lite is a name used by a Cisco solution (just google it). That's
    why i definitely would not want the name to be reused for something else.

    I'd also like to remember, that we did mention this during IETF meetings:

      -> IGMPv3lite from Cisco is an implementation of a subset of IGMP
         running over UDP. The main reason was to allow applications on hosts
         to support SSM application even when the OS did not have an IGMPv3
         implementation.

         We specifically did not want to bring this into the IETF because we
         feared that emphasizing on this too much would cause even more delay
         in the adoption of full IGMPv3 in hosts and routers.
    
    The subset of course supported by IGMPv3lite is ONLY the SSM subset, eg:
    ONLY INCLUDE({S},G) - no EXCLUDE support at all !!!

    As far as the name is concerned: 

    -> I am happy to share the name IGMPv3lite with anything that ONLY supports
       SSM, but no ASM at all. I think it would make quite some sense too
       to describe that as two elements:

        a) Simplified state machinery of IGMPv3/MLDv2 
           - mandate explicit per-host tracking on router, allow only include mode
             reports. No leave queries at all, no report timers. Fast leave
             behavior, PIECE OF CAKE, REALLY SIMPLE, REALLY lite
             (except for the explicit tracking, this is what we've implemented
              in Cisco IGMPv3lite by the way).
        
        b) Transport:
           1. native
           2. encapsulated into UDP (for transition).
       
       And IGMPv3lite hosts with native transport would be perfectly
       backward compatible with full IGMPv3 routers, and IGMPv3lite routers
       with native transport of course also with IGMPv3 hosts that only
       run SSM applications.

   If you have any solution that is (like the current draft lio-mboned...) meant
   to also support ASM, then it would be lovely to NOT call this lite, because
   it is NOT lite. If this draft is going to stay, here are some ideas:

      IGMPv3-half-n-half
      IGMPv3-70%
      IGMPv3-no-sourcefilter
      IGMPv3-lazy
      IGMPv2.75
   
   ... and so on ;-))

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

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sun, 26 Nov 2006 18:16:12 +0900 (JST)

Regarding the naming issue,

>     why i definitely would not want the name to be reused for something else.
...snip...
>    it is NOT lite. If this draft is going to stay, here are some ideas:

Sounds interesting:), but in the next I-D, I'd like to propose;

    Lightweight IGMPv3 (LW-IGMPv3)
    Lightweight MLDv2 (LW-MLDv2)

It's straightforward, isn't it?

Regards,
--
Hitoshi Asaeda