Re: [DNA] Model: how to treat "link down" events

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

> The above case may not be an abnormal case. The "Link UP" event
> needs to be processed even though it has been generated by
> the lower layer. This may take some time. It is not atomic in
> the sense that when the event happens,  no packets are allowed
> till the event is processed. Do you think that this case is
> a pathological case ?

My simple model assumes the whole IP layer (including Neighbor Discovery 
and DNA) is a single event-driven loop, i.e. the link up event and 
receives NS packets would be processed in the order the device driver 
passes them up.

If the implementation separates things, e.g., handling NS in the kernel 
and the 'link up' events in a daemon, then it needs to take care to 
preserve the ordering in this case.

I don't think using 'link down' helps here, because we have the common 
case of AP handover, where the change from using one AP to another is 
more or less instantaneous. Even if we mandate a 'link down' in that 
case, it would be immediately be followed by a 'link up', thus a split 
implementation would still need to handle the ordering issue.

I suspect it's not that hard to have a split implementation do the right 
thing. The 'link up' event can be used by the kernel to immediately set 
the optimistic DAD state, and then pass the event to the daemon that 
does DNA/RS/RA. That daemon will later tell the kernel when to turn off 
the optimistic state.

But it sure is worth-while to list this as an implementation 
consideration, in addition to making a clear statement about the 
ordering/atomic behavior of the host as a whole for this issue.

Do we put that in CPL or in draft-pentland? They both need the same thing.

    Erik