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:42:36 -0800 (PST)

Hi, Everyone,

> configuration option that allows these variables to be set manually."

I think I'm in agreement with this, if I'm interpreting it correctly.

E.g., Not all snooping switches must have a timeout feature. However,
if they do AND if they also implement flooding of unregistered 
multicasts, then they MUST have a feature to override the timeout
behavior.

That sounds all right to me.

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:42:36 -0800 (PST)

Hi, Everyone,

Thanks,
	Karen