Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt

[Jari Arkko <jari.arkko@kolumbus.fi>]

Hi Christian,

and thanks for writing this draft. Some comments:

Technical:

>    o  MN sends a RS with a TSLLAO from the unspecified address.
>    o  MN receives an IPv6-multicast RA by link-layer unicast.
>    o  MN sends a MLD Report for an optimistic address.
>    o  MN send a NS for the optimistic address, initiating ODAD.
>
>    The RS (step 1) may be sent immediately, even though this is the
>    first message transmitted after (re-) enabling the interface RFC
>    2461bis.
>
>    From a standard's perspective, it is debatable whether or not the MLD
>    Report must be delayed.  RFC 2462bis says in section 5.4.2:

My belief is that the original delays in IPv6 specifications were
written in order to avoid broadcast storms and other similar
problems that might occur when, for instance, the electricity
is turned on for a large set of nodes after a power failure. Similarly,
this can address (in some cases) the wireless movement patterns
such as a bus load of people coming to the range of a cell at the
same time.

But I get worried if its followed blindly, such as in the above
scenario where other messages precede MLD signaling anyway.
Basically, I believe we need to look at the problem as a whole,
and build in safeguards that prevent packet storms. But once they
exist in a given situation, that should be sufficient and neither
ND nor MLD delays should be needed. Here's what RFC 3775 said
about the matter:

   The Mobile
   Node SHOULD delay according to the mechanisms specified in RFC 2462
   unless the implementation has a behavior that desynchronizes the
   steps that happen before the DAD in the case that multiple nodes
   experience handover at the same time.  Such desynchronizing behaviors
   might be due to random delays in the L2 protocols or device drivers,
   or due to the movement detection mechanism that is used.

>    It hence seems feasible to eliminate the backoff for MLD Reports when
>    applied after IPv6 relocation.  In particular, both of the following
>    two conditions would have to be met:
>
>    1.  The mobile node has received a trigger from its local link layer
>        indicating that interface reattachment has taken place.
>    2.  The MLD Report is either the first message transmitted on the new
>        link or it is sent in response to a unicast RA indicating IPv6
>        relocation.

What does "reattachment" mean, exactly? I believe you mean that
an interface which was previously operational has gone down and has
now come up again. But the text should be clear about this, to
avoid confusion with re-attaching to the same link that you have
previously visited.

Also, I find it curious that your conditions above don't call for
the same de-sync knowledge as the RFC 3775 text did. I'm not sure
if it is needed, just pointing out the difference...

Editorial:

>    Mobile nodes require fast IPv6 relocation.  Yet, router discovery,
>    address auto-configuration, and support for TSLLAOs depend on delayed
>    MLD signaling, defeating existing optimizations in many situations.
>
>    This document identifies problematic situations.  It proposes delay
>    relaxations for MLD Reports or use of optimistic addresses prior to
>    the initial Neighbor Solicitation to improve them.

Remove acronyms from the abstract (TSLLAO, MLD). What's
"relocation"? Maybe write the abstract as

  As mobile nodes move to new links, they need to resume their
  communications in a timely fashion. To communicate, IPv6 nodes need
  to complete router discovery, address auto-configuration, and
  other tasks. Unfortunately, many of these tasks depend on prior
  completion of the Multicast Listener Discovery (MLD) protocol,
  which introduces a mandatory delay of up to a second. This
  document discusses where this can be problematic and proposes
  some solutions that can alleviate the problem.

>    relocation delays indentified in section 2.

s/indentified/identified/

>    IPv6 Neighbor Discovery [1] accellerates router discovery in that it

My speller doesn't like the fourth word. Maybe "IPv6 ND [1]
allows mobile nodes to forego ..."

>    accelleration for this, defeating the benefits of the afore-mentioned

Same here. Maybe write it simpler as "... can currently not be optimized
away, defeating ..."

>    Both of the following two approaches can eliminate the high IPv6
>    relocation delays indentified in section 2.

There's three subsections following this.

--Jari