RE: mboned: RE: suggestion for simplifying IGMPV3/MLDV2 to discard EXCLUDEmode

see my comments in-line.

mark

On Mon, 19 Jun 2006, Hui Liu wrote:

> Hi Mark:
> 
> Thank you for comments on this draft. Many of your suggestions are valuable.
> 
> Please see the in-line discussions below.  
> 
> > the proposal should provide an interoperable subset of the 
> > full versions of IGMPv3/MLDv2, which i do not believe the 
> > draft does in failing to adhere to core elements of RFCs 
> > 3376/3810.  among other things:
> > 
> >   * abandoning the Filter-Mode-Change records, TO_IN and TO_EX,
> >     misinterprets the role of these records in signaling state change
> >     to the routers and the subsequent handling of state change in the
> >     routers, e.g., the generation of appropriate group and
> >     group-specific queries and the accompanying lowering of timers.
> > 
> >     consider this very simple example:
> >        - host joins group G, generating IS_EX() at 0s
> >        - host leaves group G, generating IS_IN() at 5s
> >        - since no query is generated by receipt of IS_IN(), 
> >          group record for G persists for GMI - 5s
> > 
> >     along these lines, the older version interoperability section of
> >     RFC 3376 maps IGMPv2 Leaves to TO_IN(), not IS_IN() -- 
> > and there is no
> >     such thing as a "v1 Leave".
> > 
> >     rather, i believe the proposal should specify the 
> > following "Action on
> >     Change of Interface State":
> > 
> > Old State      New State             State-Change Record Sent
> > ---------      ---------             ------------------------
> > 
> > INCLUDE (A)    INCLUDE (B)           ALLOW (B-A), BLOCK (A-B)
> > 
> > INCLUDE (A)    EXCLUDE ( )           TO_EX ( )
> > 
> > EXCLUDE ( )    INCLUDE (B)           TO_IN (B)
> > 
> 
> I agree that TO_IN(X) should be kept, as the above example explains. We
> previously consider resolving this by requiring the host sending IS_IN()
> before sending INCLUDE(B) (see 3.2 Editor's note). This IS_IN() will
> generate a group query. But it will cause extra message sending and make the
> process complex. So TO_IS() record should be preserved as you suggested. 

[mf] only the reception of "State-Change" records (TO_EX, TO_IN, ALLOW,
BLOCK) can result in query generation -- an IS_IN() cannot generate a 
group query, for the obvious reason of avoiding endlessly generating
queries in response to solicited reports.  and the only queries generated
in your draft appear to be from BLOCK messages.


> As to TO_EX(x) message, I think it is unnecessary in lite version. Since
> there are no need to block source list under EXCLUDE mode, the process of
> TO_EX() and IN_EX() are identical (please see the table you have listed). So
> TO_EX() record can be removed from host part for simplification.

[mf] by not considering exluded source lists, TO_EX() and IS_EX() messages
are indeeed equivalent in their actions generated; but i fail to see how
this significatnly simplifies the protocols on either the host or router
sides, and would question any such removal for non-essential savings.


> > 
> >   * one of the key points of the proposal should be to eliminate the
> >     excluded sources list; further removing the router's filter-mode
> >     or re-labeling the group's timer for ASM purposes is ultimately
> >     superfluous, constituting more of an implementation 
> > optimization than
> >     a protocol simplification.
> > 
> >     in considering the handling of group and source timer 
> > values, the only
> >     material consideration in the proposal should involve handling the
> >     expiration of source timers, which should always result 
> > in removing
> >     the source record regardless of the mode of the group or 
> > the value of
> >     the group timer.
> > 
> > 
> > from my understanding of the "full" versions of IGMPv3/MLDv2, 
> > i do not believe that a "lite" version of the protocols 
> > requires a lot of significant alterations, and is more 
> > adequately summarized by a couple of simple modifications to 
> > what's already been described in RFCs 3376/3810:
> > 
> >   * do not allow excluded sources in interface state
> >   * do not process source lists in IS_EX and TO_EX messages
> >   * remove source records when their respective timer expires
> > 
> > where other areas and alterations can be reduced safely to 
> > implementation concerns.  and again, here's a reposting of my 
> > earlier thoughts on what the proposal's router state should look like:
> > 
> > Router State   Report Rec'd  New Router State    Actions
> > ------------   ------------  ----------------    -------
> > 
> > INCLUDE (A)    IS_IN (B)     INCLUDE (A+B)       (B)=GMI
> > 
> > INCLUDE (A)    IS_EX ( )     EXCLUDE ( , )       Delete (A)
> >                                                  Group Timer=GMI
> > 
> > EXCLUDE (X, )  IS_IN (A)     EXCLUDE (X+A, )     (A)=GMI
> > 
> > EXCLUDE (X, )  IS_EX ( )     EXCLUDE ( , )       Delete (X)
> >                                                  Group Timer=GMI
> > 
> > INCLUDE (A)    ALLOW (B)     INCLUDE (A+B)       (B)=GMI
> > 
> > INCLUDE (A)    BLOCK (B)     INCLUDE (A)         Send Q(G,A*B)
> > 
> > INCLUDE (A)    TO_EX ( )     EXCLUDE ( , )       Delete (A)
> >                                                  Group Timer=GMI
> > 
> > INCLUDE (A)    TO_IN (B)     INCLUDE (A+B)       (B)=GMI
> >                                                  Send Q(G,A-B)
> > 
> > EXCLUDE (X, )  ALLOW (A)     EXCLUDE (X+A, )     (A)=GMI
> > 
> > EXCLUDE (X, )  BLOCK (A)     EXCLUDE (X+A, )     (A-X)=Group Timer
> >                                                  Send Q(G,A)
> > 
> > EXCLUDE (X, )  TO_EX ( )     EXCLUDE ( , )       Delete (X)
> >                                                  Group Timer=GMI
> > 
> > EXCLUDE (X, )  TO_IN (A)     EXCLUDE (X+A, )     (A)=GMI
> >                                                  Send Q(G,X-A)
> >                                                  Send Q(G)
> 
> This table is directly deduced from RFC 3376. Because there are no explicit
> excluded sources, the table can be simplified further and the process of
> source list should be specially considered.
> 
> 1  As earlier mentioned, TO_EX() and IS_EX() are identically processed in
> this table, so lines related to TO_EX() could be   removed, and TO_EX()
> message need not be defined for the host ;

[mf] as i mentioned earlier, i do not see a big advantage of removing the
aliased records at the expense of some clarity in the protocol, especially
when tracking state changes.


> 2. When receiving IS_EX(), Delete(A) action is not necessary. Consider the
> following scenario:
> 
> Router R has multiple hosts connected, such as  A,B and C.  A is in IS_EX(),
> B and C are in IS_IN(B) and IS_IN(C). When general queries are periodically
> sent, A,B,C will report their states separately. 
> A sends IS_EX(NULL), Router R deletes its source list;
> B sends IS_IN(B), Router R adds B into it's source list;
> C sends IS_IN(C), Router R adds C into it's souce list;
> 
> Thus in this case, router has to do unnecessary processing---deleting and
> adding sources£¬ even though  there are no state changes. In lite version,
> this can be avoided by not deleting source list when receiving IS_EX()
> reports.

[mf] the motivation behind the "Router Filter-Mode" is explicity stated in
6.2.1 of RFC 3376:

   To reduce internal state, IGMPv3 routers keep a filter-mode per group
   per attached network.  This filter-mode is used to condense the total
   desired reception state of a group to a minimum set such that all
   systems' memberships are satisfied.

the above outlined action to delete all included sources on reception of
IS_EX() and TO_EX() messages is a realiztion of the goal to maintain the
minimum necessary set to satisfy all systems' memberships.  once the
IS_EX() and TO_EX() messages are recevied, holding on to any included
sources is extraneous to satisfying all systems' memberships and can
be construed as a waste of the resources used to represent the included
sources.  you are suggesting an optimization / simplification based on the
assumption of a given scenario and the presence of certain conditions that
do not necessarily hold for all cases, thus favoring the particular case 
at the expense of general operations.  further, you are abandoning the
certainty of the original goal laid out in RFC 3376 of maintaining minimum
internal state in favor of reducing operations (adding and removing sources) 
that may or may not be necessary depending on the scenario.


> Regards,
> 
> Hui Liu
> 
>