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

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

To try to comprehend this complex protocol I first tried to understand
how things work when the link is broken while a bunch of listeners change state
(so that all state change reports are lost) and then the link starts working
to see how the router build state from the IS_IN and IS_EX messages only.

Looking at the INCLUDE case (the router is in INCLUDE state and so is
all the LISTENERS), then the EXCLUDE case, and finally the mixed case
I'm utterly confused.

Part of the confusion is due to the definition of the source lists A and B
in section 6.4.1.

I interpret (A) to mean that this is the list of sources that listeners
in INCLUDE state have reported. That interpretation seems consistent with the
text in appendix A.3 (keep the source list for those in INCLUDE state
so that it is quick to switch to INCLUDE state on the router when the
last EXCLUDE listener goes away).

But that seems inconsistent with the rules in the tables in in the mixed case.
Section 6.4.1:
    INCLUDE (A)       IS_EX (B)     EXCLUDE (A*B, B-A)

This modifies A to A*B even though there is no change in the 
source list for any of the listeners in INCLUDE state.
Should be EXCLUDE (A, B-A) to be consistent.

    EXCLUDE (X,Y)     IS_EX (A)     EXCLUDE (A-Y, Y*A) (A-X-Y)=MALI 

This changes X to A-Y, even though there is no change in the
source list for any of the listeners in INCLUDE state.
Should be EXCLUDE(X, Y*A) to be consistent.

Section 6.4.2
   INCLUDE (A)     TO_EX (B)      EXCLUDE (A*B,B-A)    (B-A)=0

This changes A to A*B even though there is no change in the 
source list for any of the listeners in INCLUDE state.
Should be EXCLUDE (A, B-A) to be consistent.

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

This is OK *if* the ALLOW was sent by a listener in INCLUDE
state if sent by a listener in EXCLUDE state the result
should be EXCLUDE (X, ...).

   EXCLUDE (X,Y)   TO_EX (A)      EXCLUDE (A-Y,Y*A)    (A-X-Y)=Multicast

This changes X to A-Y even though there is no change in the 
source list for any of the listeners in INCLUDE state.
Should be EXCLUDE (X, Y*A) to be consistent.

The next to last example above points out that in order to maintain the
source list for the listeners in INCLUDE state properly it is necessary
that the ALLOW message indicate whether the sender is in INCLUDE or EXCLUDE
state which seems impossible in the current packet format and sending rules.

It seems like the definition of set (A) in 6.4.1 has somehow evolved
from being the union of the source list from all listeners in INCLUDE
state, to being a list of sources that are explicitly ALLOWed.
But with that definition it is no longer possible to use this
list for rapid and correct change from EXCLUDE to INCLUDE state
on the router when the last EXCLUDE listener goes away.

Did I misunderstand something?

  Erik

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 21:26:43 +0100 (CET)

> The draft defines X as:
>   Sources that at least one node has requested to be forwarded
> As explained above, X represents the union of the source lists of INCLUDE
> listeners only when the include switch occurs.

The text in the draft doesn't have your added sentence. But even with
that sentence the definition isn't very helpful since it only specifies the 
semantics at one point in time. What does the variable contain
e.g. when the router is in EXCLUDE mode?

> The draft defines also Y:
>   Sources that MLD will suggest to the routing protocol not to forward
> This means that sources from Y were asked to be blocked by all the listeners
> on the link.

Yes, but that isn't a definition which helps create a mental model
of how the protocol maintains Y; it is an explanation of how the result
is used.

Your added sentence isn't completely accurate either - if IS_EX {} issued 
by a listener the list to be blocked is not maintained in Y - the fact 
that no sources should be blocked is captured in the EXCLUDE state 
at the router.

Is Y always the intersection of the IS_EX, TO_EX, and BLOCK that have been
received in the last MALI interval?

> You mean changing X and Y to "include list" and "exclude list"?

I mean changing them to names that are descriptive so
that the running text can use descriptive names. The state tables
can continue to use X,Y.
But unfortuntately include and exclude matched by incorrect mental
model of the protocol. So those names
might not actually fit the actual protocol.

> But you are probably right that we could make the text clearer by defining
> separately the roles of the source lists when in include or in exclude mode.
> The following paragraph should then be rephrased/replaced:
>    Note that there will be two sets only when a router's filter mode for
>    a multicast address is EXCLUDE.  When the filter mode is INCLUDE, a
>    single set is used to describe the set of sources requested to be
>    forwarded (e.g. simply ( A ) ).

and add "since the "exclude" set is empty."

> > You seem to be saying that X will over time converge towards the union
> > of the INCLUDE mode listeners but at any given time
> > it might have more as well as less members than this union.
> 
> Right.
> 
> > And though some (to me incomprehensible) dependency
> > on time constants the fact that X in some cases is less than this union
> > will not cause the protocol to fail.
> 
> Right.
> 
> 
> > What is the definition of Y?
> 
> I specified it above.

You specified its use.
There is a difference between
	Source IPv4 address: 32 bit number. The IP address of the sending node.
and
	Source IPv4 address: the address to which routers send ICMP errors
	and to which the peers respond (e.g. responses to TCP SYNs).
I call the first a definition.

> You agreed that the protocol functions correctly. 

Misquote. I agree to "that part seems to work".
(for whatever "that" we were discussing.)

Most of the stuff in section 6 I still don't understand and would with
high probability not be able to implement correctly from the spec.

> There are already several
> implementations of it up and running (LIP6, KAME, Cisco?). Now if i would be
> a router vendor, and there would be an algorithm that functions correctly,
> is of the same complexity (in number of operations) as another algorithm,
> but it significantly reduces router state, I would buy it, even if it is
> hard to understand why is a list set to A and not to B.
> 
> As I said, by using the mechanism proposed by the protocol, router state is
> reduced with A-B IPv6 addresses. This is done during MALI, i.e. 2*125+10 =
> 260 seconds by default. So I can reduce router state for more than 4
> minutes, with maybe tens of IPv6 source addresses, for each multicast
> address that has listeners on the link.

Presumably the router needs memory for worst-case and not best-case.
Btu in any case I don't see what this has to do with the inability of
the specification to explain how the protocol is supposed to work
so it can be implemented from the spec.

> Again, it is a tradeoff between router state and temporary inconsistency, if
> you wish. But that temporary inconsistency with the common understanding of
> what a source set should represent does not affect in any way the
> correctness of the protocol.

It might be correct - I just can't tell. And I can't implement it.

> The point is that the router knows nothing about whether the listener who
> sent the Allow (A) is in Include or Exclude mode. Thus, it cannot handle the
> two cases separately.

Yes, but why is the protocol designed so that the router doesn't know?
I think there is a rather fundamental difference between a listener
in include mode adding a desired source and a listener in exclude mode
removing an undesired source from its source list.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 21:26:43 +0100 (CET)

You specified its use.

    Erik