Subject: [magma] MLDv2: invariant behavior

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

Based on my (so far limited) understanding of MLDv2 it seems
like there are some things which essentially are invariants (or should be).

For instance, if an INCLUDE mode listener adds an address to its source list
and sends an ALLOW, there shouldn't need to be any difference between this
ALLOW being processed on the router, and the processing the router would do
if the ALLOW (and its retransmissions) were lost and the first time it
hears about the new group is in an IS_IN current state report.

Yet the state tables for
 EXCLUDE (X, Y)		IS_IN (B)
and 
 EXCLUDE (X, Y)		ALLOW (A)
have different actions.
Is this difference because it is assumed that the ALLOW is from
a listener in EXCLUDE mode?

I think a similar invariant makes sense between an EXCLUDE mode listener
which adds an address and sends a BLOCK, and the first time the router
hears about the new blocked address is in an IS_EX report.

Finally, an invariant makes sense between an TO_EX and the router not hearing
about the state change until it receives an IS_EX.

Why do I think these make sense? Because in these cases the state change 
messages do not provide any information that can not be extracted from is
current status reports. The router can tell when the INCLUDE list is
extended (since it is maintaining the union of includes), when the
EXCLUDE list is shortened (since it is maintaining the intersection
of excludes), and when the first EXCLUDE listener appears (since EXCLUDE
takes precedence over INCLUDE).

The state change messages that allow the router to more quickly detect
changes is
 - a TO_IN, since it might be the last EXCLUDE mode listener going away
   Thus it makes sense to query if there are any more EXCLUDE mode
   listeners.
 - an INCLUDE mode listener removing an entry from its source list
   since it makes sense quering to detect if any other INCLUDE mode listener
   has that source it in its source list.
 - an EXCLUDE mode listener adding an entry from its source list
   since it makes sense to check if all other EXCLUDE listeners also has
   that entry in their source list

But my conceptual model of the protocol doesn't match what is in the draft.

And if I can't understand this I can't check if the protocol in fact
is robust.

  Erik

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

---

From: "Rolland Vida" <[email-masked]>
Date: Fri, 14 Feb 2003 23:40:53 +0100

> hears about the new group is in an IS_IN current state report.

Right, there's no difference.

> have different actions.

I do not follow you.
The third line from the table in 6.4.1 states:

   EXCLUDE (X,Y)   IS_IN (A)     EXCLUDE (X+A,Y-A)    (A)=MALI

while the fifth line from the table in 6.4.2 states the same thing:

   EXCLUDE (X,Y)   ALLOW (A)     EXCLUDE (X+A,Y-A)    (A)=MALI

> hears about the new blocked address is in an IS_EX report.

The Exclude is slightly different, as a Block report does not update the
multicast address timer, while an IS_EX report it does.

Let's see the two cases from the tables:

EXCLUDE (X,Y)     IS_EX (A)     EXCLUDE (A-Y, Y*A) (A-X-Y)=MALI
                                                       Delete (X-A)
                                                       Delete (Y-A)
                                                       Multicast Address
                                                       Timer = MALI

EXCLUDE (X,Y)   BLOCK (A)      EXCLUDE (X+(A-Y),Y)  (A-X-Y)=Multicast
                                                       Address Timer
                                                       Send Q(MA,A-Y)

In the first case, sources from X are deleted from the router state. As the
mcast address timer it was updated, interested receivers can restore those
sources, before the INCLUDE switch occurs.

In the second case, a block message can be sent either by a receiver in an
Include or in an Exclude state. Thus, the mcast address timer is not
updated. Therefore, the sources from X should be kept, to correctly handle
the exclude-include switch, if it occurs.

On the other hand, in the first case, the router for sure only that sources
from Y*A should be blocked. It does not know anything about sources in Y-A,
so it deletes them from its state. Those sources will start to be forwarded.
If someone asks then again to block them, the router state will be updated
accordingly. Forwarding an unwanted source is not a misbehavior, as the
packet will be dropped at the receiver, instead of the router. What would be
a problem is to block a source that has listeners on the link. But, as far
as I see, this problem will not occur.

So finally, in the second case, from the Block (A) message the router cannot
deduce anything concerning the sources in Y-A. They were explicitly demanded
to be blocked previously, and the block message does not concern them.
That's why the second term of the expression stays Y, instead of Y*A, as in
the first case. By continuing to block sources from Y-A, it is sure that we
will not block desired sources.

> And if I can't understand this I can't check if the protocol in fact

I hope that my explanations were clear enough, and you understand better
what we meant to do. Do you agree with those arguments?

Thanks,
Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Fri, 14 Feb 2003 23:40:53 +0100

I do not follow you.

Thanks,
Rolland