Subject: [magma] IGMP Snooping Draft 6 Section Replacement

From: Karen Kimball <[email-masked]>
Date: Thu, 13 Mar 2003 13:00:45 -0800 (PST)

Hello, everyone,

The co-authors of the IETF draft for Considerations for IGMP and MLD 
Snooping Switches wish to revise a portion of the proposed version 06
draft. This part of the original version 6 text had not been reviewed
by the other co-authors at the time of posting, and since then a new
approach was discussed and preferred.

This concerns Section 4 of the 2.1.1. IGMP Forwarding Rules, which
deals with Proxy Querying when topology changes occur.

The proposed new text for this section is as follows:

    "4)  An IGMP snooping switch should be aware of link layer topology
         changes. These changes may result from enabling/disabling of
         ports due to Spanning Tree operation. A port's up/down state
         may also change due to network management configuration, or
         because of devices being attached to or removed from that port.

         In the Spanning Tree case, a General Query should be sent on
         all active ports in order to reduce network convergence time.
         A switch may optionally send a General Query only on the ports
         affected by the Spanning Tree operation but this behavior must
         be configurable.

         In the case of network management newly enabling a port, or the
         addition of a new device (host/switch/router) to a previously
         unused port, a General Query is sent on the new port only. This
         operation can be followed by an MRD discovery on this port.

         In the case of network management disabling a port, or the
         removal of a device (host/switch/router) from a previously
         active port, no action is necessary.

         If the switch is not the Querier, it should use the 'all-zeros'
         IP Source Address in these proxy queries.  When such proxy
         queries are received, they must not be included in the Querier
         election process."

The full 2.1.1. IGMP Forwarding Rules, with this new text, is shown
below for context.  

Please review this section if interested, and post any comments to
the Magma mailing list.

Thank you,
	Karen Kimball
	[email-masked]

...................................................

Excerpt from      Considerations for IGMP and MLD Snooping Switches
                    <draft-ietf-magma-snoop-06.txt>

2.1.1.  IGMP Forwarding Rules

     1)  A snooping switch should forward IGMP Membership Reports only
         to those ports where multicast routers are attached.
         Alternatively stated: a snooping switch should not forward IGMP
         Membership Reports to ports on which only hosts are attached.
         An administrative control may be provided to override this
         restriction, allowing the report messages to be flooded to
         other ports.

         This is the main IGMP snooping functionality.  Sending
         membership reports (as described in IGMP versions 1 and 2) to
         other hosts can result in unintentionally preventing a host
         from joining a specific multicast group.  This is not a problem
         in an IGMPv3-only network because there is no message
         suppression of IGMP Membership reports.

         The administrative control allows IGMP Membership Report
         messages to be processed by network monitoring equipment such
         as packet analyzers or port replicators.

         The switch supporting IGMP snooping must maintain a list of
         multicast routers and the ports on which they are attached.
         This list can be constructed in any combination of the
         following ways:

         a)  This list should be built by the snooping switch sending
             Multicast Router Solicitation messages as described in IGMP
             Multicast Router Discovery [MRDISC].  It may also snoop
             Multicast Router Advertisement messages sent by and to
             other nodes.

         b)  The arrival port for IGMP Queries (sent by multicast
             routers) where the source address is not 0.0.0.0.

         c)  Ports explicitly configured by management to be IGMP-
             forwarding ports, in addition to or instead of any of the
             above methods to detect router ports.

     2)  IGMP snooping switches may also implement "proxy-reporting" in
         which reports received from downstream hosts are summarized and
         used to build internal membership states as described in
         [PROXY].  The IGMP proxy-reporting switch would then report its
         own state in response to upstream queriers.  If the switch does
         not already have an IP address assigned to it, the source
         address for these reports should be set to all-zeros.

         An IGMP proxy-reporting switch may act as Querier for the
         downstream hosts while proxy reporting to the 'real' upstream
         queriers.

         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 uniquely
         identified through their link layer source MAC address.

         IGMP membership reports must not be rejected by an IGMP
         snooping switch because of a source IP address of 0.0.0.0.

     3)  The switch that supports IGMP snooping must flood all
         unrecognized 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.

     4)  An IGMP snooping switch should be aware of link layer topology
         changes. These changes may result from enabling/disabling of
         ports due to Spanning Tree operation. A port's up/down state
         may also change due to network management configuration, or
         because of devices being attached to or removed from that port.

         In the Spanning Tree case, a General Query should be sent on
         all active ports in order to reduce network convergence time.
         A switch may optionally send a General Query only on the ports
         affected by the Spanning Tree operation but this behavior must
         be configurable.

         In the case of network management newly enabling a port, or the
         addition of a new device (host/switch/router) to a previously
         unused port, a General Query is sent on the new port only. This
         operation can be followed by an MRD discovery on this port.

         In the case of network management disabling a port, or the
         removal of a device (host/switch/router) from a previously
         active port, no action is necessary.

         If the switch is not the Querier, it should use the 'all-zeros'
         IP Source Address in these proxy queries.  When such proxy
         queries are received, they must not be included in the Querier
         election process.

     5)  An IGMP snooping switch must not make use of information in
         IGMP packets where the IP or IGMP headers have checksum or
         integrity errors.  The switch should not flood such packets but
         if it does, it should also take some note of the event (i.e.,
         increment a counter).  These errors and their processing are
         further discussed in [IGMPv3], [MLD] and [MLDv2].

     6)  The snooping switch must not rely exclusively on the appearance
         of IGMP Group Leave announcements to determine when entries
         should be removed from the forwarding table.  It should instead
         implement the router side functionality of the IGMP/MLD
         protocol as described in [PROXY] on all its non-router ports.

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

---

From: Haixiang He <[email-masked]>
Date: Thu, 13 Mar 2003 18:14:18 -0500

> Please review this section if interested, and post any comments to

I made a comment on how to use IGMP proxy in Atlanta IETF. The comment
relates to the above section and I think the it needs more clarification.

IGMP Proxy allows only ONE upstream interface. However a switch may have
more than one routers connected through different ports. My question is how
we treat these ports when performing IGMP Proxy. One virtual upstream
interface covering all router ports or each interface per router port and
configure only one as the upstream interface?

My suggestion: treat them as one virtual interface and reports to all router
ports when queried.

>          queries are received, they must not be included in the Querier

I think there is a problem if the switch supports only IGMPv2 but the router
uses IGMPv3. Sending IGMPv2 queries by the switch will force IGMPv3 hosts to
backdown to IGMPv2 until it receives another IGMPv3 query. Is this behavior
acceptable? If not, I think more suggestions are required.

In addition, sending v2 queries to router ports will force v3 routers to log
errors. So I suggest to adopt version -06 idea not sending queries to router
ports.

Cheers,

haixiang

---

From: Haixiang He <[email-masked]>
Date: Thu, 13 Mar 2003 18:14:18 -0500

Cheers,

haixiang

---

From: Karen Kimball <[email-masked]>
Date: Thu, 13 Mar 2003 16:45:29 -0800 (PST)

Hello, Haixiang,

I should clarify the intent of this section regarding Proxy
Querying, because Brian Haberman interpreted it similarly. 

This is NOT the behavior described in the IGMP/MLD Proxy Draft
document.

This is the behavior of having IGMP snooping switches "spoof"
a General Query out when the network topology changes, to trigger
hosts to re-send their IGMP Reports (Joins).

It isn't IGMP Proxy behavior. It's just a proxy Query.

Does that clear things up?

Sorry for any confusion. This IGMP/MLD Snooping draft should be
independent of the IGMP/MLD Proxy draft.

I see, however, that you have raised other issues that do pertain
to the Snooping switch behavior, namely,

> acceptable? If not, I think more suggestions are required.

I don't think this behavior is desireable. 

However, I would expect that, even though the switch is largely an IGMPv2 
switch, it could spoof up an IGMPv3 Query for these purposes.

We could add a recommendation that the spoofed Query match the IGMP 
version being used by the current true Querier. 

> errors. So I suggest to adopt version -06 idea not sending queries to router

This was my original recommendation to the co-authors as well, so I
need Morten to weigh in on this as he has consistently supported the 
proxying out of router ports and may be able to argue for this where
I cannot.

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: Thu, 13 Mar 2003 16:45:29 -0800 (PST)

Hello, Haixiang,

Thanks,
	Karen

---

From: Haixiang He <[email-masked]>
Date: Fri, 14 Mar 2003 10:52:47 -0500

Hi Karen,

My intent is not to require a snooping switch to perform Proxy.

I guess I don't understand how the General Query is generated. I think the draft
still needs to clearly describe the behavior of generating a General Query. And it
would be better to describe separately for an IGMPv2 switch and IGMPv3 switch.

"Proxy Querying" gives me a real-time feeling. I don't think that is the intent of
the draft. "Spoof Query" sounds a good behavior to me.

Another question is "Will an IGMPv2 switch treat an IGMPv3 General Query as
recognized or unrecognized IGMP message?" If unrecognized, according section 3,
the switch must not make use of it.

In addition, I think the second paragraph of section 3 does not match your
suggestion. I suggest you describe how an IGMPv2 switch deals and spoofs an IGMPv3
Query.

Haixiang

---

From: Haixiang He <[email-masked]>
Date: Fri, 14 Mar 2003 10:52:47 -0500

Hi Karen,

Haixiang

---

From: "Karen Kimball" <[email-masked]>
Date: Fri, 14 Mar 2003 10:04:43 -0800

Hello, Haixiang,

> My intent is not to require a snooping switch to perform Proxy.

Neither is ours! Sending occasional proxied General Queries does not 
make a switch any kind of Proxy Device.

> I guess I don't understand how the General Query is 
> generated. I think the draft still needs to clearly describe 
> the behavior of generating a General Query. And it would be 
> better to describe separately for an IGMPv2 switch and IGMPv3 switch.

Are you asking _why_ the General Query is being generated? It is to
trigger hosts to send out new Joins so that their multicast groups will
be forwarded to them immediately on the new network path. Otherwise,
they
have to wait until the next General Query from the true Querier to come
by. Having the switch proxy out a General Query reduces the latency in
going over to the new forwarding path.

Actually generating the General Query isn't difficult. Many switches are
already capable of becoming the IGMP Querier if there is no other
Querier
present on the network.

Our Snooping Switch draft requests that if the switch is not the true
Querier, it use the 0.0.0.0 IP Source Address in this proxy Query so
that
it will not be mistaken for the real Querier (and will not trigger a
Querier Election). 

The intent is purely to trick hosts into sending out Joins early.

As to the other point, even an IGMPv2 switch can spoof up an IGMPv3
Query
if the network is running IGMPv3. The implementer needs to be aware of
the differences between the IGMPv2 and IGMPv3 General Query in this
case.
That isn't all that difficult. They can refer to the IGMPv3 standard.

> Another question is "Will an IGMPv2 switch treat an IGMPv3 
> General Query as recognized or unrecognized IGMP message?" If 
> unrecognized, according section 3, the switch must not make use of it.

How can the IGMPv3 Query not be recognized? It is longer than the v2
Query, but it is the same message type of 0x11. An IGMPv2 switch might
simply not be aware of any additional information that the IGMPv3 Query
contains.

In reality, as an implementer you want your code to keep pace with the
current network world. Even if the switch is going to remain primarily
IGMPv2, there is no reason that code upgrades cannot allow such features
as detecting the IGMPv3 General Query (its length is longer than the v2
Query) and parsing the additional fields in it if desired.

> In addition, I think the second paragraph of section 3 does 
> not match your suggestion. I suggest you describe how an 
> IGMPv2 switch deals and spoofs an IGMPv3 Query.

There is no restriction against being IGMPv3-aware in a primarily IGMPv2
switch. 

If the switch is IGMPv2-only, and no further implementation upgrades are
planned, the switch is definitely not going to send out any proxy
Queries
of any kind (because this is a new recommended behavior). So this
becomes
moot.

In our recommendations for Snooping Switches, we could add a small note
to 
the bottom of the new 2.1.1. section 4, such as,

	"Furthermore, a non-Querier switch should be aware of whether
the 
	Querier is in IGMPv3 mode. If so, any proxy queries the switch 
	generates should be IGMPv3 and should use the true Querier's
most 
	recent General Query information for the additional IGMPv3
fields 
	such as 'QRV and QQIC'. In this IGMPv3 case, the switch should
also 
	set the 'S'flag to 1, to suppress router timer updates, and the 
	'Resv' field and 'Number of Sources' field should both be set to
0."

I believe this would satisfy your point?

Thanks for the comments,

	Karen Kimball
	[email-masked]

> Querying, 
> > because Brian Haberman interpreted it similarly.
> >
> > This is the behavior of having IGMP snooping switches "spoof" a 
> > General Query out when the network topology changes, to 
> trigger hosts 
> > to re-send their IGMP Reports (Joins).
> >
> > I see, however, that you have raised other issues that do 
> pertain to 
> > the Snooping switch behavior, namely,
> >
> > > >          because of devices being attached to or 
> removed from that 
> > > > port.
> > > >
> > > I think there is a problem if the switch supports only IGMPv2 but 
> > > the router uses IGMPv3. Sending IGMPv2 queries by the switch will 
> > > force IGMPv3 hosts to backdown to IGMPv2 until it 
> receives another 
> > > IGMPv3 query. Is this behavior acceptable? If not, I think more 
> > > suggestions are required.
> >
> > However, I would expect that, even though the switch is largely an 
> > IGMPv2 switch, it could spoof up an IGMPv3 Query for these purposes.
> >
> > > In addition, sending v2 queries to router ports will force v3 
> > > routers to log errors. So I suggest to adopt version -06 idea not 
> > > sending queries to router ports.
> >
> > proxying out of router ports and may be able to argue for 
> this where I 
> > cannot.
> >
> > Thanks,
> >         Karen
> >

---

From: "Karen Kimball" <[email-masked]>
Date: Fri, 14 Mar 2003 10:04:43 -0800

Hello, Haixiang,

Thanks for the comments,

	Karen Kimball
	[email-masked]