Subject: [magma] IGMP snooping draft, item 2.1.1.6

From: "Ben Carter" <[email-masked]>
Date: Thu, 21 Nov 2002 16:25:39 -0800

The draft states:
 
(6) The snooping switch MUST NOT rely exclusively on IGMP announcements
to determine when entries should be removed from the forwarding table.
The reason for this is that changes in the local topology may cause the
snooping switch to fall off the path between the router and recipient
system.  As a result, the switch cannot be assured of seeing an
annou[n]cement message associated with the recipient leaving the group.
 
I read this as the switch should not rely solely on IGMP leaves, but
that there should be some timeout functionality in the event a group
participant silently becomes unavailable due to topology change, system
crash, power outage, IGMPv1 hosts etc.? 
 
If this is the case then it seems to me that more detail is needed for
the timeout process. To leave the timeout undefined leaves room for
incompatible implementations. At a minimum there are 3 variables (IMO)
that are necessary to properly tune IGMP snooping for a specific
application: Query Interval, Robustness (number of Queries) and Query
Response Time.
 
While dynamically learning the query interval is possible, and the Query
response time is contained in the IGMP query, dynamically learning the
routers robustness setting seems unworkable.
 
To make item 2.1.1.6 more clear:

"(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."
 
One possible timeout method to bring the snooping switch in line with
the IGMP router (to be appended to item 2.1.1.6):
 
"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 MUST have a configuration option
that allows these variables to be set manually." 

Ben Carter

Network Analyst

Douglas County PUD

1151 Valley mall Parkway

East Wenatchee WA, 98802

Voice: (509) 884-7191

Fax:    (509) 884-0553

---

From: "Marshall Eubanks" <[email-masked]>
Date: Sun, 24 Nov 2002 23:24:37 -0500

On Thu, 21 Nov 2002 16:25:39 -0800
> crash, power outage, IGMPv1 hosts etc.? 

All multicast state must be soft state - timing out if communication is lost
for any reason. This can happen for a lot more reasons than changes in
group topology.

In RFC3376 (RFC2236, for IGMP v2, has the same text) there is

8.4. Group Membership Interval

   The Group Membership Interval is the amount of time that must pass
   before a multicast router decides there are no more members of a
   group or a particular source on a network.

   This value MUST be ((the Robustness Variable) times (the Query
   Interval)) plus (one Query Response Interval).

The straightforward thing would be for a snooping switch (which in many ways is
acting as a router) to adopt the same time using the defaults. However, this
could be a number of minutes, depending on the value of the variables 
(4 minutes 20 seconds using the defaults). Multicast data would be kept flooding
across an unnecessary link for that duration if the topology changed
unfavorably. I can see why a switch manufacturer might want to shorten this
time, which amounts to shortening the robustness parameter.

> incompatible implementations. At a minimum there are 3 variables (IMO)

I do not see however why it is necessary to have the same time out value in
every snooping switch. If nothing happens, they will all time out in time.

Did you have some particular failure mode in mind ?

                                                   Regards
                                                   Marshall Eubanks

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624 Fax : 703-293-9609
e-mail : [email-masked]
http://www.multicasttech.com

> that allows these variables to be set manually." 

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

---

From: "Marshall Eubanks" <[email-masked]>
Date: Sun, 24 Nov 2002 23:24:37 -0500

Regards
                                                   Marshall Eubanks

T.M. Eubanks