Subject: IGMPv3: response to source-and-group specific query when in EXCL mode

From: Wilbert de Graaf <[email-masked]>
Date: Fri, 19 May 2000 15:35:20 -0700

Hi,

The IGMPv3 draft v03 says (in the last table of $5.2 ) that when a host
receives an IGMPv3 source-and-group-specific query, and it's current
interface state is exclude, it has to send a report like this:

INCLUDE (all sources in the query - the sources it has in it's own
exclude list)

So if the exclude state is {a, b}, and the query asks me if I'm
interested for traffic from {c, d, e, f, g, ...} I have to store all of
these addresses until I can send the delayed response. Of course this
can be done but it has some overhead involved.

Why not just respond with your own exclude list ? Or is there some
practical limit on the number of sources that you would store ?

- Wilbert

---

From: Isidor Kouvelas <[email-masked]>
Date: Fri, 19 May 2000 18:00:03 -0700

>practical limit on the number of sources that you would store ?

I think that sending the full EXCLUDE state instead of requesting
reception of the queried sources will probably also work. This is
because current state reports do not trigger queries. Otherwise,
we could get into a query / report loop if the exclude lists from
two hosts contained different sources.

For example if two hosts switch from INCLUDE{} to:
Host1: EXCLUDE{A,B}
Host2: EXCLUDE{B,C}
and they start generating TO_EX reports, then the router will generate
source specific queries for sources A and C.

If a broken host implementation does not generate the correct reports in
response to the queries, and mixes the triggered TO_EX retransmissions
with the responses to the queries, then we can get into a loop where the
TO_EX reports trigger more queries and the queries more TO_EX reports.

I do not think this can happen with EXCLUDE reports but to be on the
safe side, a host implementation should respond to source-specific
queries with an IS_IN record.

thanks
Isidor