Re: [magma] Snooping draft items 2.1.1.6 & 2.1.2.7

On Thursday, November 28, 2002, at 12:37 AM, Toerless Eckert wrote:

> On Wed, Nov 27, 2002 at 02:57:03PM -0800, Karen Kimball wrote:
>> 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.
>
> 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}}

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

>
> The language does not demand that you have to filter the (S,G) traffic
> in the opposite case !!!
>
>> 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.
>
> 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.
>
>> 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.
>
> There's no routing function 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). "
>
> 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.
>
>> 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."
>
> 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
>> Slist2.
>
> 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
> _______________________________________________
> magma mailing list
> magma@ietf.org
> https://www1.ietf.org/mailman/listinfo/magma