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

> First WRT Mark Fine's point on receipt of an IS_EX followed closely  
> by an IS_IN
>    -- Why didn't the host that wanted to join the group send a TO_EX
> 	(or an ALLOW if we are talking about sources)?
>    -- When the host left, why didn't the host sent a TO_IN?

the context of the example was to illustrate the need for TO_* messages
(which the initial huawei draft was proposing to eliminate) in order to
signal a state change to the router and cue a group-specific query in
order to expedite aging out the group record.  as you suggest, it's more
accurate to describe the example in terms of a TO_EX() followed by a
TO_IN(), as no host should be sending either a IS_EX or TO_EX unsolicited.



> Then what happens if you have two hosts, one sending IS_IN the other  
> sending
> IS_EX?  The router must query the subnet unless it is doing explicit  
> tracking.

IS_IN and IS_EX are solicited reports -- they are responses to a query the
router has already sent out on the subnet; hence one of the reasons why
query responding IS_IN and IS_EX reports do not begat more queries.



> Mark suggests the following:
> >>
> >> Router State   Report Rec'd  New Router State    Actions
> >> ------------   ------------  ----------------    -------
> >> EXCLUDE (X, )  IS_IN (A)     EXCLUDE (X+A, )     (A)=GMI
> 
> But, I thought the plan was to do away with EXCLUDE state
> for specific sources and with an empty list of sources to
> be BLOCKED, this state is equivalent to INCLUDE(A+).

apologies if my notation was not clear, but the above is equivalent to 

Router State       Report Rec'd  New Router State     Actions
------------       ------------  ----------------     -------
EXCLUDE (X, NULL)  IS_IN (A)     EXCLUDE (X+A, NULL)  (A)=GMI

using (A, B) notation described in 6.4.1 of 3376.  in other words,
before receiving IS_IN(A), the group record has a timer and a list of X
source records each having a timer; after receiving IS_IN(A), the group
record has an un-refreshed timer and a list of X+A source records each
having a timer, with the list of A source records having refreshed
timers, and the list of X-A source records having unrefreshed timers.



> FWIW: I don't see the need to differentiate between reports that are
> replies
> to queries and reports that are triggered from the host.  ie, TO_IN
> is the
> same as IS_IN as far as the router is concerned.  I do not see the
> advantages
> outlined in the IGMPv3 RFC Appendix A because you never know when you
> receive
> a IS_IN whether or not that information is already in the IGMP cache.
> 
> In other words, whether or not to send a query shouldn't be dictated
> by the
> hosts but by the router when it merges all the reports and records and
> doesn't know for sure which ones to add or delete.

IMHO, the concepts and operations outlined in section 6 of 3376 provide a
complete and thorough description of an abstract model of the protocol's
router half, clearly illustrating the rationales behind actions performed,
queries generated, state maintained, etc.  while neither section 6 nor
appendix A.1 offer in-depth explanations replete with examples or
scenarios, it should nonetheless be straightforward to realize the
negative impact of removing state-change messages in terms of accurately
reflecting the network's group memberships with minimal state.

it's also important to remember that section 6 of 3376 is describing an
abstract model of the protocol's router half, not a concrete software
implementation running on a vendor's routers.  by contrast, the discussion
around reducing complexity in the IGMPv3/MLDv2 protocols seems to be
overly influenced by implementation concerns that are potentially
obfuscating the original intentions and motivations of the protocols.

section 6 describes an abstract model of representing group membership
records and their sets of source records, along with operations and
actions for coherently managing these records and sets of records -- with
a stated goal of minimizing state while satisfying everyone's membership
requests.  in the context of an implementation that explicity tracks the
memberships of each host OR seeks to reduce operations in favor of
increased state (i.e., only removing source records when they age out),
potentially significant portions of section 6 are extraneous or 
unnecessary.  if an implementation is not maintaining aggregate group
membership state and is instead explicitly tracking each host's group
membership state, it may not be necessary to differentiate between IS_*
and TO_* messages.  OR, if an implementation is optimized towards SSM
environments it can favor "simpler" operations over minimal state by not
removing included source records on receipt of an ASM report.

on the other hand, there is clear motivation to provide reduced versions
of IGMPv3/MLDv2 that are still faithful subsets of the full protocols: 
(a) a "lite" version i've described in earlier emails WITHOUT excluded
source record lists; (b) draft-holbrook-idmr-igmpv3-ssm version WITH ONLY
included source record lists and no group timers.  more than addressing
implementation concerns, (a) and (b) are fully interoperable against the
full protocols while offering reduced group membership services: no
excluding sources in (a), and only including sources in (b).

in summary, where i see potential value in outlining and specifying
reduced subsets of the IGMPv3/MLDv2 protocols, i do not see the point of
documenting the particular strategies or protocol shortcuts of this or
that implementation.

mark