Subject: [magma] FW: Comments on draft-ietf-magma-snoop-01.txt

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 12 Mar 2002 12:07:19 -0800

This didn't make it to the old list, so here you all go...

-----Original Message-----
From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:[email-masked]]
Sent: Sunday, March 10, 2002 8:31 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: KIMBALL,KAREN (HP-Roseville,unix1)
Subject: Comments on draft-ietf-magma-snoop-01.txt

Morten,

Attached are some comments from HP ProCurve on your current draft...  Your
original text is highlighted below (>) and some of it has been removed for
brevity.  Nice work, by the way.  The document is very concise and to the
point...

>2.1.1.  IGMP Forwarding Rules
>
>
>1) A snooping switch MUST only forward IGMP Membership Reports on ports
>where multicast routers are attached. Alternatively stated: A snooping
>switch MUST NOT forward IGMP Membership Reports to ports on which only
>hosts are attached.

While this is the general principal and desired operation, the way it is
stated seems to be a little too restrictive.  It should be possible for
management to manually configure forwarding of reports and associated data
to any specific port, regardless of there being a router attached or not.
The intention would normally be to manually configure router ports, but they
could be host ports, or sniffer ports, or whatever.  I guess I object to the
word 'only' in the first sentence, and the generality of the hosts in the
second sentence.  How about the following:

1) A snooping switch MUST forward IGMP Membership Reports on ports
where multicast routers are attached. Alternatively stated: A snooping
switch MUST NOT forward IGMP Membership Reports to ports on which only
hosts are attached unless explicitly configured to do so by management.

>This is the main IGMP snooping functionality. Sending membership reports
>to other hosts can result (For IGMPv2 and IGMPv1) in the unwanted pre-
>vention of a host wishing to join a specific multicast group. This is
>not a problem in a IGMPv3 only network because there is no cancellation
>of IGMP Membership reports.
>
>The switch supporting IGMP snooping MUST maintain a list of multicast
>routers and the ports on which they are attached. This list SHOULD be
>built using IGMP Multicast Router Discovery [MRDISC]. IGMP snooping
>switches MAY alternatively build this list based on
>
>a) The arrival port for IGMP Queries (sent by multicast routers) or
>

It might be useful to include some discussion about how the switch will
determine the Query came from a multicast router and not another snoopy
switch?  Ideally, the switch should not include other snoopy switches that
may be sending queries due to topology changes or other proxy-querier
reasons.  In particular, any query with the 0.0.0.0 IP address as a source
should not be used in this map.

>b) List of ports configured (by management) as having multicast routers
>attached.
>

I would like to see this generalized to simply a list of ports configured by
management.  Again, the intention is to do this for router ports, but it
shouldn't be limited to only ports known to have multicast routers attached.
The sentence could be replaced with the following:

b) List of ports configured by management.

You could add additional discussion about why management might want to
configure this list of ports (e.g. known to have multicast routers
attached).

>Implementation example: IGMP snooping can be achieved by redirecting all
>IGMP packets (IP packets with IP-PROTO = 2) to the CPU (or similar
>higher layer entity) for IGMP message processing and table management.

This paragraph seems to be completely out of context with the other text in
this section.  I suggest that you move this text into an introductory
paragraph since there are no normative statements and it would help in
introducing the general operation of snooping switches.  

>2) IGMP snooping switches MAY implement "proxy-reporting" in which
>reports received from downstream hosts are summarized and used to build
>internal membership states. An IGMP proxy-reporting switch would then
>report it's own state in response to upstream queriers.  If the switch
>does not have an IP address it SHOULD use the address 0.0.0.0 as source
>in these reports.
>
>An IGMP proxy-reporting switch may act as Querier for the downstream
>hosts while proxy reporting to the 'real' upstream queriers.
>

This would be a good place to indicate how this should or should not impact
the querier election process.  The switch should not attempt to take over
the querier function of a real multi-cast router (IMHO).  Can a switch
acting as querier us a source IP address of 0.0.0.0?  If so, then these
frames should be not be considered as part of the querier election process.
This would actually be a needed change in IGMP (I'm guessing).  If the
0.0.0.0 source IP address is used, it would always win the election process
and if there are multiple switches using that address, things would be
confusing.

Two possible suggestions here.  Either the switch MUST have an IP address to
act as querier, or the 0.0.0.0 address can be used, but these frames MUST
NOT be used in the querier election process.

>It should be noted that there may be multiple IGMP proxy-reporting
>switches in the network all using the 0.0.0.0 source IP address. In this
>case the switches can be identified by their, link layer source MAC
>address.
>
>IGMP membership reports should not be rejected because of a source IP
>address of 0.0.0.0.
>
>3) The switch that supports IGMP snooping MUST forward all unrecognized
>IGMP messages and MUST NOT attempt to make use of any information beyond
>the end of the network layer header.  In particular, messages where any
>reserved fields are non-zero MUST NOT be subject to "normal" snooping
>since this could indicate an incompatible change to the message format.

The switch should forward these where?  On all ports, or just to the current
list of router ports and/or manually configured ports.  There seems to be
three independent statements in the two sentences above, so if my reading is
correct I would suggest breaking them out.  The first statement is that
unrecognized IGMP messages MUST be forwarded (where should be specified -
preferably to all ports on the subnet).  The second statement is that
information beyond the network header MUST NOT be used.  Is this just for
unrecognized IGMP messages or all?  The third statement is what to do when
reserved fields are non-zero.  This leads to a much larger comment I have
about forward and backward compatibility and who has responsibility for
making sure things work.  In general I don't agree with the philosophy of
making the older implementations responsible for recognizing and acting upon
future changes.  More on this later... 

>4) An IGMP snooping switch SHOULD be aware of link layer topology
>changes.  Following a topology change the switch SHOULD initiate the
>transmission of a General Query on all ports in order to reduce network
>convergence time.

Again, what are the rules for doing this if the switch is not the designated
Querier or does not have an IP address?  I don't believe it is desirable to
have topology changes cause the querier election process to automatically
kick-in.  

The objective of this, I'm assuming, is to speed-up the process of allowing
the multicast data to flow on the new topology by triggering reports.  It
doesn't seem necessary to send the General Query out all ports, but rather
only those enabled by the new topology. 

Also, a discussion about how this activity might impact the Querier election
process should be included.  Ideally, the switch's query would not be
included in the election process, but I'm not sure this can be avoided.  It
would be great if we could specify that the 0.0.0.0 address be used and that
these frames are to be ignored by the election process.  This might require
other documents to be updated.   

>5) An IGMP snooping switch MUST discard from the IGMP snooping process
>IGMP packets where IP or IGMP headers have checksum errors.

By discard, I assume you mean don't give to the CPU and don't forward out
the router and other ports?  The result of not forwarding the packets is
that the snooping switch acts like a 'network cleanser' on bad IGMP packets.
While I agree this is a good idea, I'm wondering if making this a MUST
requirement is truly what is desired.  The switch MUST NOT act upon those
packets for sure, and it SHOULD NOT forward those packets.  If it choose to
forward the packets, it MUST forward them as unknown packets.  The switch
SHOULD take note of this event (e.g. at least increment a counter).

>2.1.2.  Data Forwarding Rules
>
>
>6) Packets with a destination IP (DIP) address in the 224.0.0.X range
>which are *not* IGMP MUST be forwarded on all ports.
>
>This requirement is based on fact that many hosts exist today, which
>does not Join IP multicast addresses in this range before sending or
>listening to IP multicast. Furthermore since the 224.0.0.X address range
>is defined as link local (not to be routed) it seems unnecessary to keep
>state for each address in this range.
>
>7) Packets with a destination IP address outside 224.0.0.X which are
>*not* IGMP SHOULD be forwarded according to group based port membership
>tables and MUST also be forwarded on router ports.
>
>This is the core IGMP snooping requirement for the data path.
>
>Discussion: An implementation could maintain separate membership and
>multicast router tables in software and then "merge" these tables into a
>current forwarding cache.
>
>8) If a switch receives a *non* IGMP multicast packet without having
>first processed Membership Reports for the group address, it MUST for-
>ward the packet on all ports.  In other words, the switch must allow for
>the possibility that connected hosts and routers have been upgraded to
>support future versions or extensions of IGMP that the switch does not
>yet recognize. A switch MAY have a configuration option that suppresses
>this operation, but default behavior MUST be to allow flooding of unreg-
>istered packets.

I don't agree with this position and this default behavior.  It seems
completely backward to me.  I understand the point about attempting to
prevent incorrect behavior in the presence of a future version of IGMP, but
this should not be the responsibility of the current operating version, it
should be the responsibility of the future version of IGMP or whatever
protocol may conflict.  Future versions should attempt to be backward
compatible whenever they can.  It is just too impractical for a legacy
version to predict the future.  What could or should be mandated is that it
is possible to configure the device into such a mode that allows operation
with a future version (including mandating a configuration option to disable
the functionality completely), but this should not be the default behavior.
The burden is on the future version of the protocols, not the existing.  

The default behavior you are proposing yields no optimization what-so-ever
in the common configuration where a group of multicast senders is separated
from receivers by a multicast router.

I suggest the following modification to the text above:

8) If a switch receives a *non* IGMP multicast packet without having
first processed Membership Reports for the group address, it MAY for-
ward the packet on all ports, but it MUST forward the packet on router
ports.  A switch MAY forward an unregistered packet only on router
ports, but the switch MUST have a configuration option that suppresses
this restrictive operation and forces flooding of unregistered packets
on all ports.

>9) IGMP snooping switches MAY maintain forwarding tables based on either
>MAC addresses or IP addresses. If a switch supports both types of for-
>warding tables then the default behavior MUST be to use IP addresses.
>
>Discussion: Forwarding based on MAC addresses is subject to the problem
>associated with the 32-fold IP address to 1 MAC address mapping.

True that it is better to use IP addresses, but a MUST here seams a little
strong.  I think a recommendation to use IP is sufficient (e.g. default
behavior SHOULD be to use IP addresses).  This isn't going to fix the
overlap problem and there are no standards for L2 forwarding based upon L3
addresses, so I don't think it is appropriate to mandate this.  

>10) Switches which rely on information in the IP header SHOULD verify
>that the IP header checksum is correct. If the checksum fails the packet
>SHOULD be silently discarded.

This seems inconsistent with the previous discussion on IP header checksums.
If the switch is going to make forwarding decisions based upon information
in the IP header, then the checksum MUST be correct.  If it isn't correct,
the switch MAY flood the packet as it would any unknown packet, or it MAY
discard the packet (again, acting as a network cleanser).  We could
recommend a behavior of discarding by adding the statement that it SHOULD
discard.
I'm not sure why we would want to 'silently' discard the packet though.  It
would seem that these errors should at least be counted.

As a side note, the validation of the checksum must assume proper
classification of the packet as an IPv4 or IPv6 frame, otherwise this might
be violating the 'future proofing' approach taken above on IGMP - which I
don't agree with.
What if some future version of IP used a different checksum or header
format, but the other fields magically made the frame look like an
IP-multicast datagram?  This is obviously not an issue in practice, but
perhaps this paper should include (by reference at least) a description of
IGMP frame classification.

Other comments:

I believe it would be helpful to include two additional sections to this
document.  Perhaps both belong in section 2.1.1, but perhaps the latter of
the two belongs in 2.1.2.  Anyway they include:

a.	Discussion of the snooping switches role in the Querier election
process, and how the switch should assume the role of Querier if no routers
are detected, and forfeit the role if routers appear
b.	Discussion about how to properly age entries from the list, unless
you believe there is no difference between what a router would do and what
the snooping switch would do.

Regards,

Paul Congdon

+------------------------------------------+
Paul Congdon
HP ProCurve Networking
Hewlett Packard Company
8000 Foothills Blvd - M/S 5662
Roseville, CA   95747
phone: 916-785-5753
email: [email-masked]
+------------------------------------------+

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