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

Some of this may be rambling, some of it I've said already, some
other folks have already said, so my point is:
   1) routers have to protect receivers by doing what the receiver  
meant, not
	what the receiver asked for.  Routers should merge all their received
	records and determine for themselves whether or not to send a query.
   2) Everyone knows what SSM is but everyone only thinks they know  
what ASM is
	because what I think it is doesn't match other definitions I've heard.
	(for example allowing a router to send an (S,G) join for a bidir source
	would not be a "good thing" yet some insist that bidir is a subset of
	ASM.)
   3) Deleting the EXCLUDE filter-mode on the router would be a "good  
thing"

 From here on, you might not want to read.  :-)
-----------------------------------------------------

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?

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.

IMHO depending on messages from hosts to tell you whether or not to  
send a query
is a mistake.

If the router is doing explicit tracking, there is no advantage to  
assigning
different outcomes on receipt of IS_IN vs TO_IN.  In the following, I am
suggesting that the TO_x and IS_x messages be treated the same way in  
IGMPv3-lite.

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+).

OTOH, how this is realized by by different implementations
is not important and IF it is determined that a full implementation
of IGMPv3 is inappropriate, AFAIC, the router state can be
IN or EX just as long as the same sources are forwarded.

On Jun 25, 2006, at 6:26 PM, Hui Liu wrote:

>
> According to the previous discussions on the list the draft is  
> updated to
> version01:
>
> The key points of the simplification operations are:
> 1 On the host side, TO_EX(x) is not needed and IS_EX(NULL) is used to
> represents an ASM join.

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.

As an example...
   (apologies to all who already understand this)

The difference between these two is only whether or not the Query is  
sent.
I can see that there may be some message savings, but I can't see  
that its
enough to make it worthwhile to differentiate between them.  Especially
since once the merge is processed there may not be any reason to send
the query.

INCLUDE (A)    TO_EX (B)    EXCLUDE (A*B,B-A)       (B-A)=0
                                                     Delete (A-B)
                                                     Send Q(G,A*B)
                                                     Group Timer=GMI
INCLUDE (A)    IS_EX (B)    EXCLUDE (A*B,B-A)       (B-A)=0
                                                      Delete (A-B)
                                                      Group Timer=GMI


> 2 Filter mode is not maintained in the router. Group timer  
> identifies the
> switching between ASM and SSM groups.

Isn't it true that the SSM group range is defined on the router and is
independent of what the host might think?

There is nothing to prevent the host from sending an IGMPv3 report for
an (S,G) when the router thinks the group is ASM.  There should be  
nothing
to prevent the router from establishing (S,G) state in that case.

However, if the router defines the group as Bidir and it receives a  
(S,G)
IGMP report, the router must drop that report.


> 3 When source timer expires, its source record should be deleted  
> without
> waiting for the  expiration of group timer. And do not remove  
> source records
> when IS_EX(NULL) is received.


FWIW: the hosts I've reviewed have all implemented the entire IGMPv3  
spec
although not exactly the same way.  Yet things still work "good enough".

In 3.1:
   If TO_EXCLUDE is going to be deleted then what is the use of  
TO_INCLUDE?
   specifically the state in 3.2:
         EXCLUDE (NULL)    INCLUDE (B)       TO_IN(B)

   should use IS_IN(B) instead since that is what is used to answer
   periodic reports.  It should be clear however that if an  
implementation
   uses TO_IN(B) that it isn't necessarily wrong.

In 4.1:
   I'm not sure that I like the introduction of ASM and SSM here.  I'd
   rather that -any- EXCLUDE be defined to mean INCLUDE(ALL) without
   expressly saying ASM or SSM.

   This is kind of complicated, but consider that the default SSM group
   range is 232.0.0.0/8.  Is it the purpose of this draft to say that
   if an EXCLUDE(232.1.1.1) is received that the router is suppose to
   join to the (*,G) for that group?  I hope not.

   Likewise, take an ASM group 224.1.1.1, obviously an EXCLUDE 
(224.1.1.1)
   will cause PIM to send a (*,G) join, but should an INCLUDE 
(1.1.1.1,224.1.1.1)
   cause a PIM (S,G) join be sent?  (I think so)  And if a (S,G) join  
is sent
   is 224.1.1.1 now an SSM group?  (I do not think so)

   ie, using SSM here expands the definition of what SSM is and may  
confuse things.



In 4.2:  doesn't the first rule obviate the second?  If not, why  
doesn't the second
    state that the group record should be deleted?

       G_Timer == 0   S_TIMER == 0          Suggest to stop forwarding
                                           traffic from source and
                                           remove source record. If
                                           there are no more source
                                           records for the group, delete
                                           group record.

       G_Timer == 0   No Source Elements    Suggest not to forward
                                           traffic from the source

In 4.3: Again, I'm concerned with the loose use of the term SSM.
    I think I can see a benefit derived from a change in
    exactly what it means to be an SSM range, but I don't think we  
want that
    to be defined in this document since it would be rather obscure.   
But
    if we go with what you seem to be suggesting, then it would seem  
to me
    that router configuration commands such as "ip multicast ssm- 
range" would
    become obsolete.  That's a good thing.

        sources to be forwarded by the router, while in ASM group  
(G_Timer >0)
        the source list remembers the sources to be forwarded after  
switching
        back to SSM mode.


In 4.4: IMHO maintaining the TO_IN  reports is going to severely limit
    the simplification of the protocol.  If these reports are handled  
in the
    same way that IS_IN/IS_EX then routers don't have to worry about  
complying
    with the triggered query.  If a host is expressly interested in  
BLOCKING
    a specific source, receipt of a BLOCK(B) report by the router  
explicitly
    causes the triggered query.  If the goal is to simplify things,  
letting
    unwanted sources timeout will be much easier.  (Like I said, an  
opinion).

    And since certain host implementations already send more records  
than are
    required (because it was easier).
    In other words TO_IN(A) can perhaps better be represented by a  
combination
    of BLOCK(B)/ALLOW(A) since (I believe) TO_IN is used to announce  
a change
    by the host from IS_EX.

    But there seem to be so many ways of interpreting what should be  
sent...
    (that is in the IGMPv3 RFC)

In 5.2:  I'd like to eliminate the TO_IN and make it, which I think  
would
    be handled the same way:

       TO_IN(x)                    IS_IN(x)


Bottom line:  I don't agree with the IGMPv3 RPC appendix A.1 which  
states:

        The inability to distinguish between the two types of reports  
would
        force a router to treat all Membership Reports as potential  
changes
        in state and could result in increased processing at the  
router as
        well as an increase in IGMP traffic on the network.

    I believe the router is going to have to treat all IS_IN messages as
    state changes now.  I'd appreciate someone explaining why that  
might not
    be so.