Subject: RE: mboned: RE: [magma] suggestion for simplifying IGMPV3/MLDV2 to discard EXCLUDEmode

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 8 Jun 2006 11:20:23 -0400

When operating with IGMPv3/MLDv2, is there no value in allowing for any
source multicast filtering behavior? Are we saying that whenever ASM is
needed, the host must revert to IGMPv1/IGMPv2/MLDv1?

I figured the EXCLUDE mode was useful if IGMPv3/MLDv2 was to be used in
an ASM situation, although I suppose that this isn't a big deal. Because
the version can be different for any given multicast group supported by
a multicast router.

Bert

> -----Original Message-----
> From: David McWalter [mailto:[email-masked]] 
> Sent: Thursday, June 08, 2006 7:29 AM
> To: Hui Liu; [email-masked]
> Cc: [email-masked]
> Subject: mboned: RE: [magma] suggestion for simplifying 
> IGMPV3/MLDV2 to discard EXCLUDEmode
> 
> Hi Hui.
> 
> Yes, I think that's already been agreed.
> 
> (See section 2.2.2 in 
> http://www.ietf.org/internet-drafts/draft-holbrook-idmr-igmpv3
-ssm-08.txt
> currently in RFC Ed queue).
> 
> 'An SSM-aware host SHOULD NOT send any of the following 
> record types for
> an SSM address.
> 
>     - MODE_IS_EXCLUDE as part of a Current-State Record
> 
>     - CHANGE_TO_EXCLUDE_MODE as part of a Filter-Mode-Change Record
> 
> This is a MODIFICATION to [IGMPv3,MLDv2], imposing a 
> restriction on its
> use for SSM destination addresses.  The rationale is that EXCLUDE mode
> does not apply to SSM addresses ... '
> 
> 
> I don't think you're proposing anything in addition to this?
> DMcW.
> 
> -----Original Message-----
> From: Hui Liu [mailto:[email-masked]]
> Sent: 08 June 2006 10:59
> To: [email-masked]
> Cc: [email-masked]
> Subject: [magma] suggestion for simplifying IGMPV3/MLDV2 to discard
> EXCLUDEmode
> 
> 
> Hello, all
> 
> I'd like to suggest here the simplification of IGMPv3/MLDv2;
> 
> In IGMPV3/MLDv2, protocol filter-mode is defined to support SSM. In
> practice, it seems EXCLUDE mode is not so useful, for there is little
> requirement for excluding specific sources. Further, EXCLUDE can not
> guarantee host not receiving unexpected traffic.
> 
> The realization of the EXCLUDE mode and corresponding 
> mode-switch operation
> are relatively complicated, especially when implementing 
> L2/L3 LAN switch
> with snooping. So it is suggested here to simplify 
> IGMPV3/MLD2 to eliminate
> the EXCLUDE mode. Then the process of router and host will be greatly
> simplified. And the important thing is: For SSM, INCLUDE mode 
> is enough to
> express join for specific sources.
> 
> Glad to hear your opinions
> 
> Regards,
> 
> Hui   Liu

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Stig Venaas <[email-masked]>
Date: Thu, 8 Jun 2006 21:44:27 +0200

> the version can be different for any given multicast group supported by

Right, we need exclude for ASM, but perhaps not the ability to block
sources. IGMPv3/MLDv2 could be simplified by just removing blocking
perhaps...

Stig

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

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 09 Jun 2006 10:39:04 +0900 (JST)

> But, as I said, I'm not necessarily seeing implementations follow  
> those rules.

IGMPv3/MLDv2 host-side implementations included in KAME support all
conditions (INCLUDE/EXCLUDE and all state tranditions) mentioned in
these specs.
I'm sure it is easy to support only INCLUDE mode, though.
--
Hitoshi Asaeda

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 8 Jun 2006 22:29:13 -0400

I think that the way to do this might be to
create a profile for "IGMPv3 lite" which does not do (S,G) excludes  
for ASM.

Clearly, as Dave Thaler said at the last IETF, anything that's done  
has to interoperate with
equipment that implement the full IGMPv3. I worry that if nothing is  
done here,
there will emerge a range of partial implementations, which may not  
all interoperate.

Regards
Marshall

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 09 Jun 2006 11:38:51 +0900 (JST)

> create a profile for "IGMPv3 lite" which does not do (S,G) excludes  

Maybe it might be my proposal sent to mboned ML on the 9th of Aug
2005.

> there will emerge a range of partial implementations, which may not  

Right. It may be possible if we carefully support the interoperation
between full version and Lite.
--
Hitoshi Asaeda

---

From: Stig Venaas <[email-masked]>
Date: Fri, 09 Jun 2006 08:11:09 +0100

> between full version and Lite.

Yes, it must be done carefully (if we decide to do so, I'm not really
arguing for change). I'm aware of one partial implementation causing
some problems already.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Fri, 09 Jun 2006 08:14:36 +0100

John Zwiebel wrote:
> Let's just leave the spec alone.
> Let implementers ignore the exclude for sources until someone
> figures out how to use it, then it won't have to be revisited.
> 
> FWIW: one can interpret the EXCLUDE to delete specific (S,G) entries.
> ie the opposite of INCLUDE, and since SSM doesn't deal with (*,G)
> entries...
> 
> And consider that it appears that each kernel is making different decisions
> on the type of message to send to join and leave the group, we might not
> want to mess around with this too much.
> 
> For example, Linux is sending out an "allow-new-sources" followed
> immediately by "change-to-include".

What Linux sends seems rather strange to me (I've looked into this
before). I feel it's not done the way it should be, but it seems it was
easier to implement it this way.

Stig

> 
> Windows XP, doesn't seem to support "block-old-sources" (although it
> could be
> the application I'm using).
> 
> NOW, it -could- be the test apps I'm using...
> 
> It is true that 3376 suggests that "MODE-IS-INCLUDE" is only sent in
> response to a IGMP query.  But is it also true that triggering a
> MODE-IS-INCLUDE
> will create the right state in the router.  (current-state-record)
> 
> It is also true that 3376 appendix A explains the need to differentiate
> 'current-state-records' from 'change-state-records'.
> 
> But, as I said, I'm not necessarily seeing implementations follow those
> rules.
> 
> 2cents

---

From: Hui Liu <[email-masked]>
Date: Fri, 09 Jun 2006 15:27:27 +0800

1  I agree with Stig that EXCLUDE mode is kept for ASM, to say precisely, be
kept for (*,G)join on the host side. 
That is expressed by EXCLUDE<NULL> in the IGMPv3.  And there is another
alternative to represent the (*.G)join as an 
extension for INCLUDE mode, i.g., INCLUDE<ALL>. Then it is possible that
EXCLUDE mode not supported by IGMP3 host. 
But for compatibility reason, EXCLUDE <NULL> is prefered.

2 On the router part, there is also a filter mode definition in igmpv3 to
optimize the state description within the router. 
Without the EXCLUDE (S, G) report, there is little need to maintain
router-filter-mode. The judgement is easier to take 
by the router and no complex mode-switching is required.
    
3  As Marshall mentioned, if lite version is a feasible choice, I agree that
new implemention should not introduce interoperation problem. 

Thanks
Hui Liu

> -----邮件原件-----
> 发件人: [email-masked] 
> [mailto:[email-masked]] 代表 Marshall Eubanks
> 发送时间: 2006年6月9日 10:29
> 收件人: Hitoshi Asaeda
> 抄送: [email-masked]; [email-masked]; [email-masked]
> 主题: Re: mboned: RE: [magma] suggestion for simplifying 
> I think that the way to do this might be to create a profile 
> for "IGMPv3 lite" which does not do (S,G) excludes for ASM.
> 
> Clearly, as Dave Thaler said at the last IETF, anything 
> that's done has to interoperate with equipment that implement 
> the full IGMPv3. I worry that if nothing is done here, there 
> will emerge a range of partial implementations, which may not 
> all interoperate.
> 
> Regards
> Marshall
>

---

From: Cao Wei <[email-masked]>
Date: Fri, 09 Jun 2006 16:21:16 +0800

> arguing for change). I'm aware of one partial implementation causing

Yes, if Lite version is considered, it should avoid introducing new problems. 

And as I know, it is much more complex for snooping to support IGMPv3/MLDv2.
 I have heard some complaint from LAN switch engineers.
I think Lite version can do some help.

Cao

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 9 Jun 2006 13:37:39 -0400

Just for the record, the Aug 9, 2005 message is attached below.

Regards
Marshall

> IGMPv2.1
> --------
> So maybe IGMPv2.1 might have made sense a few years ago but at this
> point, I'm not sure its a step in the right direction.
>

The SSM deployment problem is not due to IGMPv3's development delay.
Talking about the host-side implementation, my original igmpv3 code
was released to public more than three years ago, and KAME has been
supported to apply it for all *BSDs for more than two years. Linux and
Windows XP have already supported it. I heard Solaris too. I'm not
sure about MacOS, but from now on it would be trivial I guess.
Major router vendors have already supported the router-side
implementation. I thought implementation of the snooping function on
switch may be a bit delayed, but now the situation can be slightly
changed since as Tom said upgrades are available in many cases.

On the other hand -- this is the different discussion --, defining
SSM-only IGMP may be beneficial for some small equipment (e.g. PDA or
other mobile terminal).
In fact, in my implementation, the state change procedure between
INCLUDE mode and EXCLUDE mode are fairly complex and the relative code
size is not small. It would be tough work to sprit each function and
discard EXCLUDE mode from the current code; nevertheless, it may be
beneficial for such small equipment to support only INCLUDE mode
because the code size (and thus kernel itself) will be considerably
minimized (less than half, I guess) if we eliminate EXCLUDE mode from
the complete IGMPv3 implementation.

Again, defining IGMPv3-Lite/MLDv2-Lite (*), which only supports
INCLUDE mode, does not solve the current deployment problem. However
it may be able to increase the chance for new users to live with SSM.
(*) A new protocol naming with older version (i.e. IGMPv2.1) puts some
negative image to people who do not know our intention. It's not a
good idea to use older version number here. For me, IGMPv3-Lite/
MLDv2-Lite is much better to work for a positive approach.

--
Hitoshi Asaeda

---

From: mark fine <[email-masked]>
Date: Fri, 9 Jun 2006 14:15:37 -0700 (PDT)

i have not encountered undue difficulties with excluding sources in my
snooping implementation, but a "lite" version of the IGMPv3/MLDv2
protocols with no excluded sources seems possible by ignoring source lists
in the TO_EX() and IS_EX() messages, producing the following simplified
router state machine with no excluded sources:

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 would avoid excluding sources while maintaining interoperability with
"full" versions of the IGMPv3/MLDv2 protocols by adhering to a reduced
subset of their router state machine.

mark

---

From: Hui Liu <[email-masked]>
Date: Sat, 10 Jun 2006 11:07:55 +0800

Hi Mark,  

I agree with your comments, the reason is as follows:

The simplification introduces no changes on the message format 
of the group query and report.The member sends two kinds of report
to its connected router: INCLUDE mode report and EXCLUDE<NULL> report, 
which can be recognized by both the simplified and non-simplified protocols.

When a simplified router receives a EXCLUDE(S,G) report, it processes it 
just as the EXCLUDE<NULL> one. 

If  filter-mode on the router is not supported on the router part, the
operation 
just simplified the processing inside the router, not influencing the
outside 
behavior of the protocol. 

The interoperability method with lower versions (i.e. IGMPv1, IGMPv2, and
MLDv1) 
should be the same as that of the IGMPv3 and MLDv2. 

Regards,

Hui  Liu

Marlk wrote: 
> i have not encountered undue difficulties with excluding 
> sources in my snooping implementation, but a "lite" version 
> of the IGMPv3/MLDv2 protocols with no excluded sources seems 
> possible by ignoring source lists in the TO_EX() and IS_EX() 
> messages, producing the following simplified router state 
> machine with no excluded sources:
> 
> 
> this would avoid excluding sources while maintaining 
> interoperability with "full" versions of the IGMPv3/MLDv2 
> protocols by adhering to a reduced subset of their router 
> state machine.
> 
> mark
> 
> 
>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 10 Jun 2006 12:18:55 +0900 (JST)

Thanks for the report, John.

> When and application joins a new (S,G) one expects to see two  
> (robustness variable)
> (if the querier is configured for default) IGMP packets with
> at least one record.

Right.

> If one carefully reads the spec para 4.2.12
> it would appear that this record should be a CHANGE-TO-INCLUDE-MODE.

An initial interface state of each host is (m, INCLUDE, NULL).
When the host changes the state (m, INCLUDE, s1) (due to (m,s1) join),
it sends ALLOW(m,s1), not TO_IN(m,s1), because the host's initial
filter mode has been INCLUDE.

> After that, the host should respond to IGMP general queries with MODE- 
> IS-INCLUDE
> records.

Correct.

>  I would argue that one only uses ALLOW-NEW-SOURCES when  
> you've already
> sent a report to join a specific group.  (NOT that I really care that  
> much, but
> its the only way I can justify to myself the CHANGE-TO- modes).

ALLOW is used to notify or add interesting sources.

> When FreeBSD 5.4 sends the initial IGMP report for a new (S,G) it sends
> only one (1) packet with a single record which is ALLOW-NEW-SOURCES.

The message is correct, but it should send the message rob_ver times.

> FreeBSD 5.4 responds to IGMPv3 general query with one (1) packets with
> one record MODE-IS-INCLUDE

Same of above.
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 13 Jun 2006 16:50:42 +0900 (JST)

> Well, one could believe that there is no initial state.
> or there is "NULL" state.
> 
> I don't find anything in the RFC that claims there is any initial state.

Does the sentence in section 5.1 correspond to my thought?

   If no interface
   state existed for that multicast address before the change (i.e., the
   change consisted of creating a new per-interface record), or if no
   state exists after the change (i.e., the change consisted of deleting
   a per-interface record), then the "non-existent" state is considered
   to have a filter mode of INCLUDE and an empty source list.
--
Hitoshi Asaeda

---

From: Hui Liu <[email-masked]>
Date: Thu, 15 Jun 2006 15:32:59 +0800

Hi, all,

Thank you for previous dicussions of  the ideas. 

A draft "Simplifying Process for IGMPv3 and MLDv2 Protocols" has just been
prepared and submitted to the IETF database. This draft suggests the discard
of EXCLUDE(S,G) mode on the hosts and the filter-mode on the router. The
changes introduced to the original full IGMPv3/MLDv2 and appropriate
processing are described. Interoperation issues with full IGMPv3/MLDv2 and
IGMPv1/IGMPv2/MLDv1 are also discussed.

Any comments for this draft is welcome. If there are any incorrectness,
please feel free to indicate.

Thanks,

Hui  Liu

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 15 Jun 2006 06:03:41 -0400

Dear Hui Liu;

Thank you for this draft.

Will you be able to discuss this in Montreal ?

Regards
Marshall

On Jun 15, 2006, at 3:32 AM, Hui Liu wrote:

> <draft-liu-magma-igmpv3-mldv2-lite-00.txt>

---

From: Hui Liu <[email-masked]>
Date: Thu, 15 Jun 2006 18:58:18 +0800

Hi Marshall:

I'm not able to go to Montreal next month. But Wei Cao, another author of
this draft,
is going to attend this IETF meeting. He is planning to discuss this draft.
If it is 
possible, he'd like to give a presentation for 10 minites' time.

Thanks for consideration

Best Regards,

Hui Liu

> -----邮件原件-----
> 发件人: Marshall Eubanks [mailto:[email-masked]] 
> 发送时间: 2006年6月15日 18:04
> 收件人: Hui Liu
> 抄送: [email-masked]; [email-masked]; 'Stig Venaas'; 
> 'Hitoshi Asaeda'; [email-masked]

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 15 Jun 2006 07:33:24 -0400

Dear Hui Liu;

Thank you.

If MAGMA does not want to take on new drafts, it can be scheduled in  
Mboned.

Regards
Marshall

---

From: mark fine <[email-masked]>
Date: Thu, 15 Jun 2006 15:51:13 -0700 (PDT)

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)

  * 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:

mark

---

From: Hui Liu <[email-masked]>
Date: Mon, 19 Jun 2006 19:42:37 +0800

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:
> 

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. 

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.

> 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:
> 
> 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:
> 

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 ;
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.

Regards,

Hui Liu

---

From: mark fine <[email-masked]>
Date: Mon, 19 Jun 2006 11:41:16 -0700 (PDT)

see my comments in-line.

mark

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

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

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

> adding sources£¬ even though  there are no state changes. In lite version,

[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.

---

From: Hui Liu <[email-masked]>
Date: Mon, 26 Jun 2006 09:26:15 +0800

Hi all:

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.
2 Filter mode is not maintained in the router. Group timer identifies the
switching between ASM and SSM groups. 
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.

The state table is simplified as much as possible with the above rules
introduced.
  
Any comments are welcomed.

Thanks,

Hui liu

---

From: John Zwiebel <[email-masked]>
Date: Wed, 28 Jun 2006 17:39:22 -0700

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.

>> Router State   Report Rec'd  New Router State    Actions

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.

> 1 On the host side, TO_EX(x) is not needed and IS_EX(NULL) is used to

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

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

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

---

From: mark fine <[email-masked]>
Date: Thu, 29 Jun 2006 02:09:17 -0700 (PDT)

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

> IS_EX?  The router must query the subnet unless it is doing explicit  

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.

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

> 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

---

From: John Zwiebel <[email-masked]>
Date: Thu, 29 Jun 2006 09:30:06 -0700

Mark:

Your notation was clear.
I thought the desired outcome of this discussion was to
eliminate the need for EXCLUDE filter state on the router.
Am I mistaken here?

WRT the clarity of the IGMPv3 spec: not to me. ;-)
(Just a data point, not meant to be taken as an indictment
of the spec nor a confession of my ignorance, but I do thank
you for your patient elaboration of the goals and methods.)

Thanks
z

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 29 Jun 2006 12:43:08 -0400

> eliminate the need for EXCLUDE filter state on the router.

That was my understanding.

Regards
Marshall

---

From: mark fine <[email-masked]>
Date: Thu, 29 Jun 2006 10:26:29 -0700 (PDT)

> That was my understanding.

draft-holbrook-idmr-igmpv3-ssm completely eliminates the need for EXCLUDE
filter state (it does not allow IS_EX or TO_EX messages) at the expense of
not providing an ASM service.  i thought the desired outcome was to remove
excluded source lists while still allowing (*,G) joins, as well as 
included source lists.  eliminating excluded source lists significantly
reduces / neuters the EXCLUDE router filter mode to a concept that only
supports (*,G) state (as well as tracking requested included source
lists): whether it's called EXCLUDE filter mode or renamed to something
like ASM mode, it's effectively a group record with an active timer and
represents a (*,G) join.  this accomplishes the goal of providing both SSM
and ASM services within the interoperable context of the full IGMPv3/MLDv2
protocols, while dropping the ability to exclude source lists.

that's my understanding :)

mark

---

From: John Zwiebel <[email-masked]>
Date: Thu, 29 Jun 2006 10:38:23 -0700

On Jun 29, 2006, at 10:26 AM, mark fine wrote:

>  whether it's called EXCLUDE filter mode or renamed to something
> represents a (*,G) join.

OK, we're converging.  :-)

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 29 Jun 2006 13:39:15 -0400

Hello;

> that's my understanding :)

Yes. And one question is : Does anyone know of an application /  
service that actually
requires tracking exclude source lists ?

I thought once (around 2000-2001) that this could be used to squelch  
DOS attacks
on ASM groups, by excluding the rouge actor, but I think that both  
the usage and
the technology have evolved in different directions so I don't see  
removing that possibility as a real issue.

Regards
Marshall