Subject: RE: [magma] IGMP snooping draft, item 2.1.1.6

From: "Ben Carter" <[email-masked]>
Date: Tue, 26 Nov 2002 08:05:43 -0800

I apologize for the lack of line breaks in my previous post. !OOPS! 
Thanks for the feedback. My responses are below.

>-----Original Message-----
>From: Marshall Eubanks [mailto:[email-masked]] 
>Sent: Sunday, November 24, 2002 8:25 PM
>To: Ben Carter; [email-masked]
>Subject: Re: [magma] IGMP snooping draft, item 2.1.1.6

>On Thu, 21 Nov 2002 16:25:39 -0800
> "Ben Carter" <[email-masked]> wrote:
>> 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.? 

>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.

Exactly.

>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.
>>  
>> 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)

>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.

I must clarify my original statement. Not defining the timeout criteria
_in 
the snooping draft_ leaves room for incompatible implementations. (IMO) 

Allowing the network administrator to override the switches default
behavior with the 3 variables I mentioned should not unduly limit the
switch manufacturer's options for default timeout behavior. 

>Did you have some particular failure mode in mind ?

We are a layer 2 transport carrier providing Ethernet to the Home. Our
customers are service providers. These service providers, who provide
their own layer 3 routing, provide IP service to the end user. One of
the service 
providers is a video provider with hundreds of MPEG2 video channels of
4-6Mbps each. To accommodate this scale of multicast traffic and to
address 
other issues, this service provider has changed their router's IGMP 
settings. To ensure proper delivery of this service, tuning IGMP
snooping to 
match the service provider router's IGMP settings is critical. 

Even with control over the multicast router, having the ability to tune
IGMP 
snooping to match the router settings is essential to a robust and 
flexible IGMP snooping implementation. (IMO)

Thanks
Ben Carter
Network Analyst
Douglas County PUD
1151 Valley mall Parkway
East Wenatchee WA, 98802
Voice: (509) 884-7191
Fax:    (509) 884-0553

>                                                   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 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
>> 
>>  
>> 
>>  
>> 

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

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 26 Nov 2002 11:30:15 -0500

Hello Ben;

>>Subject: Re: [magma] IGMP snooping draft, item 2.1.1.6
<snip>
> 7

I would say that the snooping draft should adopt the defaults
in RFC3376 as its defaults. Anyone see a reason why not ?

> match the service provider router's IGMP settings is critical. 

Can you give me an idea what happens when the tuning is mismatched ?
Are you worried about the switches IGMP time out being much less than the
routers, so that state is frequently dropped to be restored ?

> flexible IGMP snooping implementation. (IMO)
<snip>

                                  Regards
                                  Marshall Eubanks

T.M. Eubanks

Test your network for multicast :
http://www.multicasttech.com/mt/
  Status of Multicast on the Web  :
  http://www.multicasttech.com/status/index.html

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 26 Nov 2002 11:30:15 -0500

Hello Ben;

<snip>

<snip>

                                  Regards
                                  Marshall Eubanks

T.M. Eubanks