Subject: [magma] MLDv2: operation without state change reports: exclude list

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Feb 2003 18:12:11 +0100 (CET)

Proceeding with the exclude list (i.e. (B) in section 6.4.1) I get
even more confused.

It seems very hard to understand what (B) is with the given definition.

What I can understand is the need to maintain the intersection of
the source lists for all the listeners in EXCLUDE state, but this
is not what (B) says.
When operating with mixed listeners the set of sources that can be excluded
by the router is the above intersection minus the (union of all the listeners
in INCLUDE state).
But I think it is a lot easier to analyze the protocol if
one describes this separately.

For instance, it is impossible for me to grasp how the protocol recovers
from total packet loss of state change reports (i.e. falls back
to using the periodic queries to rebuild state) when one or more
listeners in EXCLUDE state reduces the set of sources that they don't
want to hear.

  Erik

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

---

From: "Rolland Vida" <[email-masked]>
Date: Fri, 14 Feb 2003 22:46:37 +0100

> listeners in EXCLUDE state reduces the set of sources that they don't

I hope that my previous e-mail clarified a bit the question...

Let us imagine that there is a receiver in Exclude (Y) state, and the router
in Exclude (X,Y). Now the receiver sends several state change reports
containing Allow records, reducing the list of blocked sources, as you
required. Let us suppose that all these messages are lost.

Now the receiver sends its current state report IS_EX (A), which arrives,
with A being a subset of Y.

As specified in the last line of the table from section 6.4.1, the router
switches to EXCLUDE (A-Y, Y*A), i.e EXCLUDE (void, A). This is OK from the
point of view of the receiver that has sent the state report. In the
meantime, X is deleted from the state of the router, but if there is a
different receiver that is in INCLUDE (X), it will confirm its state before
the multicast address timer expires.

So, for me, the behaviour seems to be correct.

Thanks,
Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Fri, 14 Feb 2003 22:46:37 +0100

Thanks,
Rolland

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Feb 2003 16:58:06 +0100 (CET)

> > listeners in EXCLUDE state reduces the set of sources that they don't

But the interesting and hard case is what happens when the increase the
set of sources that they do not want to hear.

Thus with the router in EXCLUDE (nil, Y) there is an IS_EX(A) where
A is a superset of Y (A=Y+B) and there is no other listener on the link.
Then you get the state of          EXCLUDE (B, Y)     (B)=MALI 
                                                       Multicast Address
                                                       Timer = MALI

If there is no other listener on the link when does the router
start to exclude B?
If this what the 5th line in the table in 6.3 is trying to say?
That is far from clear to me.

Assume a second listener with state EXCLUDE (Y).
It responds to a periodic query before MALI expires with IS_EX(Y).
So we go back to			EXCLUDE (nil, Y) 
                                                       Delete (B)
                                                       Multicast Address
                                                       Timer = MALI

> So, for me, the behaviour seems to be correct.

I don't find any holes.

Unfortunately this is not sufficient to satisfy RFC 2026.
It says
   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

Thus I'm concerned about the "well-understood" part.

The router state machine is the most complex state machine I've ever
seen in any category of protocols.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Feb 2003 16:58:06 +0100 (CET)

I don't find any holes.

   Erik

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 26 Feb 2003 10:28:10 +0100

> If this what the 5th line in the table in 6.3 is trying to say?

Yes. The router will start to exclude B when the timers of sources from B
will expire. Note that both the source timers from B and the Multicast
Address Timer are set to MALI. Before those timers expire, if the Exclude
mode listener is still there, it will resend an IS_EX(A) report. The state
transition for that report wilbe the following:

    EXCLUDE (B,Y)    IS_EX (A)     EXCLUDE (B, Y)    (A-B-Y)=MALI
                                                      Multicast Address
                                                      Timer = MALI

But A-B-Y=nil. Thus, the Requested List and the Exclude List (as defined in
my previous mail) remain the same, only the Multicast Address Timer is
updated. Later on, the timers of sources from B will eventually expire, B is
moved in the Exclude List, and the router will start to block B.

> So we go back to			EXCLUDE (nil, Y)

Right. But that behavior is correct. If that receiver is listening on the
link, from its state it is clear that it is interested in sources from B.
Those sources are blocked only after their timers expire. As those timers
are set to MALI the first time B is asked to be blocked, the listener in
EXCLUDE(Y) state has enough time to send its report and avoid the sources
from B being blocked.

I agree that in the case you propose the sources from B are not blocked
rapidly (only after MALI, not after LLQI). Nevertheless, this case only
occurs when all the [Robustness Variable] state change reports were lost.
That's why the router learns about sources from B in a current state report.
We have chosen to send address or source-specific queries only in answer to
state change reports, as otherwise we would generate an increased number of,
usually unuseful, messages. If there are serious packet losses, as you
mention, the blocking is not immediate. Nevertheless, the correct listening
state is regained after a short period.

Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 26 Feb 2003 10:28:10 +0100

Rolland