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

[Brian Haberman <brian at innovationslab.net>]

Hi Greg,

Greg Daley wrote:

> Hi Brian,
>
> Brian Haberman wrote:
>
> > I don't like the idea of a random delay in the MLD Reports.  As I
> > said in another note, it either adversely affects the logic in the
> > MLD specs or causes application delays for non-LL groups.
> >
> > Is having a delay in the NS transmission alone sufficient?  So that
> > the Report is sent immediately and the NS is delayed.
> >
> > Regards,
> > Brian
>
> I think what Jari asked was not a modification to the semantics
> of reporting group joins.
>
> I think that what Jari proposed was actually that we delay DAD
> (which entails both the operation of beginning listening to
> a group and the NS transmission).
So, in logic-wise it would look like:

    1. Generate the solicited-node multicast address
    2. Wait for random timer expiry
    3. Perform ADD_MEMBERSHIP call on the socket
    4. Send DAD

I think I can live with that for the time being.

> To put it another way, we don't actually configure the address
> until the random delay timer has expired.  The delay's expiration
> is a precondition for address configuration, in this case.
>
> In this way, joining the group occurs when the group is first
> listened to (in accordance with MLDvX) and the NS transmission is
> similarly delayed.
OK.

> Delaying only the NS is insufficient, as the statement in RFC-2462
> is for two purposes:
>
> 1. Increased reliability of DAD NS tranmission.
>
> 2. Protection of the link against packet storms.
>
> Relying only on the MLD report replay mechanisms only achieves
> the first of these goals, and not the second, since the MLD
> transmissions may be synchronized for the first report.
>
> Delaying both provides superior protection of the link, and
> gains the same reliability mechanisms already available without
> requiring change to the MLD specifications.
Given the above proposal, I can accept this approach.  It isolates
the delay to NDP rather than affecting all users of MLD.

Regards,
Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------