Subject: mboned: Issues with draft-liu-magma-igmpv3-mldv2-lite-02.txt

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

Regarding the last mboned meeting in SD:

> Lightweight IGMP/MLD, draft-liu-magma-igmpv3-mldv2-lite-02.txt, Liu Hui
[...]
>     ME: Cisco have already use the term "IGMPv3-Light", does the
>     name of the current ID need to be changed?
[...]
>     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.

Unfortunately i could not be at the meeting, but to refine what i already
said an IETF meeting in before, and now via email to reach all group members:

  I am against adopting this draft as a WG item on grounds of the 
   following arguments:

   a) Not sufficient additional value 
   b) additional work
   c) unnecessary to standardize, contradiction in term
   d) taking away cycles from more important topics if any

   Let me go into a bit more detail here: First of all, i think there is
   not sufficient additional value, because supporting both EXCLUDE({},G)
   and INCLUDE({S,..},G) membership reports still leaves quite a complex
   state machinery.

   It does in fact create additional work, because now you are faced with
   the problem of interoperability testing in a larger matrix: IGMPv3 router
   and/or IGMPv3"lite" router and/or IGMPv3/IGMPv3"lite" host. 
   
   More fundamentally: 
   
    -> Are "lite" hosts and routers supposed to receive all IGMPv3 messages
      and answer them in an IGMPv3 compliant fashion ?

      The document is unfortunately not explicityl making a statement
      about this.

   But: If the answer is YES< then this IGMPv3"lite" is purely an
   implementation choice that does not change the external behavior -> 
   aka: no additional standardization required. If on the other hand the
   external behavior changes, then we got a bigger interoperability issue
   on our hand.

   The way i understand it, i guess (and if this document is to be maintained
   then it would be good to emphasize this better) the behavior is as
   follows:

     a) an IGMPv3"lite" host behaves exactly like an IGMPv3 host on the
        wire -> no standardization required for that, BUT: It does
        simply ignore any exclude filter list on the user API side.
     
     b) an IGMPv3"lite" router behaves also exactly like an IGMPv3 router,
        except that it also ignores EXCLUDE lists, which would impact
        potential PIM implementations and would of course make any
        IGMP-proxying router that acts like an IGMPv3"lite" router also
        as a IGMPv3"lite" only host on the upstream interface.

    The second best that could happen to this draft IMHO would be to rename it to
    something like the following and refocus:
    (the best thing of course being that this simply stays a vendor specific
     optimization).
    
       Title:
         Ignoring EXCLUDE lists
         Implementation simplifications for IGMPv3/MLDv2 host and routers
       
       Abstracts:
         When IGMPv3/MLDv2 hosts and routers ignore source lists as
         received in hosts from user APIs and in routers from hosts,
         the IGMPv3/MLDv2 state machinery implementation can be somewhat
         simplified. This draft explains how. It is informational only.
       
       Applicability:
         The methods explained in this draft are applicable as follows:

         a) To hosts that choose to only implement a subset of the
            MSF-API (eg: IP_ADD/DROP_MEMBERSHIP and IP_ADD/DROP_SOURCE_MEMBERSHIP)
         
         b) To PIM routers that use a mapping from IGMP/MLD memberships
            to PIM state in which EXCLUDE({S},G) state is ignored.
         
         The methods explained in this draft are specifically NOT applicable
         to IGMP/MLD proxy routers because when applied to such devices,
         the optimizations would result in a non-IGMPv3/MLDv2 compliant
         behavior on the uplink.

    Who by the way is in need to trying to save the few cycles of implementation
    work to make their IGMPv3 implementation half-baked ? Could we get a list
    of vendors for hosts/routers that would be interested in this ?

    It's not that i love the EXCLUDE({S},G) support, of course it's unnecessarily
    complex, but we knew when we wanted to have SSM, that the fastest way to
    get adoption was to continue to rely on IGMPv3, which by then (2000) was
    already some years in the making. And it's not because IGMPv3 is complex that
    some vendors still have not adopted it. It's just lazyness and what i call
    BCBS (Business Case Bu****it). I did ask over the years many
    vendors (host side specifically ;-), and it never came down to complexity,
    but just to whether or not IGMPv3/MLDv2 itself was mentioned often enough in
    RFPs by customers. And now we want to create even more RFCs that customers
    put randomnly onto their RFPs ????

    Of course it would be lovely to progress IGMP/MLD, but as we've seen in
    the past that's a 10 year timeline thing. For example, the whole INCLUDE
    vs. EXCLUDE report mode crap makes it completely impossible to implement
    good IGMP-proxy-routers that are not aware of whether or not a group-range
    is SSM and still maintains SSM behavior in the face of EXCLUDE reports
    (and that's totally independent of exclude source lists). Aka: One host
    joins to EXCLUDE({},G) and another one to INCLUDE({S},G). The IGMP proxying
    router doesn't want to know whether G is SSM only (consider this is a
    cheap home access gateway), so the only thing it can do on it's upstream
    is to send EXCLUDE({},G), thus killing the SSM host. Just consider those where
    two PCs in the home, maybe even running the same app, but one of them
    had only IGMPv2 on it. Stupid behavior like this.

    Aka: If we want to talk about state machinery changes, then i'd love to
    see just a simple model where any reporter can report group G membership
    AND channel (S1,G),... (Sn,G) AT THE SAME TIME. That would make all forms
    of proxy-routing and snooping and so on IMHO much more SSM safe and simple.
    And no, i haven't thought about whether or not this could be made compatible
    with IGMPv3, because in the end, i would love to see any further work
    really only be invested into SSM only solutions.
_______________________________________________________________
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:11:01 +0900 (JST)

>    external behavior changes, then we got a bigger interoperability issue

The answer for the host-side behavior is;
    (1) The lite host does not maintain EXCLUDE source address list
        and ignores a report/query message including EXCLUDE source
        address list.
    (2) The lite host deals with (*,G) join as an EXCLUDE filter-mode
        join with NULL source address list.

(1) is fundamental for the lite version host, and many could agree to
it. For (2), some would agree to this spec, and the others, who mainly
want to live with SSM-only network, may not. However, in fact, (*,G)
join is necessary for several service discovery protocols, e.g. SAP,
ND, SLP, mDNS, etc. We cannot hence simply remove a (*,G) join
operation from the host-side protocol.
If there is a way to categorize these service discovery protocols and
differenciate them by some manner, we may be able to allow to make a
(*,G) join operation only to them and stop making (*,G) join request
for regular *streaming applications*. But, anyhow, we cannot remove a
(*,G) join operation itself and the corresponding functions from the
host-side protocol.

For the router-side behavior, when a lite version router receives an
EXCLUDE filter-mode join with non-NULL source address list (i.e.
IS_EX(x) or TO_EX(x)), it deals with them as IS_EX(). By this manner,
the router does not need to maintain exclude source list as well.

>         simply ignore any exclude filter list on the user API side.

You had thought that an IGMPv3-Lite host only eliminated exclude
operation (because the corresponding APIs were eliminated)... Well, I
agree that implementing complete (and complex) MSF APIs is the most
tough work for the host-side protocol and eliminating some of them
contributes to the lightweight protocol at some level. On the other
hand, if we can further simplify the protocol/implementation by
additional manner, why we don't include/adopt it? I've been looking
for this additional manner in this lite specification, and thanks to
various inputs from the ML or discussions, several ideas could be
mentioned in the current draft. Of course, interoperability is the
most important thing for this protocol; hence if you find something
being inconsistency for keeping interoperability, I'm glad to know it.

>     of vendors for hosts/routers that would be interested in this ?

I already heard that some router/switch vendors are interested in
this specification, and they already started or planed the
implementation. As the host-side implementation, I plan to implement
the one (with open source license) and confirm the interoperability. I
also do hope popular OSes which have not supported the full version of
IGMPv3/MLDv2 yet would be able to choose the lite version then.

And again, if the full version is implemented on a router or host,
there is no need to re-investigate nor re-implement the lite version
spec or something at all. The lite version is mainly aims to faciliate
further SSM deployment, and to cooperate with vendors or developers
who have not yet completed or have hesitated the full igmpv3/mldv2
implementation because of its complex specification or some thoughts
(about exclude mode operation).

>     had only IGMPv2 on it. Stupid behavior like this.

Here, I think you are mentioning two issues, (1) unwilling condition
when (*,G) join and (S,G) join are invoked on a LAN, and (2) unwilling
condition caused by host compatibility mode.
Both are true, but neither of them relates to the lite version spec/
implementation itself. Both are caused in the current SSM.

For (1), it may not be perfectly fit the demand, one of my papers
focuses this problem and gives one tentative idea.
Hitoshi Asaeda and Walid Dabbous, "Multicast Routers Cooperating with
Channel Announcement System", Proc. of IEEE/IPSJ SAINT 2004, Jan. 2004.
If you are interested in, I'm happy to introduce it in a bit detail.

For (2), this should be also considered, while I mailed related
problem in magma ML. Please see;
http://www1.ietf.org/mail-archive/web/magma/current/msg00027.html

Yes, your concern is considerably reasonable, yet if we need to
address these issues, then we may need to start the discussion about
future multicast communication architecture, including *new* version
of IGMP and MLD. Maybe it should be our future work, not now, no?

>     of proxy-routing and snooping and so on IMHO much more SSM safe

Sounds interesting. But it's fulfilled by neither of the full nor
the lite protocol as you mentioned next.

>     really only be invested into SSM only solutions.

I also love to see SSM only solutions. And I believe the
igmpv3/mldv2-lite could contribute to them, while it is possible (and
necessary) to invoke (*,G) join at the protocol level.

IMO, we should decide that (*,G) join could be used only for discovery
protocols and all streaming applications must use an address in an SSM
address range at the service level. As the result, we can live with
SSM only network. This is another issue, but if we operate with such
rule, really the lite solution would contribute to our wish.

Regards,
--
Hitoshi Asaeda