Subject: [magma] MLDv2: editorial comments and questions

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

[Note that I'm still in xmit mode - making sure I type up all the comments
and questions before I read the responses so far]

Introduction:
-------------

Several of the unclear aspects (such as do the routers send periodic
general queries) below could be amelirotated by having an introduction
section which actually introduces the workings of the protocol.

It would be good if such a section presented this as well as
 - the fact that the routers do not track the membership of
   individual listeners (for scalability reasons)
 - the existence of state change reports as well as current status reports
 - the fact that there are 3 different types of v2 queries
 - the fact that a single (multicast) router on a link is
   elected the querier and it is the only node issuing queries
 - general queries are sent periodically 
 - mc addr and source specific queries are sent it response
   to detecting state changes in a listener
 - the workings of the "supress" flag would be useful to explain
   at a high level
 - the assumption about robustness and fast leaves
 - the fact that MLD operates independently for each interface - all
   state is per interface

Currently even with a good understanding of MLDv1 it is very hard to
read this specification and get a good grasp of the protocol.
In some cases it requires reverse engineering the overall operation
of the protocol from some minute detailed rules in the bowels of the spec.
This is not good.
Even a new reader (that has never read MLDv1) should be able to get an
overview of how the protocol works without having to read the defails.

Minor issues:
-------------

Section 2 has MUST requirements on the service interface for instance,
"MUST NOT be less than 64 addresses per list".
Why is it important for the protocol specification to place such
requirements on the API?
It seems out of place.

There seems to be a section in 4.1 about "source address for queries"
that is missing.
Presumably, as in draft-ietf-mld-source, the query must be sent with a 
link-local source thus an unspecified source is not allowed.
If not then the destination address rule in 4.1.14 would allow
off-link queries.

What is the motivation for 4.1.14 allowing unicast addresses?
When I read this and appendix A.2 I thought there was some new "fast leave"
scheme that involved targeting reports at individual nodes but there
is no such thing. If the query to unicast is useful for e.g. debugging it
would be good to say that in section 4.1.14.

4.2.13 says
	Routers MUST ignore a report with an unspecified source.
This requires a rule that hosts only send such reports for link-local groups
and some explanatory text in 4.1.13 that the purpose of such reports
is to make MLD snooping switches see that the host is interested
in the group. Otherwise the host can think it send a report
for some non-ll group while the router ignored that report.
Hence join latency before the host has assigned a link-local address
would suffer.

5.2 doesn't make it specific what happens when a node receives
a multicast address specific (or multicast address and source specific) 
query and the interface has no record for that group.
It seems to say to schedule the multicast address timer
but then not send the report when the timer fires. That seems suboptimal
unless there is something I don't understand here.
Is there a requirement that all queries (even for addresses which
the node is not interested in) be retained until the timer fires?
Is there some subtle ordering dependency that would make things fail
if the listener compared the source list when the query was received
it could report the wrong thing if its source list has changed while
the timer was running?

Section 6.2 specifies the "multicast address timer".
As far as I understand the semantics of this timer
is just the "exclude mode" timer. Or is its semantics more tricky
than that?

I think it would give a more comprehensible discussion if
section 6.2 specified a separate "include source list"
and "exclude source list" instead of having a single list and
interpreting its content based on the source timer.
An example of possible confusion shows up in 6.5 where it says
   source records.  Source records whose timers are zero (from the
   previous EXCLUDE mode) are deleted.
A source record could presumably have had its timer decrement to
zero and without it being an EXCLUDE source record
(yes, per section 6.2.3 such a source record should be removed,
but the delete might not be immediate.)
I realize this part of the protocol works even with this
confusion, but this is one more thing which makes the protocol
hard to understand.

The rules for when a source record as well as a multicast record
can be deleted is hidden in various rules e.g. in section 6.2.3.
It would be cleared to be able to say in one place
	A multicast record in include mode with an empty source
	list carries no semantic information hence it can be deleted.
	Thus any time a record transitions to this state it is deleted
	by the router.
and corresponding text for the source record.
That would simply the Actions/Comments in the state tables.

Section 6.2.2 says
         INCLUDE             Timer >= 0          All listeners in 
                                                 INCLUDE mode.
even though the text above says that the multicast address timer
is not used (presumably never set, decremented, or fires) in INCLUDE
mode. Thus it would make sense to say "Don't care" or "Not used"
instead of "Timer >= 0".

It would be much helpful if section 6.2.2 could say when the multicast address
timer is started/restarted.
I *think* this is each time a report is received in IS_EX or TO_EX state
but I can't find that (and which value it entered in the timer)
spelled out anywhere.

The table in section 6.2.3 looks inconsistent to me.
The two elements:
        INCLUDE            TIMER == 0        Suggest to stop forwarding
                                             traffic from source and
                                             remove source record. If
                                             there are no more source
                                             records, delete multicast
                                             address record      

        INCLUDE         No source element    Suggest to not forward
                                             traffic from source

Presumably the two above are the same. When the source timer
becomes zero in include mode, the individual source record can be
deleted. And when all source records are deleted the multicast
address record can be deleted. But the second item above does not state
"and delete multicast address record". Is this just an editorial
miss?

Furthermore section 6.2.3 has:
        EXCLUDE            TIMER == 0        Suggest to not forward
                                             traffic from source
                                             (DO NOT remove record)
Which record is not to be removed? The source address record or
the multicast address record?

Section 6.4.2 and 6.6.2 talk about "Querier state" but this state
on the router is never defined.
I understand that is it the result of the querier election
that sets the querier state, but I don't expect other readers
to be that good at reading between the lines.
Perhaps querier election and querier state should be defined early
in section 6 instead of towards the end i.e. move 6.6.2 earlier?

Section 6.6.1 and elsewhere talks about "Supress router-side processing flag".
The only motivation and high-level explanation of this flag is 
in appendix B:
   o The S flag (Suppress Router-Side Processing) is included in queries
     in order to fix robustness issues.
It would be useful for understanding if the issue and solution was
explained in more detail at the higher level. I feel like I'm reading
uncommented assembly code trying to deduct the programmers intent here!

Section 6.6.2 talks of a "lower IPv6 address". I suspect some more
detail would be useful - even for a 32 bit quantity we have byte-order
issues thus how to compare a 128 bit quantity as an integer might
be subject to different interpretations.

Section 6.6.2 reads as the elected querier sends general queries but other
routers might send other queries. I assume that the elected querier is the
only node sending queries. Is this correct?
If so it makes sense to append "as well as other queries." to the last
sentence in the first paragraph.

The second paragraph in 6.6.2 looks inconsistent with section 7.3.1.
The former says that the router should automatically switch to
MLDv1 queries if it hears a v1 query, but the latter talks about
this being adminstratively assurred. At a minimum this is rather confusing.
What should an implementation do?

The description of detecting an old router in 7.2.1 seems rather complex
and hard to read. I understand from section 8 that this is just
a case of 
	when an old query is received switch to old mode and (re)start
	a timer.
	if the timer fires switch to new mode
but I can't parse that from the text in 7.2.1.
(I suspect the complexity is a carry over from IGMPv3 which deals with
3 versions.) Saying "older" isn't needed - "v1" is more specific in
the case of MLDv2.
Same for section 7.3.2.

Section 9 says that the use of the unspecified source
address protects against off-link packets. This isn't true since
there is nothing in any IPv6 specification that says that routers
MUST NOT forward packets with an unspecified source address.
Thus the security considerations section should mention the issue
of how the protocol handles off-link reports with an unspecified
source address. (The fact that such reports are ignored by the router
means that this doesn't add any security hole - but the issue should
be explained and documented. MLD snooping switches might have a
security issue with off-link unspecified source reports though!)

Editorial nits:
---------------

Section 1 says:
   This document specifies Version 2 of MLD.  The previous version of
   MLD became an Internet Standard and is specified in [RFC 2710].  In
MLDv1 is a proposed standard and the above can be read as it being
a standard. How about dropping "became and Internet Standard and"?

Section 3.1:
   o If the requested filter mode is INCLUDE *and* the requested source
     list is empty, then the entry corresponding to the requested
     interface and multicast address is deleted if present.  If no
     such entry is present, the request is ignored.
I think "has no effect" is more accurate than "is ignored".
For instance, some particular API might chose to return an error
in such a case which doesn't sound like the request would be ignored.
I don't think this specification should preclude there from being such
an API.

Section 3.2 mostly talks about the interface state but it also
has this important note:
   but not on socket s2. Note that MLDv2 messages are not subject to
   source filtering and must always be processed by hosts and routers.
Shouldn't this be specified more visibly somewhere else?

Section 3.2 continues with
   Filtering of packets based upon a socket's multicast reception state
   is a new feature of this service interface.  The previous service
   interface described no filtering based upon multicast listening
   state; rather, a Start Listening operation on a socket simply caused
   the node to start to listen to a multicast address on the given
   interface, and packets sent to that multicast address could be
   delivered to all sockets whether they had started to listen or not.
The above doesn't match reality.
While filtering based on the socket isn't required by any IETF standard
(and I think requring it is the new thing) many implementations have
some form of filtering. In some cases it is simple as in unless
the socket has issued at least one add_membership type operation
it will not receive any multicast packets (even if other sockets
have joined the group). In other cases it might be full-fledged
filtering of groups per socket.
A possible fix is to just add "Requiring " before "Filtering of packets ...".

Section 4:
   link-local IPv6 Source Address (or the unspecified address, if the
   node has not yet acquired such an address), an IPv6 Hop Limit of 1,
It is the *interface* and not the *node* that needs to
have a link-local address assigned.
s/node/sending interface/
Same issue in section 4.2.13.

The document seems inconsistent on whether the unspecified address
can be used for v2 queries, but I think the intent is that
they only be allowed on v2 reports. If so it makes sense to
clarify the above sentence and also search for "unspecified"
and make the other text consistent.

Section 4.2.12 says:
       1    MODE_IS_INCLUDE - indicates that the interface has a filter
            mode of INCLUDE for the specified multicast address. The
            Source Address [i] fields in this Multicast Address Record
            contain the interface's source list for the specified
            multicast address, if it is non-empty.
This reads as if MODE_IS_INCLUDE reports are sent even if the
source address list is empty, but that is not the case AFAICT.
Thus it makes sense to clarify this to say that MODE_IS_INCLUDE
is never sent with an empty list.

Section 4.2.12 says:
   o A "Filter Mode Change Record" is sent by a node whenever a local
     invocation of IPv6MulticastListen causes a change of the filter
     mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to
     INCLUDE) of the interface-level state entry for a particular
     multicast address. The Record is included in a Report sent from the
     interface on which the change occurred.  The Record Type of a
     Filter Mode Change Record may be one of the following two values:
I makes it clear later, but it would be good to add
"whether or not the source list changes at the same time"
to the above.

Section 4.2.12 says:
   Unrecognized Record Type values MUST be silently ignored.

I assume this means more than just ignoring the type field when it
isn't recognized. The question is whether it means that the
whole report be ignored, or just the multicast address record
with the unrecognized type. Which one is it?

Section 5 says
   There are two types of events that trigger MLDv2 protocol actions on 
   an interface:
Presumably there is a set of timers that, when firing, trigger
MLD protocol actions as well.
It would make sense to list those timers here.

Changing this means it makes sense to add a section 5.3 about
interface timer firing and 5.4 about multicast address timer firing.

Section 5:
   (Received MLD messages of types other than Query are silently    
   ignored, except as required for interoperation with the earlier 
   version of MLD.)
Replace "earlier version of MLD" with MLDv1 and look
for other occurances of "version" where the same thing applies.
(I understand that this type of language makes sense for IGMP
since there are two earlier versions.)

Section 5.2:
   When a new Query with the Router Alert option arrives on an
The "router alert" is checked above.
Using the expression "valid query" throughout the section captures
the validity checks at the beginning of the section.

Section 6.2.2 says in the first paragraph
	kept per multicast address per attached link.
but the "per attached link" doesn't appear in section 6.2.3 for the
source timer which looks confusing.
It would be better to say
	kept per multicast address record.

Section 9.1:
Change "MLDv2 receivers" to "MLDv2 listeners".

Section 10.
It would make sense to ask the IANA to assign a *link local scope* multicast
address.
It would make sense to say ICMPv6 instead of ICMP in this section
as well.

The specification potentially introduces new name spaces.
At least the multicast address record type is such a name space.
It would make sense to state this in the IANA considerations section.
(I'm Assuming that the assignment of new types be restricted to standards 
action.)

Section A.2 #1 made me believe that routers in this protocol
would track membership per host which it clearly doesn't do.
And doing it per host doesn't seem to be an improvement.
For instance, asking a host whether it wants group X would 
still require a timeout since the listener does not respond to queries
for groups in which it is not interested.
So this argument is weak at best.
What could be done without host supression is for the router to
count the number of hosts interested in a particular group
(at least for include mode - haven't thought about exclude mode)
which makes it easier for the router to detect when it is likely
that the last listener has unsubscribed without having to query for
every leave.

Appendix A.2 #2 seems to have an odd conclusion as the last sentence.
Since MLDv2 mandates compatibility with MLDv1 and MLDv1 has host supression
Thus I don't see how the snooping switches can be made simpler by removing
anything at this point in time. In some future date when the v1 compatibility
is removed that might be the case.
A point that is missing is that in the precense of MLD snooping switches
the utility of host supression is zero. That coupled with #3 and #4
seems to make a strong case for removing host supression.
But #1 and the current #2 seems weak arguments at best.

Appendix B
Change "65,535 seconds" to either "65,535 milliseconds" or "65 seconds".

   Erik

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

---

From: "Rolland Vida" <[email-masked]>
Date: Tue, 18 Feb 2003 20:05:11 +0100

Erik,

> section which actually introduces the workings of the protocol.

Ok, if you think this is necessary, we can extend the introduction with a
short description of the protocol operation.

> Why is it important for the protocol specification to place such

These requirements are included in RFC3376 (IGMPv3) as well. So maybe Brad,
Bill, or Isidor could comment on this issue as well.

As for my opinion, section 2 states: "In order to take full advantage of the
capabilities of MLDv2, a node's IP service interface MUST support the
following operation: [...]". So the whole section is about API requirements.
If those are not met, MLDv2 cannot be supported. I do not see how could
MLDv2 operate with an API that limits the source list to 2 addresses for
example.

> There seems to be a section in 4.1 about "source address for queries"

In the first paragraph of section 4 it is stated:
   All MLDv2 messages described in this document MUST be sent with a
   link-local IPv6 Source Address (or the unspecified address, if the
   node has not yet acquired such an address).
There is a special section (4.2.13) about "source address for reports", as
MLDv2 hosts do not have a valid link-local address during the DAD (in the
case of mobile MLDv2 hosts that arrive on the link, for example). But in
order to execute the DAD, they must send MLDv2 reports. So in this case they
can use the :: address. We assumed that MLDv2 routers do not have this
problem.

But you are right, to further clarify the issue, we can introduce a "source
address for queries" section in 4.1

> would be good to say that in section 4.1.14.

ok.

> This requires a rule that hosts only send such reports for

4.2.13 says:
   An MLDv2 Report MUST be sent with a valid IPv6 link-local source
   address, or the unspecified address (::), if the node has not yet
   acquired a valid link-local address.  Routers MUST ignore a message
   that is not sent with a valid link-local address.
Thus, hosts should send reports with a valid link-local source address EVEN
FOR link-local groups. The unspecified address can be used ONLY when a valid
link-local address has not yet acquired, i.e., during the DAD.

> Otherwise the host can think it send a report

It is stated that all reports not sent with a valid link-local address MUST
be ignored by the router. Thus, the host is aware of it. Nevertheless, as
specified in the next paragraph of the draft, the DAD can still be executed,
as it does not require anything from the router. By sending out the report,
the MLDv2 host has modified its listening state, whether the router drops
the report or not.

> query and the interface has no record for that group.

The text says that:
   When a new Query with the Router Alert option arrives on an
   interface, provided the node has state to report, a delay for a
   response is randomly selected. [...]
So it seems obvious to me that if there's no state to report, then no report
is sent. But we can say this explicitly in a separate phrase, if you think
this makes the text easier to understand.

> but then not send the report when the timer fires.

No, it does not say that. If there's no state to report, then the host does
nothing.

> the node is not interested in) be retained until the timer fires?

No.

> it could report the wrong thing if its source list has changed while

There's no ordering dependency. No response is scheduled at all.

> is just the "exclude mode" timer. Or is its semantics more tricky

No, it could be called the "exclude mode" timer indeed.

> interpreting its content based on the source timer.

I agree we could do that. In that case we should specify explictely how and
when sources are deleted from one list, and pasted into the other. With the
timer mechanism, this is straightforward.

> zero and without it being an EXCLUDE source record

If a source record had its timer decrement to zero, then it is necessarily
an EXCLUDE source record. I explain.

There are two ways for a source to end up with a running timer in what you
call the "include list" of the EXCLUDE mode router.

Case 1.  It can be a source that someone in invlude mode specifically ask to
listen, while the router is in Exclude mode. Example:

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

As you can see, in this case sources from A are added in the "include list".
But the "exclude mode" timer (multicast address timer in the text) is not
updated.

Case 1.1.
Now, if there's no receiver in exclude mode that sends a report, the exclude
timer expires surely before the source timers for sources in A. Thus, when
the include mode switch occurs, all sources in A will have their timers
running.

Case 1.2.
On the other hand, if a receiver sends an exclude mode report before the
exclude timer expires, this will update the exclude timer. But in the
meantime, the sources from A will be deleted from the include list. See the
following example:

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

You can see that the entire "include list" (X) is deleted. Thus, there's no
question about these sources' timer being expired or not. As I said in my
previous e-mails, if there is, however, a receiver interested in those
sources deleted from the include list, its next report will update the list
accordingly.

Case 2. In all the other cases, a source ends up in the routers include list
(while the router is in exclude mode), because it is an EXCLUDE source
record for someone, and an INCLUDE record for someone else. If its timer
expires, it means that the INCLUDE mode receiver did not confirm its
interest in that source. Thus, it becomes an EXCLUDE source for all the
actual receivers, and it can be deleted without problems if the include mode
switch occurs.

I agree that the algorithm might seem complicated, but there are a large
number of different complicated scenarios (with different types of reports
that arrive in different orders) that all should be treated correctly. I
think that we managed to do that, and the algorithms works correctly.

On the other hand, the router state should be managed efficiently. It does
not seem acceptable to me to have huge lists of sources for each address
kept on the MLDv2 router, especially as we talk about long IPv6 addresses.
So if the algorithm can save router state, while still working correctly,
that seems to be an important point for me.

> but the delete might not be immediate.)

Section 6.2.3 states that in include mode, a source record with timer zero
is deleted immediately. In exclude mode, the delete is done when the include
mode switch occurs. there's no other reason to delay a delete.

> confusion, but this is one more thing which makes the protocol

At least I'm glad that you agree on its correctness. :-)

> That would simply the Actions/Comments in the state tables.

Section 6.2.3 is specially dedicated to the definition of the source timers.
Then the following section is specially dedicated to the corresponding
forwarding rules. It clearly states:
  Suggest to stop forwarding traffic from source and
  remove source record. If there are no more source
  records, delete multicast address record
We created separate sections for each problem exactly in order to make the
text esaier to read. It seems that we did not really succeed :-) So if you
think, we can paste the above phrase in 6.2.3. Nevertheless, I still have
doubts about this making the text more readable.

> mode. Thus it would make sense to say "Don't care" or "Not used"

Ok, I agree. we'll change it to "Not used"

> but I can't find that (and which value it entered in the timer)

section 6.2.2 states:
   Multicast address timers are updated according to the types of Multicast
   Address Records received.
Then, the handling of each type of multicast address record is presented in
details in the tables from dedicated sections 6.4.1 and 6.4.2. So you are
right, the timer is updated each time an IS_EX or TO_EX report is received,
as presented in the tables. It is also specified that the timer is set to
MALI (Multicast Address Listening Interval).

Then section 8.4 is dedicated to this value.

As a general comment, we have chosen to have separate sections dedicated to
separate problems, and to have one section refer to the other, rather than
trying to explain everything in the same place. As the algorithm and the
scenarios are quite complex, this seemed to be the nicer way to do things.
But we can add some further explanations in different section, even if it is
redundant with what is said already elsewhere, if this can make the text
easier to read.

> Presumably the two above are the same.

Not quite. The source list in include mode can become void not only by the
source timers expiring, but also by an include switch, from a router state
of EXCLUDE (void, Y). Then the router turns in INCLUDE (void) state, which
means that traffic should be blocked for that multicast address, no matter
the source.

I agree, however, that it does not seem to be interesting to keep such a
state on the router. By simply deleting the state from the router, multicast
subscription is cancelled, so the traffic will be stopped anyhow. Thus I
agree on deleting the multicast address record if this scenario occurs.

Any comment on this by the authors of IGMPv3.

> the multicast address record?

The "source" record. We can add this additional word.

> in section 6 instead of towards the end i.e. move 6.6.2 earlier?

Ok.

I'll come back with answers to the other issues you raised in the rest of
this e-mail tomorrow...
(just to say that I did not cut them out, without answering them ;-))

Thanks,
Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Tue, 18 Feb 2003 20:05:11 +0100

Erik,

ok.

4.2.13 says:

The text says that:

No.

Case 1.1.

Case 1.2.

section 6.2.2 states:

Ok.

Thanks,
Rolland

---

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

Erik,

Here is the follow-up with my comments on the rest of the issues...

> uncommented assembly code trying to deduct the programmers intent here!

Sections 4.1.7 and 6.6.1 explain how to handle a query, depending on whether
the S flag is set or not. Then, sections 6.6.3.1 and 6.6.3.2 show how to set
the flag while building a query.

As stated in appendix B, the S flag is necessary "to fix robustness issues".
When a multicast address specific or a multicast address and source specific
query is sent, several retransmissions of the query are scheduled (to assure
robustness). At the first transmission, the flag is clear, and timers are
lowered to LLQT. However, while waiting for the next scheduled queries to be
sent, the router might receive a report that updates the timers (setting the
multicast address timer or the source timers to MALI). The scheduled queries
still have to be sent, in order to assure for example that a non-querier
router keeps its state up to date with the current querier (it might not
receive the first query). Nevertheless, the timers should not be lowered
again to LLQT. Thus, in subsequent queries the S flag is set.

If you think it necessary, we could add such an explanation to the text.

> be subject to different interpretations.

Ok, we could add a phrase.

> only node sending queries. Is this correct?

Yes. The text says:
   MLDv2 elects a SINGLE router to be in Querier state per subnet [...]
   When a router receives a query with a lower IPv6 address, it sets the
   Other Querier Present timer to Other Querier Present Timeout and
   CEASES TO SEND QUERIES on the link if it was the previously elected
   querier.
We believed that by saying "ceases to send queries" it would be obvious that
we refer to all kind of queries.

> sentence in the first paragraph.

The last sentence you refer to is:
   After its Other Querier Present timer expires, it should
   begin sending General Queries.
This is correct, as when the timer expires, the new querier really starts to
send ONLY Geeneral Queries. These are the only queries sent periodically.
All the other queries are sent only in specific cases, as a reponse to
received reports. Thus, when the querier change occurs, only general queries
will be sent.
However, we could append your proposal, if this makes the text clearer.

> What should an implementation do?

6.6.2 says:
   If a router receives an older version query, it MUST use the older
   version of MLD on the link.
This does not say how the transition is done, whether it is automatical, or
administratively assured. On the other hand, it is said that details are
described in chapter 7.
Now section 7.3.1 says:
   If an older version of MLD is present on routers, the querier MUST
   use the lowest version of MLD present on the network.  This must be
   administratively assured; routers that desire to be compatible with
   MLDv1 MUST have a configuration option to act in MLDv1 mode.
Thus, here we state that the transition should be administratively assured,
as we did not succeed to come up with a consistent and correct mechanism to
do it automatically. After discussing the issue on the mailing list, it was
agreed that there's no reasonable scenario in which routers would
periodically pop up and dissappear on a specific link, as it might be the
case for the receivers. Thus, assuring the transition to be done by the
administrator is acceptable. In addition, this would filter out possible
attacks of malicious nodes sending out MLDv1 queries, and trying to switch
the link into MLDv1 mode.

Further down in section 7.3.1 it is stated:
  If a router is not explicitly configured to use MLDv1 and hears an
  MLDv1 General Query, it SHOULD log a warning.
This warning would alert the administrator, who could decide to configure
the MLDv1 mode or not.

However, you might be right saying that the sentence from 6.6.2 might be
confusing. We will try to rephrase it.

> 3 versions.) Saying "older" isn't needed - "v1" is more specific in

Ok, we can change "older" by v1. We just wanted to keep the same terminology
for timers as in IGMP, in order to ease a programmer's or a reader's life,
who is already familiar with IGMP. That's why we kept terms like "Older
Version Querier Present Timer" or "Older Version Host Present Timer" instead
of saying "v1 querier present" or "v1 host present"

> address protects against off-link packets.

This is taken out of its context. The entire prase is:
   The requirement that nodes verify that the IPv6 Source Address
   of all received MLD messages is a link-local address (or the
   unspecified address) defends them from acting on forged MLD messages
   originated off-link.
Thus, the necessity to have a link-local address is the thing that protects
against off-link packtes. I agree however, that we should probably treat the
case of the unspecified address in a separate phrase.

> This isn't true since

It is this specific MLDv2 draft that says that. As I said, I agree that
stating this in a separate phrase would probably make things clearer.

> MLD snooping switches might have a

As far as I see, snooping switches always stand behind an MLDv2 router. If
that router drops off-link unspecified source reports, I do not see how the
snooping switch could receive them.

Ok.

Ok.

> Shouldn't this be specified more visibly somewhere else?

Section 3.2 talks also about source filtering, based on the interface state.
Thus, I think that the phrase you refer to is included in the right place.
However, we could repeat it somewhere else in the text, maybe in the
enlarged introduction that you asked for, if this would make the text more
readable. We just have to be sure not to have an enlarged introduction of
tens of pages :-)

> A possible fix is to just add "Requiring " before "Filtering of

I'm OK with that.
But you should agree that we could not ask the reader to be aware of what
kind of undocumented tricks different implementors use in their products.
This is the first spec where this filtering is specified. That was what
motivated our formulation.

Ok.

> they only be allowed on v2 reports.

Right.

> If so it makes sense to

As I already stated in a previous e-mail, we could add a "source address for
queries" section in 4.1. This would clarify the issue.

Ok.

Ok.

> with the unrecognized type. Which one is it?

Just the specific record should be ignored. We should probably rephrase as
follows:
"Multicast Address Records with an unecognized Record Type value MUST be
silently ignored."

> It would make sense to list those timers here.

All the timers that might fire on an MLDv2 host are set in the first place
when a query is received. Thus, it is the reception of the query that
triggers the protocol action, and not the firing of the timer.

The corresponding protocol action is then described in detail. It includes
setting the timer, and executing a specific operation when the timer fires.

> interface timer firing and 5.4 about multicast address timer firing.

As I said, all these timers firing are just a part of the processing
triggered by the query reception. And all the corresponding actions are
already described in sections 5.1 and 5.2.

Ok.

Ok.

Ok.

Ok.

Ok.

Ok.

> would track membership per host which it clearly doesn't do.

it does not say that. It only says, that with MLDv1 it was not possible,
because of host suppression. In MLDv2, it becomes possible.

> And doing it per host doesn't seem to be an improvement.

We did not say that it must be done, but that it can be done. As far as I
know, several router vendors, e.g., Cisco, do implement explicit host
tracking.

> for groups in which it is not interested.

This spec does not specify explicit host tracking. Nevertheless, if you want
to do that, you can do it without modifying the protocol behavior. All the
reports and the queries are the same. Only that the routers, upon receiving
a report, memorize additional information too (e.g., host address).

> that the last listener has unsubscribed without having to query for

You cannot do that. You cannot count the number of hosts, if you do not
memorize their identity (address), as you cannot make the difference between
a retrannsmitted report (because of robustness) of an already known host,
and the first report of a new host.

But I underline once again that this document does not specify explicit host
tracking. We only said that with MLDv2 it becomes possible, if someone wants
to do it.

> is removed that might be the case.

The fact that we assure the compatibility with MLDv1 does not mean that we
will have MLDv1 hosts or routers in each and every part of the network. If
it would be the case, we would be always in MLDv1 compatibility mode, and
the MLDv2 protocol would never be used at its best.

Therefore, a scenario in which an MLDv2 snooping switch receives indeed an
MLDv2 report does not seem ackward to me. If the processing of this v2
packet is made simpler for the switch, then I think that this is a good
thing.

> the utility of host supression is zero.

Ok, we could add a specific phrase saying that.

> That coupled with #3 and #4

As I said, router vendors do implement explicit host tracking, at least in
IPv4. If they do it, I imagine that they have their reasons (fast leave,
security, accounting, whatever...). If this mechanism was made possible by
removing the host suppression, then I think that #1 is quite a strong
argument.

Ok.

Thanks,
Rolland

---

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

Erik,

Yes. The text says:

6.6.2 says:

Ok.

Ok.

I'm OK with that.

Ok.

Right.

Ok.

Ok.

Ok.

Ok.

Ok.

Ok.

Ok.

Ok.

Ok.

Thanks,
Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Thu, 20 Feb 2003 10:38:24 +0100

I forgot a comment.
 
> it does not say that. It only says, that with MLDv1 it was not 
> possible, because of host suppression. In MLDv2, it becomes possible.  

Actually, on page 24 (section 6) it is stated:
   Multicast routers need to know only that *at least one* node on an
   attached link is listening to packets for a particular multicast
   address from a particular source; a multicast router is not required 
   to keep track of the interests of each individual neighboring node.
   (Nevertheless, see Appendix A2 point 1 for discussion.)
This should clarify my point.

Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Thu, 20 Feb 2003 10:38:24 +0100

I forgot a comment.

Rolland

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 15:22:57 +0100 (CET)

> MLDv2 operate with an API that limits the source list to 2 addresses for

But where does the 64 magic number come from?
(I think I know the history behind the 64 - the number of bits in a hash

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 15:22:57 +0100 (CET)

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 15:54:52 +0100 (CET)

> MLDv2 operate with an API that limits the source list to 2 addresses for

MUST support at least 64 looks particularely odd since there
is no reasoning behind the magic number 64 AFAIK.

Also, MLDv2 presumably can't operate well on a node which can only join 2
groups per interface or per socket, yet there is no hard requirement on
those two limits.

> address for queries" section in 4.1

Thanks. Presumably that one can say the right thing regarding unspecified
source. And it makes sense to ensure that it and mld-source are consistent.

> link-local address has not yet acquired, i.e., during the DAD.

Thanks for the caps but I do know how to read and I've read
the whole MLDv2 spec twice during the last week.

The suggested behavior in the spec seems undesirable since a host
might decide to join a non-link local group immediately upon interface
initialization and naively send those reports with the unspecified source.
Such naive behavior will increase the join latency.
So either the routers should heed such reports, or they should be restricted
to link-local groups.

> be ignored by the router.

It would be quite reasonable for a host implementor to skip all parts
of the document which talks about router behavior. Thus the spec should make
the constraints on the host behavior clear without assuming what you propose.

> this makes the text easier to understand.

What does "no state" mean? I know that INCLUDE {} is the
same as "no state" but this might be less than obvious to the average
implementor.

> There's no ordering dependency. No response is scheduled at all.

Based on your response I don't think you understand my question.
This question is about the case when a report will be sent.

> timer mechanism, this is straightforward.

I suspect we don't have closure on comprehensible yet correct
definitions of the X and Y in EXCLUDE (X, Y) yet.
(But perhaps that is somewhere in my inbox.)
X is clearly not the union of all the listeners in INCLUDE mode
based on your discussion so far. 
Are you saying there is a way to make X and Y the include mode
and exclude mode source lists without any change to externally visible
behavior?

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

But in this case you don't know if the ALLOW is from
an exclude or include mode listener.
Thus calling it the "union of all the listeners in include mode"
isn't correct.

> At least I'm glad that you agree on its correctness. :-)

Of that part. The rest of it I still can't understand.

The problem with this is that if I as an implementor can't understand
the expected router behavior at some conceptual level all
I can do is to try to translate the rules in section 6 into code and
hope that it works. It is currently impossible for me to verify 
my implementation against the conceptual workings of the router because
I have no conceptual model - the specification failed to help me understand
the protocol. This is really really bad from the perspective of getting
specifications that are clear enough to provide a reasonable probability
that an implementation from the spec is correct and interoperable.

> doubts about this making the text more readable.

One problem is that you are attaching things to state transition arcs that
are really a function of the steady state.
For instance the forwarding behavior is a function of the steady state
e.g. INCLUDE {} (equivalent to no state) is an indication to not forward
the group. EXCLUDE {A} is an indication to forward all but A.
Separate from this steady state transition an implementation needs to
determine which groups to stop and start forwarding, but that is a trivial
diff of sets before and after a state transition.

> MALI (Multicast Address Listening Interval).

It would be quite helpful to try to have this type of description
as part of introducing the router behavior so that the reader/implementor
can gradually build a conceptual model of how this complex protocol
is supposed to work. Then the state tables can fill in the details.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 15:54:52 +0100 (CET)

Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 15:57:41 +0100 (CET)

[New subject]

> short description of the protocol operation.

I think both having more of a high-level introduction of the protocol in
section  1, and more of a gradually introduction to the workings of the
multicast router in section 6, are needed.

Having better ways to describe the state (data structures, timers, etc)
with their meaning is what is needed for section 6.

If I only could understand this part of the protocol I could have more
concrete suggestions.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 15:57:41 +0100 (CET)

[New subject]

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 16:56:19 +0100 (CET)

> If you think it necessary, we could add such an explanation to the text.

That would be great.
I don't know where it best belongs but it would be useful to be able
to read about this before seeing the S flag being used in the detailed
specification.

If the introduction goes into the fact that when there are multiple multicast 
routers one is elected to query but all routers listen to the messages
and maintain the same state (so that they can quickly take over should
the querier fail) then the above text (with the LLQT and MALI timers expanded
or replaced by approximate english text) would fit quite nicely.

> we refer to all kind of queries.

The text is only about a router that once was the querier. Does the case
of the router that never was a querier is not stated.
But a sentence or two in a protocol introduction would easily solve this.

> > sentence in the first paragraph.

Second though, this is odd.

A general statement about only the querier sending queries in the introduction
is better.

> administratively assured. On the other hand, it is said that details are

You are confusing adminstration and implementation.
To me 6.6.2 clearly says something about an implementation.
And it does not leave the door open for the implementation to have
an adminstrative knob to not follow the above MUST.

> the link into MLDv1 mode.

Then fix the text in 6.6.2 to merely refer to 7.3.1.

> confusing. We will try to rephrase it.

ok

> of saying "v1 querier present" or "v1 host present"

You seem to have missed my point that 7.2.1 can be replaced
with a few sentences which say:
	If the listener receives an MLDv1 query it switches to ...
	and (re)starts the "Older Version Querier Present" Timer.
	If this timer fires the listener switches back to ...
	The effect is that if the listener does not hear an MLDv1 query 
	during a "Older Version Querier Present Timer" interval it switches back
	to ...

Similarely for 7.3.1.

> snooping switch could receive them.

Right.
And presumably the required router alert would also prevent the
routers from forwarding MLD queries (and reports) from off-link sources
even if the source is unspecified. Thus it makes sense to bring 
router altert into the security considerations.

> readable. We just have to be sure not to have an enlarged introduction of

Yep - should try to make things succinct yet not inconsistent with the
details and fit it in 2-3 pages or something of that order of magnitude.

> motivated our formulation.

Understood.

> "Multicast Address Records with an unecognized Record Type value MUST be

also add "while the rest of the report is processed" or something of that
ilk.

> triggers the protocol action, and not the firing of the timer.

That doesn't match the implementation style that applies to these types of
protocols in the implementations I've seen - event based programming where 
received packets and timers firing form the set of events.

> setting the timer, and executing a specific operation when the timer fires.

But that style of description is either inexact or too complex because
there could be some other state change in the meantime that will change
what the action will be when the timer fires.
Take a source specific query for A,B.
When the query is received the node is interested in source A.
But when the report is generated based on the timer firing
the set of sources could be different.

Since the rest of the section 5 and 6 is just C code without the rigor
of actual C code, I don't understand why you don't want the timer
part of the structure match the structure of the most common implementation
strategy.

> because of host suppression. In MLDv2, it becomes possible.

No, because MLDv2 doesn't do that. It is possible in MLDv3 routers 
interoperating with MLDv2 listeners, but that is quite different than it
being possible in MLDv2.

> know, several router vendors, e.g., Cisco, do implement explicit host

Yes, but that is then a proprietary thing which fully interoperates
with MLDv2 listeners (and other MLDv2 routers) but the behavior of
such a router is different than the behavior specified in section 6
in this document.

So I don't have a problem with saying that the lack of host supression
makes it possible to implement either proprietary or future standard
behavior of multicast routers that tracks each host that is fully
interoperable with MLDv2 listeners and routers.

> to do that, you can do it without modifying the protocol behavior.

No. The behavior would not match section 6 in the spec.

> All the

Ack

> tracking. We only said that with MLDv2 it becomes possible, if someone wants

Agreed but it isn't "in MLDv2".

> packet is made simpler for the switch, then I think that this is a good

For the same reason that MLDv2 implementations are required to support
MLDv1 interoperability it would seem like an IETF standard (if there
will be a standard and not an informational document) for MLD snooping
switches would require the same.
Thus no code savings on the switch.

> removing the host suppression, then I think that #1 is quite a strong

Agreed if phrased better.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 16:56:19 +0100 (CET)

That would be great.

ok

Similarely for 7.3.1.

Right.

Understood.

Ack

   Erik

---

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

Ok.

Ok.

> But a sentence or two in a protocol introduction would easily solve this.

Each router starts to behave as a querier when it is switched on on a link.
Then, when it receives the first query with a lower IP source address, it
switches to non-querier state.

I agree that adding a phrase on this might clarify the text.

Ok.

Ok.

Right.

Ok.

Ok.

> part of the structure match the structure of the most common

The building and the updating of the reports that are sent, according to
other eventual queries that are received, or listening state changes that
occur before the timer fires, are described in section 5.2.

But we could rephrase that section, or we could introduce indeed a section
5.3 describing protocol  action triggered by timers firing, if that would
make the text more easy to read for an implementor.

> interoperable with MLDv2 listeners and routers.

Ok, we will rephrase it.

> Thus no code savings on the switch.

I agree that there's no code saving (the code that handles MLDv1 messages
should be included in the switch). But the handling of MLDv2 messages is
easier for the switch, if there's no host suppresion. So the MLDv2 part of
the code is simpler (than if we would have host suppression in MLDv2 too).
That's why we said "removing host suppression eases the job of the snooping
device". Maybe our statement should be rephrased to make it clearer.

Rolland

---

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

Ok.

Ok.

Ok.

Ok.

Right.

Ok.

Ok.

Ok, we will rephrase it.

Rolland