Re: [DNA] High-level overview of DNA, take 2

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Thomas

Thanks for a clear and neat summary. Except a few minor points, I am
of the same opinion. Also I think that we'd better write down a bird's
eye view on DNA in some place.

> DNA takes the approach that upon reciept of a "link up" event, the
> most-recently used configuration information should continue to be
> used, and that DNA should be initiated to (quickly) determine whether
> one is attached to a new link, or one to which one has been previously
> attached.

I'd like to make a clarification. IMO, upon "link up" event,
though a host can keep the existing configuration information,
it should not use the information until DNA procedure confirms
that the host remains at the same link.

For example, a host can retain its current IP address but should not send
a packet with the address as a source address till DNA comletes.

We'd better make this clear and explcitly write it down.

> Some key questions for DNA.
>
> 1) when reusing "old" config, do we need to do anything special? E.g.,
>   change state of ND entries to STALE? Put addresses in Optimistic
>   state? Take into account how much time has elapsed since we were
>   last attached (or just assume this happens as part of normal ND
>   timers?)
>
>   What harm can occur from continuing to use the same information?
>   how does this compare with the harm of delaying the configuration
>   of an interface until one is more certain?

It may cause address conflict if a host continues to use the existing
'IP address' without DAD. While the host is away from the link, it's
possible that another node happens to configure the host's IP address,
because there was nobody to defend the address.

Also during the absence, a router/prefix may be removed from the link
with the RA/PIO with explicit indicaiton. Since the host didn't
receive the explict indication such as PIO with lifetime=0, it may
falsely assume that router/ prefix is still there.

> 2) Upon "link up", does DNA need to delay sending an RS per the
>   2461/2462 rule? Are there ways to relax this that are consistent
>   with the original concerns that led to the existing wording in
>   2461/2462?

I think 2461bis allows an immideate RS for mobile nodes.

> 3) Upon "link up", what messages can host send that would help it to
>   quickly determine if on same link? Is it just an RS? what about
>   unicast? what about an NS (e.g., perhaps including a Landmark
>   option)?
>
>   Are there other messages that can be sent that could help? Like NS
>   queries unicast to known routers?
>
>   Note: on some links, like wireless ethernet, multicast is
>   (relatively) "expensive". Would it be better to just send a few
>   immediate unicast NS (or RS) messages to the routers we know about?
>   and send a multicast RS only if the unicast fails? Or do both in
>   parallel?

With RS/ RA, I think DNA performs better in case of actual link change.

In case a host moves to a new link, it needs an RA for new
configuration anyway, so it seems reasonable to send RS in
anticipation of a link change. Also if you use unicast meessage to
known destinations, no reply will come when you have moved to a new
link. This will result in delay since you can't but rely on timeout to
detect a link change.

For your concern about multicast, I am happy to say that you may use
FRD (draft-ietf-dna-frd-01) to remove multicast packets entirely from
the air. :-) In brief, AP keeps a suitable RA and forward it to the
host upon a new attachment.

> 6) if DNA determines that was has reconnected to the same link, what
>   else needs to be done? Rerun DAD? Do nothing? Does the answer
>   depend on how long it has been since one was previously connected
>   to that link?

Right now, DAD seems to be the main problem but we may need to think this more.

> 7) Is there ever a time when one should discard still-valid prefix
>   information on a link? That is, suppose a bogus router shows up and
>   sends out an RA with prefix information with a long Lifetime. This
>   information may stay associated with a link for weeks, because no
>   router ever advertises the prefix with a Lifetime of 0. Pre-DNA,
>   that info would presumably get discarded more quickly because one
>   doesn't keep old LI information around. But with DNA, we may find
>   this happens and causes problems. For robustness, it seems like it
>   might be desirable to discard prefix information in the _absence_
>   of RAs containing that prefix, in the case where other RAs continue
>   to be received with other prefix information. I.e., if one knows
>   that one has missed (say) N RAs, time out the info if one is
>   receiving other info from other routers.  (note: the situation is
>   further aggrevated by having routers cache RAs learned from other
>   routers.)

This also needs more thoughts. Within Design Team, there were some
arguments over the dormant node awakening case. If a prefix is removed
while a node is dormant, upon awakening, the node mistakenly assume
the prefix is valid until it's lifetime, which may be quite long,
expires.

Thanks for your kind consideration.

Best Regards

JinHyeock