Re: mboned: draft-liu-magma-igmpv3-mldv2-lite-00.txt

I don't think this would be compatible with the current RFC.
Certainly the Exclude(NULL) is inverse of the current implementation.
If we were to start from scratch, I'd support the simpler approach.

FWIW: I believe that most host operating systems (or is it the
OS with a majority of users?) have already implemented the current RFC.
Its in windows XP, Linux 2.6 and BSD flavors of Unix.

Therefore, IMHO the effort to make IGMPv3-lite is too late.

OTOH, if some one wanted to write an 'interpretation' of the igmpv3
RFC in 'plain english' that would be greatly appreciated.  :^)

And if someone wanted to write a BCP that said "routers don't know how
to exclude specific sources" and what that means, that would be a
"good thing".  (Perhaps it would be better to say current multicast
routing protocols don't know how to -easily-, in a scalable manner
exclude specific sources from the shared-tree.)

So, when a router receives an EXCLUDE with a list, perhaps it should
-always- interpret that as an EXCLUDE(NULL).  {FWIW: the implemenations
I've seen use BLOCK to remove specific sources.}

It "would be nice" if Stig could outline the problem he has seen with
a partial implementation.  I'd like to understand it.

Needless to say, the router has to protect itself.  And although
the IGMPv3 RFC states that IS_ reports are only sent in response to
queries, customers aren't going to be happy with router vendors who
don't process the IS_INC/IS_EX reports.

Routers are suppose to TRIGGER queries on the CHANGE_TO reports
which, IMHO, should have been left up to the router.  If his IGMP
cache doesn't change, why trigger a report?

WRT to "small" devices (like a phone), perhaps they need send only
"BLOCK" and "ALLOW" reports.  And perhaps on such networks there
would be no need for IS_ reports because there would be no query needed.
The link such a device is on would emulate a p2p link, and IGMP state
can be aggregated by whatever upstream device is there.


So with all this divergent BS... I guess the point I want to make
is:
   -- IGMPv3 is mostly available already on hosts
   -- The problem seems to be on the router with what to do with all the
	EXCLUDE type reports and timers.  (eliminating the need
	for an interface-filter-mode which someone suggested was a
	requirement of this new spec.)  Couldn't this best be handled
	by a BCP?


ONE LAST POINT:  (hmmm... I'll put this into a separate email, please
   don't respond on this thread.)
The v3-lite spec discusses ASM and SSM.  Like Dino, I think SSM is well
defined, but ASM is not.  But reading the spec, I need to ask how an
SSM group range is allocated.  We know that currently it defaults to
232/8, but that routers can configure locally it for any range.  Routers
specifically reject (*,G) IGMP host reports for groups in the SSM range.
AND routers -reject- (S,G) IGMP host reports for ASM groups.

The spec combines ASM and SSM in a way that suggests to me that at  
least some
of you would be "surprised" to see this.


On Jun 28, 2006, at 12:49 PM, Dino Farinacci wrote:

>
>     2) I think IGMPv3-Lite can be made much simpler and still serve  
> a useful
>        purpose. It's good that Change-to-* record types are not  
> recommended,
>        but I believe Allow-new-sources and Block-old-sources are  
> not needed
>        either. Why not just have:
>
>       o  Current-State-Include, where when the source count is non- 
> zero, it
>          is the host joining the various (Si,G), where each Si is  
> in the source
>          list. When the source count is zero, the host is joining  
> (*,G).
>
>       o  Current-State-Exclude, where when the source count is non- 
> zero, it
>          is the host leaving the various (Si,G), where each Si is  
> in the source
>          list. When the source count is zero, the host is leaving  
> (*,G).