Subject: Re: mboned: routingarch-06bis: proposed text in Section 2.7.2

From: Pekka Savola <[email-masked]>
Date: Thu, 16 Nov 2006 09:12:58 +0200 (EET)

(Re-send with correct mailing list address)

On Wed, 8 Nov 2006, Thomas Morin wrote:
> Pekka Savola :
> >    Cisco's proprietary CGMP [CGMP] provides a solution where the routers
> >    notify the switches, but also allows the switches to snoop IGMP
> >    packets to enable faster notification of hosts no longer wishing to
> >    receive a group.  Fast leave behaviour does not work very well with  
> >    IGMPv3.  
> 
> Not sure if its of any relevance, but...
> 
> It looks to me like the last sentence "Fast leave behaviour does not
> work very well with IGMPV3" is not related to a protocol design limit,
> but more something just not implemented. Though not a CGMP expert, I
> don't see why CGMP procedures would make it impossible to have a fast
> leave feature implemented. Even further, it looks to me like explicit
> tracking, as made possible by v3, would allow for quick notification to
> the switches of the port that's just left group or channel.

Good point.  The text now has:

   Cisco's proprietary CGMP [CGMP] provides a solution where the routers
   notify the switches, but also allows the switches to snoop IGMP
   packets to enable faster notification of hosts no longer wishing to
   receive a group.  Fast leave behaviour support for IGMPv3 hasn't been
   implemented.  Due to IGMP report suppression in IGMPv1 and IGMPv2,
   multicast is still flooded to ports which were once members of a
   group as long as there is at least one receiver on the link.
   Flooding restrictions are done based on multicast MAC addresses.
   IPv6 is not supported.

> Then what indeed may not work well, is IGMPv3 source filtering if the
> switches only does L2 forwarding, but that's a point in common to all
> LAN flooding reduction techniques.  It might be nice to mention this at
> start of section 2.7 ?

Also a good point -- this was already touched on in the CGMP section, 
but should be more generic.  I added in section 2.7 the following:

   Some mechanisms operate with IP addresses, others with MAC addresses.
   If filtering is done based on MAC addresses, hosts may receive
   unnecessary multicast (filtered out in the IP layer) if more than one
   IP multicast group addresses maps into the same MAC address.
   Filtering based on IP addresses avoids this but requires more parsing
   of the frame payload.  Some IP filtering techniques also snoop source
   addresses in order to better support source-specific multicast.

Personally I like MAC based snooping better because it requires less 
intelligence in the snoopers, but if there are overlaps, it causes too 
much flooding.  But this was discussed on the list and others seemed 
to have different perspectives, so I tried to make the text neutral.

Unless I hear comments on this, I'll submit a revised draft next week.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Nov 2006 12:00:47 +0200 (EET)

On Thu, 16 Nov 2006, Pekka Savola wrote:
> [...]

I and Thomas worked on this off-list a bit, and this is now:

  Some mechanisms operate with IP addresses, others with MAC 
  addresses.  If filtering is done based on MAC addresses, hosts may 
  receive unnecessary multicast traffic (filtered out in the hosts' IP 
  layer) if more than one IP multicast group addresses maps into the 
  same MAC address, or if IGMPv3/MLDv2 source filters are used. 
  Filtering based on IP destination addresses, or destination and 
  sources addresses, will help avoid these but requires parsing of the 
  Ethernet frame payload.

Again, take a look if you care; I'll submit a revised draft next week 
unless I hear something.

---

From: mark fine <[email-masked]>
Date: Fri, 17 Nov 2006 09:57:52 -0800 (PST)

>> the switches of the port that's just left group or channel.

fast leave behaviour is suitably applicable to the IGMPv3 / MLDv2
protocols -- the behaviour is not dependent on explicit tracking and
can be realized through the router's aggregated group state.  further,
fast leave beahviour can be extended to encompass source records as
well as group records.
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/