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

[Thomas Narten <narten@us.ibm.com>]

> \>    Are there other messages that can be sent that could help? Like NS
> >    queries unicast to known routers?

> This is what DNAv4 does (via unicast ARP), because this enables a 
> determination of whether the host has connected to a previously encountered 
> router, without ambiguity.

Indeed, the DNAv4 approach is what led me to ask that question.

DNAv4 uses ARP. Shouldn't we think about using an NS? It's unicast,
and already includes the "R" bit, so we know whether the node is a
default router or not. Perhaps it make sense to add some options that
benefit DNA. (The same options could be used in RSs too, if that makes
sense.)

One issue that seems to be carrying a lot of weight on the DNAv6 side
is that with RS/RAs, one (only) learns the router's link-local and
link-layer addresses. But these two together are insufficient to
uniquely identify a link, since both can be used on different links at
the same time.

Why not allow inclusion of a landmark option in an NS/NA? One benefit
of an NS is that we presumably don't have to delay sending one, and
the responder doesn't delay in responding. So this can be very fast.

Another thought I have. When one gets a "link up" event, one wants to
know if one is reattaching to a previously known link. The
pentland-protocol3 draft assumes that the best way do do that is by
including all prefixes in RAs.

However, this has the disadvantage that routers have to listen to
other RAs and (effectively) do a proxy advertisement for prefixes it
itself is not advertising. I have some fairly strong qualms about that
approach...

On the other hand, a lower overhead mechanism would be to be able to
ask "are you the same router on link Foo that I was talking to
previously?" If the answer is yes, one can conclude that one is on the
same link as earlier. One way to do this might be to define a new
option, called (say) the Link/Interface Identifier option, that serves
as a sort of globally unique identifer for an interface on a specific
link. The router could generate the identifier by (say) hashing its
link-local address, internal serial number, internal interface
identifier, and time of reboot. The idea is that even if a router used
the same LL address (and link-layer address) on multiple interfaces,
the Link/Interface Identifier would be different on the different
interfaces.

One benefit of an approach like this is that a router can generate the
identifier using only local information, without coordinating with
other routers.

A host could then (say) send an NS, and ask the responder to include
that Link/Interface Identifier option.

> >    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?

> DNAv4 does both DHCP and DNA in parallel.  DNAv4 is handled solely via 
> unicast ARP, because on some links multicast not only is sent to many more 
> hosts, but also is sent at much lower  rate.   For example, with IEEE 
> 802.11n, it would be possible to send *a hundred*  unicast packets at 100 
> Mbps at the same cost in expended slots as  one multicast packet at 1 Mbps.  
> This means that in practice a single multicast RS will cost more than 
> sending unicast RS or NS messages to all previous routers.

I'm also a bit worried that one time DNA will get used a lot is at,
say, IETFs where the network is barely functioning. That seems like
the wrong time to have a bunch of nodes invoke DNA at the same time
and all send out multicast RSs...

Thomas