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

From: Erik Nordmark <[email-masked]>
Date: Sun, 16 Mar 2003 19:38:53 +0100 (CET)

> > 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.

I think it would be helpful to use a more formal way to express
this in the table where the timer actions are described
instead of the informal "Suggest to not forward traffic from source"
akin to the formalism used in the other state tables.

I also points out a high level point for the request list which
I have completely missed until now. The request list serves as some form
of holding pen for EXCLUDE mode increase in the set of blocked sources;
when the entries time out they are moved to the exclude list.

> 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.

Agreed this is ok. I'm mostly just trying to understand.

   Erik

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

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 16 Mar 2003 19:38:53 +0100 (CET)

Erik