Subject: [magma] IGMP-MLD-Proxying Draft Comments No.1

From: Karen Kimball <[email-masked]>
Date: Sun, 9 Mar 2003 09:57:15 -0800 (PST)

Comments on    IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")

This first set of comments will deal with problems in the forwarding behaviors
described by the protocol.

Section 3. Abstract protocol definition   describes the forwarding behaviors
for the IGMP/MLD Proxy device. However, I can think of network setups-- in
a tree structure as prescribed-- where this will not work. Given the following,
where the Proxy Querier A is the "Root" device,

                      < Larger LAN >         upstream
                            |                  ^
                            |                  |
                      Proxy A (Querier)      [ROOT]
                     /      |          \
                    /       |           \
                   /        |            \
             Proxy B    Proxy C           Proxy E
            /   \      /       \         /    |   \
           /     \    /     Proxy D     /     |    \
      Host1   Host2  Host3   /    \   Host6  Host7  Host8
                            /      \
                        Host4    Host5

if Proxy B receives a packet from Host1, it will forward the packet ONLY 
upstream to Proxy A. Proxy A will forward the packet down to all of its members.

But what if Host2 needed to receive the packet as well? Proxy B can't forward
the packet because Proxy B is not the Querier (and can't forward downstream).
Proxy A cannot forward the packet to HOst2 because the packet was received on
the interface from Proxy B, and the algorithm doesn't allow re-sending the 
packet down the received interface.

If Proxy B is NOT a Proxy device, but is instead an IGMP router or an 
IGMP-snooping-switch, it would forward this packet appropriately to its local
members.

The Abstract protocol definition doesn't specify or recommend this, however. 
The wording of Section 2.5, "each proxy device," implies that there may be more 
than one proxy device (where obviously, only one of them can be the Querier).

Here is another example, with a non-Root Proxy Querier:

                      < Larger LAN >         upstream
                            |                  ^
                            |                  |
                        Proxy A              [ROOT]
                     /      |   \
                    /       |    *-------
                   /    (Querier)        \
             Proxy B    Proxy C           Proxy E
            /   \      /       \         /    |   \
           /     \    /     Proxy D     /     |    \
      Host1   Host2  Host3   /    \   Host6  Host7  Host8
                            /      \
                        Host4    Host5

Similarly to the example above, if Host 4 sends a packet that Host5 also
needs, Proxy D is not allowed to forward it locally to Host5 (because Proxy D
isn't the Querier) and Proxy C isn't allowed to forward it back down the
Proxy D interface. Host5 will not receive the packet.

I believe some additional considerations are needed for this protocol behavior.

I.    Should there be a requirement that the Root always be the Forwarding 
      Proxy and also always be the Querier? 

II.   Should there be an additional change in the behavior for the Proxies to 
      ALSO forward multicasts according to the IGMP protocol (forward as for 
      the Proxy protocol IN ADDITION to forwarding as for the IGMP Protocol)? 

III.  Or should there instead be a requirement that each Root Subtree include 
      only ONE Proxy device, and that all other devices "downstream" in the 
      tree can be IGMP-supporting but should not be Proxy devices?

IV.   I believe that Section 3.2 Supporting Senders   should explicitly also 
      state that all multicast traffic must also be forwarded toward the 
      Querier (as is always the case for IGMP). This becomes a non-issue if 
      consideration II. is chosen.

I will send additional comments in separate emails.

Best Regards,

        Karen Kimball
        [email-masked]

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