[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[2462bis issue 597] multicast/MLD reference issues
(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" <elwynd@nortelnetworks.com> 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.
jinmei@isl.rdc.toshiba.co.jp
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------