Subject: [2462bis issue 597] multicast/MLD reference issues

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 19 Aug 2004 01:13:40 +0900

(The issue is now recorded at
https://rt.psg.com/ which can be viewed with login/passwd=ietf/ietf)

>>>>> On Mon, 16 Aug 2004 18:43:04 +0100, 
>>>>> "Elwyn Davies" <[email-masked]> said:

>> > s.5.4.2: In my comments on 2461bis I noted that the phrase 
>> 'join a multicast
>> > address' is not defined anywhere.  In 2462bis there is 
>> quite a lot of
>> > discussion of MLD joins but it would be useful to either 
>> define the term in
>> > the definitions or explain what it means at the top of 
>> 5.4.2 before suddenly
>> > starting talking about MLD.
>> 
>> We once discussed a similar point and rejected it.  I personally still
>> don't see the need for this, but if you strongly want to do something
>> on this, I think we could try to revise the paragraph in Section
>> 5.4.2 that talks about MLD.

I'm going to answer the "further thoughts" first:

> Two further thoughts here:
> - Ought to reference RFC3810 (MLDv2)in addition whereever RFC2710 is
> referenced at present (or as an alternative?)
> - Should interfaces resend the MLD Reports as soon as they get a valid
> address?
> - Should reference RFC3810 wherever 

(I guess the last bullet just meant the first one)

Regarding the first point: if my understanding of RFC3810 is correct,
MLDv2 should have the same issue.  (I must admit here that I'm not an
MLDv2 expert.  Please correct me if I'm wrong)

So, we should probably refer to RFC3810 as well.  Considering the fact
that the node-requirement document says MLDv2 is a SHOULD and MLDv1 is
a MAY, we might just refer to the later RFC.  But I personally think
referring to RFC2710 as well is helpful with the current deployment
status of these protocols.

Regarding the second point, we don't have to send the additional
reports at least if the node behaves as described in rfc2462bis.  In
any event, I believe such further considerations on MLD is beyond the
scope of rfc2462bis.

Coming back to the definition of 'join a multicast address':

> Suggest adding to the end of the first para of s.5.4.2:
>    For an interface to join a multicast address, it has to do two things:
>     o Configure the interface to receive packets sent to the multicast
> address
>     o Send an MLD Listener Report message for the address unless it is the
> all-nodes 
>       address [RFC2710], [RFC3810]

>    The interface has to use the unspecified address as the source address
> for the MLD 
>    Listener Report as it does not have an address when the message is sent.

As I said in our earlier message, the conclusion in a past discussion
was that it is an overspecification to provide the "definition of join
multicast" in rfc2462bis (I do not want to repeat one more cycle of
the same discussion...).  I appreciate your constructive suggestion,
but, based on the consensus, I'd reject adding the "definition" at the
beginning of this section.

If there is something we need to care about, it would be that the
current text may give an impression that it suddenly starts talking
about the MLD implication.  So, I'd like to propose a small
modification to the 5th paragraph of section 5.4.2:

   Note that when a node joins a multicast address, it typically sends
   a Multicast Listener Discovery (MLD) report message [RFC2710] for
   the multicast address.  In the above description, the delay for
   joining the multicast address thus means delaying transmission of
   the corresponding MLD report message [RFC2710].  Since [RFC2710]
   does not request a random delay to avoid race conditions, just
   delaying Neighbor Solicitation would cause congestion by the MLD
   report messages.  The congestion would then prevent MLD-snooping
   switches from working correctly, and, as a result, prevent
   Duplicate Address Detection from working.  The requirement to
   include the delay for the MLD report in this case avoids this
   scenario.  [RFC3590] also talks about some interaction issues
   between Duplicate Address Detection and MLD.

(We'll also add references to [RFC3810] if necessary)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Gerrit van Niekerk" <[email-masked]>
Date: Wed, 18 Aug 2004 20:18:27 +0200

> beginning of this section.

I raised this issue before and was not too happy with the concensus, but let it 
go. 

> modification to the 5th paragraph of section 5.4.2:

I support this modification; it also addresses my previous concern. I would 
just like to add a one-sentence motivation (which was my issue right from the 
start) and change the reference to RFC3590 to be more specific. Here is the 
slightly modified text: 

Note that when a node joins a multicast address, it typically sends a Multicast 
Listener Discovery (MLD) report message [RFC2710] for the multicast address. In 
the case of Duplicate Address Detection the MLD report message is required in 
order to inform MLD-snooping switches, rather than routers, to forward the 
multicast addresses. In the above description, the delay for joining the 
multicast address thus means delaying transmission of the corresponding MLD 
report message [RFC2710].  Since [RFC2710] does not request a random delay to 
avoid race conditions, just delaying Neighbor Solicitation would cause 
congestion by the MLD report messages.  The congestion would then prevent the 
MLD-snooping switches from working correctly, and, as a result, prevent 
Duplicate Address Detection from working.  The requirement to include the delay 
for the MLD report in this case avoids this scenario.  [RFC3590] specifies 
which source address should be used for the MLD report when no valid local 
addresses has yet been configured.  

> (We'll also add references to [RFC3810] if necessary)

===============================================
Gerrit van Niekerk
GP van Niekerk Ondernemings BK
Roosstraat 211, Meyerspark, 0184, South Africa
Tel: +27(12)8036501 Fax: +27(12)8034131
Email: [email-masked], [email-masked]
Web: http://www.gpvno.co.za
===============================================

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 19 Aug 2004 17:14:30 +0900

>>>>> On Wed, 18 Aug 2004 20:18:27 +0200, 
>>>>> "Gerrit van Niekerk" <[email-masked]> said:

> start) and change the reference to RFC3590 to be more specific. Here is the 

Your suggestion looks basically fine, but I want to check one minor
point:

> multicast addresses.

Do you really mean "forward the multicast addresses"?  I'd say, e.g.,
"to forward packets to the multicast address".

> In the above description, the delay for joining the 

					JINMEI, Tatuya

---

From: "Gerrit van Niekerk" <[email-masked]>
Date: Thu, 19 Aug 2004 18:50:06 +0200

On 19 Aug 2004 at 17:14, B wrote:

> > Note that when a node joins a multicast address, it typically sends a
> > Multicast Listener Discovery (MLD) report message [RFC2710] for the multicast
> > address. In the case of Duplicate Address Detection the MLD report message is
> > required in order to inform MLD-snooping switches, rather than routers, to
> > forward the multicast addresses.
> 

No, I don't :) How about this:

..., to forward packets containing the multicast address to the node.

Or simply:

.., to forward multicast packets.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 20 Aug 2004 23:52:24 +0900

>>>>> On Thu, 19 Aug 2004 18:50:06 +0200, 

> .., to forward multicast packets.

I'd prefer the latter, which is much simpler and contains enough
information in this context.

Thanks,

					JINMEI, Tatuya