Subject: [magma] Conflicting statements in RFC 3810 - MLDv2

From: Anupam S <[email-masked]>
Date: Thu, 8 Sep 2005 19:20:29 -0700 (PDT)

Sec 2.2: Last para states:

> In the original (first) query the S flag is
> clear.  When the Querier sends this query, it
> lowers the timers for the concerned multicast
> address (or source) to a given value;

Now this I take to imply that the First Query of the
re-transmission set should have the "S" flag-bit
UNSET. Also the re-transmissions that follow will have
"S" flag-bit SET since the timers were lowered to LLQT
while sending the First Query of the series of
re-transmissions.

This para makes perfect sense.

Also, Sec 7.6.1 Timer Updates states:

> When a router sends or receives a query
> with a clear Suppress Router-Side
> Processing flag, it must update its timers
> to reflect the correct timeout values for
> the multicast address or sources being queried. 

Note the word "sends" above and this statements also
is inline with the previous assertion. So far
everythings going good.

Here comes the contradiction and the mistake:

Sec 7.6.3.1 Building and sending Multicast address
specific queries states:

> When transmitting a Multicast Address
> Specific Query, if the Filter Timer is
> larger than LLQT, the "Suppress Router-Side
> Processing" bit is set in the query message.

How/Why in the world can/will you SET the "S" flag-bit
here!?! It should be UNSET (i.e., CLEAR) if you intend
the non-Querier to be in sync with the Querier's
timers. Infact the *only* Query in which the "S"
flag-bit will *ever* be UNSET is in the First Query of
a series of re-transmissions (assuming there are no
other G-recs/G,S-recs change state)

The above statement is clearly in contradiction with
the statement #1 above where in it states:
> In the original (first) query the S flag is
> clear.
The first Query *is* when you just possibly could have
lowered the G-Timer to LLQT. So the "S" flag-bit
*should* be UNSET.
 
Can someone please clarify (in *detail*) this
contorted logic? Has anyone implemented this stuff
yet? I looked into IGMPv3 rfc3376 and that does not
even clearly state the first two statements
illustrated above - it *just* restates the *only* the
statements in Sec 7.6.3.1 above and totally avoids
even a mention of the first two statements mentioned
above!!! Are both RFCs misleading?

		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

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

---

From: "Rolland Vida" <[email-masked]>
Date: Fri, 9 Sep 2005 14:50:27 +0200

Hi,

There is no mistake in RFC3810, you only misunderstood the order of the
actions that have to be taken. See my answers below.

> timers. 

The S flag should be SET indeed, as it is written in the text. Here is
the complete text of paragraph of sec 7.6.3.1: 

   When a table action "Send Q(MA)" is encountered, the Filter Timer
   must be lowered to LLQT.  The Querier must then immediately send a
   Multicast Address Specific query as well as schedule [Last Listener
   Query Count - 1] query retransmissions to be sent every [Last
   Listener Query Interval], over [Last Listener Query Time].

   When transmitting a Multicast Address Specific Query, if the 
   Filter Timer is larger than LLQT, the "Suppress Router-Side
   Processing" bit is set in the query message.

So what is important is the order of the actions. First the timer is
lowered to LLQT. Then, the Querier sends the first query, and schedules
the following ones. For each of these queries, the Querier checks the
value of the timer. For the first query it will be obviously equal to
LLQT, as we just set it to that value. So the first query is sent with
the S flag clear. If no answer is received, the timer will decrease and
all the subsequent queries will be also sent with the S flag clear.
However, if the Querier receives a report for the queried address, it
will update its timer to MALI, which is obviously larger than LLQT. If
there are still queries to be sent, only those will have the S flag set.
If you read now again the second paragraph of 7.6.3.1, it is exactly
what it says. Again, this paragraph does not say anything about the
handling of the first query, as for this one the timer is not larger
then LLQT.

> Infact the *only* Query in which the "S"

As I explained before, this is not true. There might be several queries
with the S flag unset. 

> above!!! Are both RFCs misleading?

IGMPv3 RFC3376 does not say that much about this issue indeed. In
RFC3810 we tried to explain more thoroughly the details of the
algorithm; including Section 2 had this specific purpose. I hoped that
for example the last paragraph of section 2.2, that you've cited also,
was clear enough in this sense. But it seems that it could have been
even clearer :-)

Cheers,
Rolland