Subject: [magma] MLDv2: Exclude mode

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

There seems to be a significant inconsistency regarding
exclude mode. Section 5.2 has
       EXCLUDE (A)                B                   IS_IN (B-A)

Yet in section 4.2.12 the semantics of MODE_IS_INCLUDE is stated as
the listener is in include mode.

If there is a need to have a listener in exclude mode report an
include list of sources it would make sense to have that be a
separate report type (MODE_IS_EXCLUDE_WITH_INCLUDE_LIST or something
like that).

I've yet been unable to understand how the source timer works for
exclude mode.
Section 6.2.3 refers to the tables in 6.4 but I can't reverse engineer
the actual design from the rules in 6.4.
Is it possible to summarize these rules?

The text in 6.2.3 says:
   Source timers are treated differently when a router filter mode for a
   multicast address is EXCLUDE.  If a source record has a running timer
   it means that at least one system desires the source.  It should
   therefore be forwarded by some router on the network.  Appendix A
   describes the reasons for keeping state for sources that have been
   requested to be forwarded while in EXCLUDE state.
The above doesn't make sense since in exclude mode there isn't a source
record for every desired source. Instead there is a source record
(with timer=0) for every undesired source, right?
As I said elsewhere, having a separate include and exclude list
would make it easier to understand this.
But even with such a separation I can't understand how the exclude
list entries are managed - they are timed out when the multicast
address timer fires but are there other cases when they are removed?
There most be in order for the protocol to work.

   Erik

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

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 19 Feb 2003 15:43:20 +0100

> separate report type (MODE_IS_EXCLUDE_WITH_INCLUDE_LIST or something

Ok, that could be done. But the processing of such a report would be exactly
the same as the processing of the IS_IN report, as it is today.

Maybe trying to rephrase a bit the text of 4.2.12, would however be simpler,
than adding a new report type that has the same processing as an already
existing one. We will look at that.

> record for every desired source.

Yes, there is. More precisely, there is a list of sources that at least one
receiver has asked to receive EXPLICITELY (either by an IS_IN (A), Allow (A)
or TO_IN (A) report). These are the sources that have their source timers
running, and it is what you call the "include list".

> Instead there is a source record

Right, this is what you call the "exclude list". But this does not mean that
the union of these two lists includes all the possible sources. There are
sources that are not included in either of the lists. Those sources are
forwarded, while the router is in EXCLUDE mode.

Suppose for example that you have two receivers. The first is in INCLUDE
(A), the second is in EXCLUDE (B), with A and B being disjoint sets (to
simplify things). The router is in EXCLUDE (A, B)
Now let's consider a source S, that is not included either in A or in B. For
the moment, S is forwarded, as the receiver in EXCLUDE mode wants to receive
it (even if it did not requested it explicitely). If that receiver goes
away, the exclude timer expires, and the router switches in INCLUDE (A). The
source S will be blocked.

Again, neither of the receivers formulated explicit requests concerning
source S. That's why S was not included in either of the lists.

> There most be in order for the protocol to work.

No, the protocol works as is.
Sources from the exclude list are removed as specified in the tables from
6.4. There are two cases:

1. The last line from table 6.4.1.
   EXCLUDE (X,Y)     IS_EX (A)   EXCLUDE (A-Y, Y*A)  Delete (Y-A)
The router is sure only that sources from A*Y have to continue to be
blocked. Sources A-Y were allowed before (whether explicitely asked or not,
i.e. whether X*(A-Y) is void or not), and are asked to be blocked now. Thus,
they will make up the new "include list". Finally, sources from Y-A will be
deleted, as there's no more reason for them being kept on the router. They
should not be in the exclude list, as the host that sent the IS_EX(A) does
not ask for them being blocked. But definitely they should not be in the
include list either. So they are deleted.

2. The same case occurs in line 7 of table 6.4.2.
   EXCLUDE (X,Y)   TO_EX (A)      EXCLUDE (A-Y,Y*A)    Delete (Y-A)

The sources from the exclude list are also deleted during an Include mode
switch.

Thanks,
Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 19 Feb 2003 15:43:20 +0100

Thanks,
Rolland

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 17:06:49 +0100 (CET)

> the same as the processing of the IS_IN report, as it is today.

Could this be done by instead sending an ALLOW in response to the query?
(If so you'd have to change some other text which says that ALLOW
is only a state change.)

> existing one. We will look at that.

ok. Need to fix this inconsistently somehow.

> running, and it is what you call the "include list".

Based on me gradually understanding the protocol from this email
exchange it is no longer the "union of source list from
INCLUDE mode listeners" but instead "converges to the list of
sources which have been explicitly requested or responded to source
specific queries by INCLUDE and EXCLUDE mode listeners. For a time period
of MALI this list might be incorrect, but subject to robustness variable
it will be correct when the multicast address record on the router
is in INCLUDE state."

A bit longer than I had hoped for :-(

I still don't understand the other list. Is it as simple :-)
as "the intersection of all the listeners in EXCLUDE mode minus set A"?

> forwarded, while the router is in EXCLUDE mode.

Understood. (This is somehing else which belongs in the introductory material
in section 6.)

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 17:06:49 +0100 (CET)

Erik

---

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

> (If so you'd have to change some other text which says that ALLOW

At a first look, it seems that it could be done, as the treatment of both
allow and IS_IN messages is the same (in Tables 6.4.1 and 6.4.2). We should
think how to rephrase then the text.

> as "the intersection of all the listeners in EXCLUDE mode minus set A"?

I hope that my first e-mail that I've sent out today clarified this issue.

> Understood. (This is somehing else which belongs in the

Ok.

Rolland

---

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

Ok.

Rolland