Subject: RE: [magma] MLDv2: operation without state change reports: periodic queries

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Mar 2003 16:32:16 +0100 (CET)

> Here is a proposal for an explanatory text about the router state. It could
> be introduced in the extended introduction we talked about, or in the first
> part of chapter 6 (describing router behavior)

Looks like a very good start. Some comments and questions below.

> *******
> A router is in INCLUDE mode for a specific multicast address on a given
> interface if all the listeners on the link interested in that address are in
> INCLUDE mode.  The router state is represented through the notation INCLUDE
> (A), where A is called the "Include List".  The Include List is the set of
> sources that one or more listeners on the link have requested to receive.
> All the sources from the Include List MUST be forwarded by the router.  Any
> other source that is not in the Include List MUST be blocked by the router.

The RFC 2119 language feels out of place here. The intent is to describe
how things are supposed to work and not prescribe behavior.
s/MUST/will/ makes it more natural.

> A source can be added to the current Include List, if a listener in INCLUDE
> mode sends an IS_IN, TO_IN or ALLOW report including that source.  Each
> source from the Include List is associated with a source timer, that is
> updated whenever a listener in INCLUDE mode sends a report confirming its
> interest in that specific source.  If the timer of a source from the Include
> List expires, the source will be deleted from the Include List.  The exact
> handling of the Include List, according to the received reports, is
> presented in details in Tables 6.4.1 and 6.4.2.

Comparing this to the group behavior in MLDv1 it looks a bit different.
When one node sends a v1 DONE the router will issue a short query to
see if anybody else is still interested in the group.
The corresponding behavior with respect to sources would be to send
a source specific query when in include mode and a BLOCK is received.
But I take it from the above description that that type of "fast leave"
is not part of MLDv2. Correct?

> A router is in EXCLUDE mode for a specific multicast address on a given
> interface if there is at least one listener in EXCLUDE mode, interested in
> that address on the link.  When the first IS_EX or TO_EX report is received
> from such a listener, the router sets the Multicast Address Timer
> corresponding to that address.  This Multicast Address Timer is reset each
> time an EXCLUDE mode listener confirms its listening state through an IS_EX
> or TO_EX report.  If the Multicast Address Timer expires, it means that
> there are no more listeners in EXCLUDE mode on the link.  In this case, the
> router switches back to INCLUDE mode for that multicast address.
> 
> When the router is in EXCLUDE mode, the router state is represented through
> the notation EXCLUDE (X, Y), where X is called the "Requested List" and Y is
> called the "Exclude List".  All the sources from the Exclude List MUST be
> blocked by the router.  On the other
> hand, both the sources from the Requested List, and the sources that are
> neither in the Requested List, nor the Exclude List, MUST be forwarded by
> the router. 

I don't understand - the sources in the requested list are forwarded,
right? The above doesn't say that.

> Nevertheless, the router has to maintain the Requested List for
> two reasons:
> 
> - To keep track of sources that listeners in INCLUDE mode listen to.  This
> is necessary in order to assure a seamless transition of the router to
> INCLUDE mode, when there will be no listener in EXCLUDE mode left.  This
> transition should not interrupt the flow of traffic to the listeners in
> INCLUDE mode still interested in that multicast address.  Therefore, at the
> moment of the transition, the Requested List should represent the set of
> sources that nodes in INCLUDE mode have explicitely requested.  When the
> router switches to INCLUDE mode, the sources in the Requested List are moved
> to the Include List, and the Exclude List is deleted.  Nevertheless, before
> the transition, while the Multicast Address Timer is still running, the
> router cannot be assured of having in its Requested List the exact list of
> the sources explicitely requested by listeners in INCLUDE mode.

It makes sense stating that before the switch the requested list can contains
an inexact guess at the sources from include mode listeners - might be too
large or too small but the protocol ensures that when a switch to include mode
happens it will be accurate.

>  For
> example, a TO_EX report received by the router might have been sent by a new
> listener in EXCLUDE mode, or by an old listener that previously was in
> INCLUDE mode, but it has changed now its filter mode.  Similarly, an IS_EX
> report received by the router might have been sent by an old listener in
> EXCLUDE mode, or by a listener that was previously in INCLUDE mode, but
> whose TO_EX state change reports have been lost.  In such cases, the
> Requested List is updated to *only* reflect the listening state of the
> reporting node (the only state the router is sure about).  Thus, sources
> might be deleted from the Requested List, as detailed in Tables 6.4.1 and
> 6.4.2.  Besides reflecting the only correct state the router can be sure
> about, deleting "doubtful" sources also reduces router state.  On the other
> hand, the Multicast Address Timer is refreshed by each IS_EX or TO_EX
> report.  Therefore, if there is indeed a listener in INCLUDE mode
> explicitely interested in sources that were deleted from the Requested List,
> it will have enough time to confirm its interest before the Multicast
> Address Timer expiration.  At that moment, the source is added again to the
> Requested List.  Thus, when the router switches back to INCLUDE mode, the
> Requested List will correctly reflect the listener state on the link.
> Details about the transition of the router to INCLUDE mode are presented in
> Appendix A3.

It might make sense to separate the above into a separate paragraph since
it is quite high-density.

> - To allow a fast blocking of previously unblocked sources.  If the router
> receives a report containing such a request, the concerned sources are added
> to the Requested List.  Their timers are set to Last Listener Query
> Interval, and a Multicast Address and Source Specific Query is sent: the
> router has to check if there are nodes on the link still interested in those
> sources, or not. If no node confirms its interest in receiving a specific
> source, the timer corresponding to that source expires. Then, the source is
> moved from the Requested
> List to the Exclude List.  From then on, the source will be blocked by the
> router.

Repeat of my question at the top: Does the fast blocking apply only in
exclude mode?

> The exact handling of the EXCLUDE mode router state, according to the
> received reports, is presented in details in Tables 6.4.1 and 6.4.2.
> ***********
> 
   Erik

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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Mar 2003 16:32:16 +0100 (CET)

Erik

---

From: "Rolland Vida" <[email-masked]>
Date: Tue, 11 Mar 2003 17:01:50 +0100

Erik, 

> The RFC 2119 language feels out of place here. The intent is 
> to describe how things are supposed to work and not prescribe 
> behavior. s/MUST/will/ makes it more natural.

Ok.

> Comparing this to the group behavior in MLDv1 it looks a bit 
> different. When one node sends a v1 DONE the router will 
> issue a short query to see if anybody else is still 
> interested in the group. The corresponding behavior with 
> respect to sources would be to send a source specific query 
> when in include mode and a BLOCK is received. But I take it 
> from the above description that that type of "fast leave" is 
> not part of MLDv2. Correct?

Actually the fast leave, by means of a Block message, does exist in
MLDv2. We should have mentioned it while describing how sources are
added to or deleted from the Include list.   

> > All the sources from the Exclude List MUST be blocked by the router.
On the other hand, both the sources from the Requested List, and the
sources that are neither in the Requested List, nor the Exclude List,
MUST be forwarded by the router.
>
> I don't understand - the sources in the requested list are 
> forwarded, right? The above doesn't say that.

Yes, sources from the Requested list are forwarded by the router. The
last sentence was intended say that. It might be clearer if we split the
phrase in two, as follows:
"All the sources from the Requested List must be forwarded by the
router. Sources that are neither in the Requested List, nor the Exclude
List, must also be forwarded by the router."

> It makes sense stating that before the switch the requested 
> list can contains an inexact guess at the sources from 
> include mode listeners - might be too large or too small but 
> the protocol ensures that when a switch to include mode 

Ok.

> It might make sense to separate the above into a separate 
> paragraph since it is quite high-density.

Ok.

> Repeat of my question at the top: Does the fast blocking 
> apply only in exclude mode?

As I said above, it applies also for the include mode. We should add it
to the text. 

Thanks,
Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Tue, 11 Mar 2003 17:01:50 +0100

Erik, 

Ok.

Ok.

Ok.

Thanks,
Rolland