Subject: [magma] Snooping draft items 2.1.1.6 & 2.1.2.7

From: "Morten Jagd Christensen (MJC)" <[email-masked]>
Date: Wed, 27 Nov 2002 09:24:13 +0100

Hi All

Thanks for the input to the draft - it is encouraging to know 
that people are actually reading it!

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?

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

---

From: Karen Kimball <[email-masked]>
Date: Wed, 27 Nov 2002 14:57:03 -0800 (PST)

Hi, Everyone,

Morten said:  
> 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 believe from Ben's earlier comments on the last draft that he would
not desire that result either.

Ben's other suggested text, to be appended to item 2.1.1.6, was

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

Again, I believe the word "MUST" in the 4th line is too strong, and 
that this should be "SHOULD" instead. 

Some IGMP implementers only allow the configuration of IGMP on|off, 
and the suggested level of configuration detail is a far cry from those 
basic implementations.

---------------------------

Onto Toerless' suggested text for 2.1.2(7):
 
     7) In the face of IGMPv3 "include source" and "exclude source"
	memberships reports 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 INCLUDE(G, Slist1) or
	EXCLUDE(G, Slist2) where S is element of Slist1 and not element
	of Slist2.

I agree that the draft's text should be changed, and have to take
primary responsibility for the section Torless addresses.

However, the last sentence of the suggested text strongly implies
that the snooping switch's role is to NOT forward when S is an element
of Slist2.

The ability to selectively SUPPRESS a given data stream based on Layer 
3 information (i.e., forward except from IP source X.X.X.X) is a router 
function.  

I believe we should avoid any wording that requires the snooping switch
to effectively become a router. Or in other words, any wording that
prevents a snooping switch from supporting any degree of IGMPv3 due
to the routing functions in IGMPv3.

However, if we were to remove the language on which lists S is an
element of, I think this would work fine. From a switch perspective,

     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 
	INCLUDE(G, Slist1) or EXCLUDE(G, Slist2). "

From a switch (Layer 2) view, if an IGMPv3 host has sent a membership
report of the form   EXCLUDE(G, Slist2), the switch does not do
"forward except for source Slist2."  The switch merely does "forward."
It is up to routers to further prune any streams from sources in 
Slist2.

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, 27 Nov 2002 14:57:03 -0800 (PST)

Hi, Everyone,

Not entirely.

 

Thanks,
	Karen

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 27 Nov 2002 21:37:57 -0800

> that the snooping switch's role is to NOT forward when S is an element

No, it does not imply that. It simply states under which circumstance
forwarding MUST happen, eg: in any case when there is at least one
host requesting traffic potentially from that particular source:

  If at least one host requests INCLUDE(G, {...,S,...})
  Or if a host requests EXCLUDE(G,{S1,...Sn}) where S is not in {S1,...Sn}}

The language does not demand that you have to filter the (S,G) traffic
in the opposite case !!!

> 3 information (i.e., forward except from IP source X.X.X.X) is a router 

a) The whole approach of IGMP snooping is a brute force hack
   between layer 3 and layer 2 !!! Te switch is looking into Layer 3
   information and making forwarding decisions at layer 2. What
   the actual filtering supported by the switch is then really
   just an implementation issue. Historically you would simply
   use existing pure L2 filtering capabilities, eg: based on Dest-MAC
   address only, but that certainly is not an architectural limitation
   of IGMP snooping (aka: there's no architectural limit for an
   architectural hack ;-)

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.

> to effectively become a router.
>
> Or in other words, any wording that

There's no routing function in IGMPv3.

> 	INCLUDE(G, Slist1) or EXCLUDE(G, Slist2). "

No, this definitely is wrong because it demands to always forward 
independent of the source list. Again, that is an implementation choice
and can not be demanded by the Snooping draft. It effectively would
put more intelligent IGMP Snooping implementations that would
specifically benefit SSM out of compliance with the specification.

> "forward except for source Slist2."  The switch merely does "forward."

This is only true for a switch that can do forwarding purely based on
MAC-destination address. There is no reason to restrict the IGMP
Snooping spec to just this class of devices, and it is also contradicting
2.1.2 5).

> It is up to routers to further prune any streams from sources in 

Does not help: Simple setup, router, switch, two hosts on individual
switch ports. Host 1 joins to SSM channel (S1,G), host2 joins to
SSM channel (S2,G). Both would have to receive traffic from both S1 and
S2, and with SSM this is clearly unwanted and in general would be
unacceptable.

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 27 Nov 2002 21:37:57 -0800

Cheers
	Toerless

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 28 Nov 2002 11:12:30 -0500

>   Or if a host requests EXCLUDE(G,{S1,...Sn}) where S is not in 

Karen, Toerless;

As I read this, the wording is correct and it seems reasonably clear.

RFC3376 says that

In EXCLUDE mode, reception of packets sent
      to the given multicast address is requested from all IP source
      addresses *except* those listed in the source-list parameter.

So EXCLUDE does mean forward " if a host requests EXCLUDE(G,{S1,...Sn}) 
where S is not in {S1,...Sn}}"

BTW, the reference section should be updated to reference RFC3376,
not draft-ietf-idmr-igmp-v3-11.txt.

Regards
Marshall Eubanks

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 28 Nov 2002 11:12:30 -0500

Karen, Toerless;

RFC3376 says that

Regards
Marshall Eubanks