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

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Greg

> I don't think you should change the ND cache state unless the 2461
> timers indicate you should (Except if you're no longer on a link).
> It's an exposure of about 30 seconds (+DELAY+PROBE).
>
> With regard to addresses, even if you return to the same link, any
> period of absence is one where you may have missed a DAD NS
> (albeit with low probability).
>
> If you arrive back within a second, you would probably see the
> NA O=1 to all nodes from the node which started DAD while you were
> away.   Placing the addresses in Optimistic state makes sense here,
> but it may not be necessary to send an NS (opinions welcome).
>
> If you've been away for an entire second, the host may arrive back
> after DAD has completed on a peer node.  A full optimistic DAD would
> be required.

It make sense to differentiate host's behavior according to the time
of absence. The longer a host is absent, the more care it should take.
BTW how a host can measure its time of detachment? Shall this require
a precise link-down event notification?

> > 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?
>
> Please note that the main problem in DNA is when the host has moved.
> When the host has not moved, we don't really need to do much.
>
> Therefore the additional packet to check "are we here?" to a known
> destination doesn't help us achieve rapid change detection in the
> important case.
>
> When a host has moved, it is not possible to identify a unicast
> destination for a querying packet a-priori.

agree.

> This is why we've used multicast.   Perhaps there is a way for all
> links to have the same (MAC) unicast destination for a serving router,
> which would avoid the issue of the multicast RS leaking back onto a
> wireless LAN.  There are other ways of dealing with this issue
> today though (e.g. group filtering).
>
> Ideas like special destinations have been discussed previously off-list,
> but have the issue that they require modification to routers.
>
> RS/RA has the advantage that it is always there, and if people
> wish to improve its performance in scheduling or efficiency,
> it is possible to upgrade it (or potentially the network it is on??).

Kindly be aware that we can avoid multicast in the air with FRD. :-)

Thanks for your kind consideration.

Best Regards

JinHyeock