Subject: RE: [magma] Snooping draft items 2.1.1.6 & 2.1.2.7

From: "Ben Carter" <[email-masked]>
Date: Mon, 2 Dec 2002 09:04:25 -0800

> -----Original Message-----
> From: Karen Kimball [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2002 2:57 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [magma] Snooping draft items 2.1.1.6 & 2.1.2.7
> 
> Hi, Everyone,
> 
> 
> Morten said:
> > I agree with both issues raised on the list. Changes will occur
> > in the  next revision. I am planning to include Toerless's and Ben's
> > suggestions without modification. Is everyone in agreement with
this?
> 
> Not entirely.
> 
> 
> First Ben's suggested textual changes:
> 
> "(6) The snooping switch MUST NOT rely exclusively on IGMP group leave
>      announcements to determine when entries should be removed from
the
>      forwarding table. The snooping switch MUST implement a membership
>      timeout feature to ensure unneeded forwarding table entries will
be
>      appropriately removed if downstream members silently leave the
group
>      or become unavailable for any reason."
> 
> 
> I disagree with the wording of "MUST" in the 3rd line. I think
"SHOULD"
> is more acceptable.
> 
> Remember that it is not required that snooping switches prune
> unregistered multicasts from the network. In those implementations
> which flood the unregistered multicasts, forcing a membership timeout
> feature will actually worsen the problem of multicast flooding.
> 

I see your point. If the switch is flooding unregistered packets in
order to service IGMP implementations that are 'invisible' to the
switch, _any_ timeout functionality will probably break the unregistered
flooding model. The switch may not recognize IGMP query responses from
future versions of IGMP, so it would timeout the groups. (Although in
practice, why anyone would actually want to deploy snooping switches
that flood unregistered groups still escapes me ;) )

I think tweaking the statement a little may fix this:

"(6) The snooping switch MUST NOT rely exclusively on IGMP group leave
announcements to determine when entries should be removed from the
forwarding table. The snooping switch SHOULD implement a membership
timeout feature to ensure unneeded forwarding table entries will be
appropriately removed if downstream members silently leave the group
or become unavailable for any reason, but MUST have a feature to 
override this timeout behavior, if implemented, for configurations that 
forward unregistered multicast packets on all ports. If timeout is 
implemented, a group's forwarding table entry SHOULD be removed from a
port 
when no IGMP report has been received for [(Query Interval x Number of 
Queries) + Query Response Time] seconds. These variables MAY be learned 
dynamically but IGMP snooping switches implementing timeout SHOULD have
a
configuration option that allows these variables to be set manually."

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

---

From: Karen Kimball <[email-masked]>
Date: Wed, 4 Dec 2002 14:55:06 -0800 (PST)

Hi, Everyone,

I've waded through Toerless' arguments, and I concur with his
basic points.

I can approve his language below, with edits for style & syntax. 
It would become,

7) When IGMPv3 "include source" and "exclude source" membership 
 	reports are received on shared segments, the switch needs to 
 	forward the superset of all received membership reports onto 
 	the shared segment. Forwarding of traffic from a particular 
 	source S to a group G MUST happen if at least one host on the 
 	shared segment reports an IGMPv3 membership of the type 

----- Forwarded message from Toerless Eckert -----

> b) The IGMP Snooping draft already states this in a short form in
>    2.1.2 5) but only mentions the drawbacks for ASM.
> 
> c) Today, if you build up an ASM network with IGMP Snooping you
>    typically escape the problems of the 32-fold overlap by just using
>    a particular subrange of IP multicast groups so that you never
>    get this overlap for your designated IP multicast traffic. Sure,
>    for te Internets IP multicast traffic at large you can not plan this,
>    but for your typical walled garden IP multicast environment you can,
>    and that's what deployments today rely on.
> 
> d) In the case of SSM, MAC based forwarding also only works well for
>    a walled garden environment where you ensure that each source
>    actually uses a unique group. But one of SSMs main benefit is actually
>    to much easier allow for merging of multi-provider content and in this
>    case you can not guarantee non-collision on the MAC address level,
>    i.e.: for SSM to fully deliver it's promise together with IGMP
>    Snooping, you really need per (S,G) based forwarding/filtering
>    in the IGMP Snooping switch.
> 
> e) There are already implementations to support d) (per (S,G) forwarding
>    in IGMP Snooping), but yes, this kind of function will for some
>    time be restricted to hardware which also could act as a hardware
>    L3 router because it's that type of hardware for filtering / forwarding
>    that you need to reuse.
> 
> So, in summary, it's not more or less a router function than anything
> else in IGMP Snooping, L3 based forwarding is already covered to
> an initial degree in the IGMP Snooping spec, but yes, L3 based filtering
> can not be required, it is optional, and the text i proposed does NOT
> require it. But it would certainly be helpfull to add text to carry
> the above listed information about the benefit of actually doing it.
----- End of forwarded message from Toerless Eckert -----

However, I'm unsure what the added text will clarify. The pain of 
doing (S,G) forwarding for some hardware? The inadequacy of L2 
forwarding for SSM? The inherent problems with L2 forwarding and the 
32-fold Mac-to-IP overlap? 
 
Toerless, do you have some specific text in mind?

Thanks,
	Karen
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*   Karen Kimball                     * 
*   Email: [email-masked]       *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Karen Kimball <[email-masked]>
Date: Wed, 4 Dec 2002 14:55:06 -0800 (PST)

Hi, Everyone,

----- End of forwarded message from Toerless Eckert -----

Thanks,
	Karen