Subject: Re: [magma] Call for Agenda Items

From: Karen Kimball <[email-masked]>
Date: Fri, 11 Oct 2002 09:51:39 -0700 (PDT)

Hello, Everyone,

> Magma'ers,
>       This is a call for agenda items for the upcoming Atlanta
> IETF meetings.  Please direct requests to the chairs and/or
> the mailing list.

 I will not be attending the IETF conference, but I would like
 discussion and/or decision on the agenda items that I had sent 
 to the mailing list. 

 There has been no response to these. For the group chairs, what
 is the normal response process for draft proposals?
 
 My agenda items were
 
 1) Changes to wording regarding backward- and forward-compatibility
 2) The need to add text to the Proxy Querying section to note again
 	that Queries with an IP Source Address of 0.0.0.0 MUST NOT
 	be included in the election process
 3) Some editorial cleanup/tweaking.
 
 I'm attaching the messages I sent to the magma mailing list below.
 
 Regards, 
 	Karen Kimball 
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 *   Karen Kimball                     * 
 *   Email: [email-masked]       *
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> =====================================================================
> 
> Hello, all,
> 
> I have a concern regarding how to better IGMPv3's backward 
> compatibility with prior IGMP versions.
> 
> In particular, in section 2.1.1 IGMP Forwarding Rules, we have 
> the following statement in sub-section 3:
> 
> "The switch that supports IGMP snooping MUST flood all unrecog
> nized IGMP messages to all other ports 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 in
> the IGMP header are non-zero MUST NOT be subject to "normal"
> snooping since this could indicate an incompatible change to
> the IGMP message format."
> 
> 
> It is this last sentence that I disagree with.
> 
> The best-practice recommendations for this situation call for
> future versions of a protocol to be useable (NOT IGNORED) by 
> prior versions of the protocol, and for earlier protocol 
> versions not to contaminate future versions.
> 
> This could be expressed in the section above as follows:
> 
> "In addition, earlier versions of IGMP SHOULD interpret IGMP
> fields as defined for their versions and MUST NOT alter these 
> fields when forwarding the message. When generating new messages, 
> a given IGMP version should set fields to the appropriate values 
> for its own version. If any fields are reserved or otherwise 
> undefined for a given IGMP version, the fields SHOULD be ignored 
> when parsing the message and MUST be set to zeroes when new 
> messages are generated by implementations of that IGMP version." 
> 
> This allows earlier versions of IGMP to process (not ignore) 
> messages that are of a recognized type using only the defined-for-
> that-version portions of the message. Later versions may then add
> refinement to the message or its use by setting specific values in
> the reserved fields, and by _appending_ any additional information
> onto the end of the previously-defined end of the IGMP message.
> 
> I propose changing the language of 2.1.1 part 3 to reflect this.  
> The changed paragraph for Section 2.1.1, part 3, would then read,
> 
> 
> 3)  The switch that supports IGMP snooping MUST flood all unrecog
>     nized IGMP messages to all other ports and MUST NOT attempt to
>     make use of any information beyond the end of the network layer
>     header. 
> 
>     In addition, earlier versions of IGMP SHOULD interpret IGMP
>     fields as defined for their versions and MUST NOT alter these
>     fields when forwarding the message. When generating new messages,
>     a given IGMP version should set fields to the appropriate values
>     for its own version. If any fields are reserved or otherwise
>     undefined for a given IGMP version, the fields SHOULD be ignored
>     when parsing the message and MUST be set to zeroes when new
>     messages are generated by implementations of that IGMP version.
> 
> 
> In general I would also say that this language, and much of the 
> language in this IETF draft document, applies to both switches and 
> to any non-Querier routers implementing IGMP. Could we consider 
> updating the document to reflect this?
> 
> Regards,
> 	Karen Kimball
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> *   Karen Kimball                          * 
> *   Hewlett Packard                        *
> *   Email: [email-masked]            *
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> =====================================================================
> 
> Hello, all,
> 
> I have some further inputs regarding the language of section
> 2.1.1 IGMP Forwarding Rules.
> 
> First, sub-section 4 describes the initiation of proxy General
> Queries upon detecting a network topology change. What is missing
> from this section, however, is how this might affect IGMP Querier
> election. This issue is covered for the case described in sub-section
> 2 (proxy-reporting), but is of a larger concern when doing proxy
> General Queries.
> 
> I propose the following language for section 2.1.1 part 4:
> 
> 4)  An IGMP snooping switch SHOULD be aware of link layer topology
>     changes.  Following a topology change the switch SHOULD initi
>     ate the transmission of a General Query on all ports in order
>     to reduce network convergence time. If the switch is not the
>     Querier, it SHOULD use the 0.0.0.0 IP Source Address in these
>     proxy queries. When such proxy queries are received, they
>     MUST NOT be included in the Querier election process.
> 
> 
> 
> 
> I also have additional proposals for changed language in other
> 2.1.1 sections. These would mainly be considered "fixing typos":
> 
> 2.1.1 sub-section 1, part b 
> ---------------------------
> 
> b)  The arrival port for IGMP Queries (sent by multicast
>      routers) where the source where the address is not 0.0.0.0.
> 
> change the last line to
>  
>      routers) where the source IP address is not 0.0.0.0.
> 
> 
> 2.1.1 sub-section 2, paragraph 1
> --------------------------------
> 
> 2)  IGMP snooping switches MAY implement "proxy-reporting" in which
>     reports received from downstream hosts are summarized and used
>     to build internal membership states as described in [PROXY].
>     An IGMP proxy-reporting switch would then report its own state
>     in response to upstream queriers.  If the switch does not
>     alreay have an IP address it SHOULD use the address 0.0.0.0 as
>     source in these reports.
> 
> change the last line to
>  
>     the IP source adddress in these reports.
> 
> 
> 2.1.1 sub-section 2, paragraph 3
> --------------------------------
> 
>     IGMP membership reports MUST NOT be rejected because of a
>     source IP address of 0.0.0.0; however, these messages MUST NOT
>     be included the election process so that a snooping switch does
>     not elected over an active router.
> 
> change the last two lines to
> 
>     be included in the Querier election process so that a snooping 
>     switch is not elected over an active router.
> 
> 
> 
> Regards,
> 	Karen Kimball
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> *   Karen Kimball                          * 
> *   Hewlett Packard                        *
> *   Email: [email-masked]            *
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Karen Kimball <[email-masked]>
Date: Fri, 11 Oct 2002 09:51:39 -0700 (PDT)

Hello, Everyone,

 
 My agenda items were

 
 Regards, 
 	Karen Kimball