Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay

From: Gregory Daley <[email-masked]>
Date: Sat, 07 Feb 2004 22:44:19 +1100

Hi Jari, 

----- Original Message -----
From: Jari Arkko <[email-masked]>
Date: Friday, February 6, 2004 10:42 pm
Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay

> Greg Daley wrote:
> 
> > I do not think we should be modifying every node to suit
> > MLD snooping, but it is possible to perhaps suggest
> > a random delay for _both_ the MLD report _and_ the DAD
> > NS (but no explicit delay between them). The DAD NS must
> > come after the MLD report though.
> 
> What is important here is to avoid the collisions. The collisions
> are avoided if there is some random delay before you start sending
> packets. Given that the protocols impose an ordering (MLD first and
> DAD after that), a delay in MLD will impose an equivalent delay
> in DAD.

That's sufficient.

> My conclusion is that the right thing is to update RFC 2710
> and require a delay. This removes collisions from both MLD
> and DAD.

I think that the problem there may be that RFC-2710 is 
being replaced by MLDv2.

The IPv6 node reqs document had a MUST for MLDv1, and
SHOULD for MLDv2 (last I saw).  This could lead to many
of the hosts exhibiting the colliding behaviour for MLDv1,
even if the changes go into MLDv2. 

Will we effectively need MLDv1(the second)?

> (We could still keep the requirement in 2462bis that if the DAD
> message is the first message to be sent then you should add
> a delay, but in that case we need to explain that if you
> follow the MLD spec then it never is the first message.)
>
> > In this case, the node could start listenting to the group
> > before sending an MLD report.  This is different to MLD/MLDv2,
> > but will not hurt, since the DAD NS is the principle
> > trigger for multicast traffic to that solicited nodes' address.
> > 
> > In snooping environments, the node wouldn't get any messages
> > to the group until the MLD report was sent.
> > In any case, it avoids the simultaneous transmission problem.
> 
> Listening before you send the MLD report is possible, but should
> be optional since, as you say, it does not always work.

Since you've not sent any packets on the link, it may not hurt
though...

Whether it's worth specifying here (listen before you're
a listener) is another matter.

Greg 

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

---

From: Jari Arkko <[email-masked]>
Date: Sat, 07 Feb 2004 18:44:34 +0200

>>DAD after that), a delay in MLD will impose an equivalent delay

Ok, so now we agree what needs to be done protocol wise, the
rest is just a documentation issue ;-)

> Will we effectively need MLDv1(the second)?

I see the problem. I do not have a strong opinion on which
document should explain what the correct behaviour is, as
long as the document boundaries do not force us to specify
suboptimal behaviour. For instance, if RFC 2462bis can explain
that the delay should actually be before the MLD packet, that
would be also sufficient. [If you think it sounds strange that
2462bis would be saying what to do for MLD, lets not forget
that MLD is invoked because 2462bis needs the multicast
listening service.]

--Jari

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 08 Feb 2004 22:20:03 +0900

>>>>> On Sat, 07 Feb 2004 22:44:19 +1100, 
>>>>> Gregory Daley <[email-masked]> said:

> even if the changes go into MLDv2. 

Actually, the latest node req document says SHOULD for MLDv2 and MAY
for MLDv1:

   Nodes that need to join multicast groups SHOULD implement MLDv2
   [MLDv2]. However, if the node has applications, which only need
   support for Any-Source Multicast [RFC3569], the node MAY implement
   MLDv1 [MLDv1] instead.
(draft-ietf-ipv6-node-requirements-07.txt, Section 4.6)

Unfortunately, MLDv2 is now in the RFC editor queue, and I'm afraid
it's too late to put this kind of change at this stage (even if we
agree that the change itself is a good idea).

Assuming neither MLDv1 nor MLDv2 can soon be updated, we'll have to
deal with the collision issue within rfc2462bis.  Possible options,
through discussions so far, are:

1. no change in rfc2462bis (expecting MLDv1 and/or MLDv2 will
   eventually be updated with a random delay)
2. the original proposal of mine (expecting MLDv1 and/or MLDv2 will
   eventually be updated with a random delay):
   impose a random delay even for the first NS after the corresponding
   MLD when the sending node knows there is no delay for the MLD.
3. Greg's suggestion:
   require a random delay before the first MLD (in rfc2462bis).

Now that we are updating rfc2462bis, I don't think option 1 should be
taken.  This way we'd just neglect an obvious problem while we have a
good chance to fix it.  The other options may require a change to
existing implementations, but I believe we can accept that.

Regarding option 2:
  pro: this can make DAD work if MLD-snooping switches are not used
  pro: we can keep the issue separate from the MLD specs (we do not
       have to worry about "spec-violation")
  con: MLD packets still collide, which also make DAD unworkable if
       MLD-snooping switches are used

Regarding option 3:
  pro: this is a complete solution of the problem, which works with
       MLD snooping switches
  con: this can be regarded as spec-violation, and we may have to
       worry about conflict with MLD updates in the future

I slightly prefer option 1, considering the deployment status of
MLD-snooping switches.  But it's not a strong opinion.  If others
prefer option 2 and the wg can agree on this, I'll follow the
decision.

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