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

[Erik Nordmark <erik.nordmark@sun.com>]

Thomas Narten wrote:

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

But an NS is ignored if the target doesn't match.
Are you talking about some hybrid between a RS and a NS which other 
routers can respond to immediately?

Or are you just trying to solve the case when the link-local address of 
the router isn't globally unique and that's why you want to add the 
landmark?

We want reasonable behavior both when the host has moved and when it 
stays on the same link.
In the case when it moves, dna-protocol* has explored the optimal 
solutions (a single RS and a single RA), and unless we have some clue 
from L2 the RS must be multicast to all-routers. (As Greg pointed out, 
this doesn't mean it needs to go everywhere.)

In the case when a host hasn't moved then (if one already know it didn't 
move ;-) then a unicast packet can be used to verify this.

But given that the host has to work efficiently whether it has moved or 
not, the choices are hard.
We could unicast 3 packets (and wait for 1 second after each) before 
sending the RS to all-routers. But that means that the case when the 
host moved now takes 3 more seconds.

We could send a RS to all-routers, which is fast in both cases, but 
causes extra traffic if multicast to all-routers isn't implemented 
efficiently in the network (MLD snooping?)

But there is no middle point: sending the RS to all-routers in parallel 
with the unicast NS doesn't reduce the multicast traffic.

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

We've discussed various ways, and I still think that the single landmark 
is simpler. But handling the case when a most might move between a link 
with DNA capable routers and a link without such routers (as well as 
links that have some of each) is tricky.

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

Because of the prefixes or something else?
These prefixes are only used for DNA; they do not effect the 2461/62 
operation.

The routers have to keep track of each other in any case to be able to 
have one of them immediately respond to an all-routers RS.

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

But that approach optimizes only for the case of non-movement. We need a 
balance that also optimizes for the case of movement.


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

I thought it was the 802.11 associate frames that were problematic on 
Monday's at the IETF ;-)

Seriously, it is hard to optimize for the case of flaky infrastructure 
(like IETF on Monday morning), and at the same time also optimize for
non-movement as well as movement.

I think that would be an over-constrained problem.

    Erik