Re: [DNA] draft-ietf-dna-cpl-02.txt

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

Thomas Narten wrote:

> A host should maintain IP configuration info about "previous links"
> that it has connected to. That is, for each "previous link", it
> maintains the list of default routers, list of prefixes, MTU info,
> etc., as well as any relevant lifetime info. When connecting to a link
> (any link), a node always assumes it is connecting to a "new" link and
> starts the normal 2461/2462 procedures. In _parallel_, it also
> attempts to determine whether it is connected to a link it has
> connected to previously. When it get back an RA containing a prefix,
> it looks for that prefix in its "previous links" cache, and if it
> finds a match, it assumes it is rejoining that link. It immediately
> uses the cached config information (after adjusting to take into
> consideration elapsed time) to configure its link. Note that normal
> 2461/2462 continues to operate in parallel, and any info learned there
> simply updates the (now) configured parameters.

I'm not sure the above description with "in parallel" captures the essence.

If/when the host receives an RA that indicates prefix overlap with the 
old attachment point, then it can declare that it hasn't moved at L3 and 
continue without any changes.

But until then, the host can't operate 2461/62 unchanged, because that 
would imply that information it receives for a potentially new/different 
link will be added to the 2461/62 conceptual data structures for the old 
link.

Also, DNA needs to be able to pick a point at which it will declare that 
is has moved at L3 and have that result in discarding the old 
information from the old link (old on-link prefixes, autoconfigured 
addresses, default routers, etc.) If DNA doesn't do that, then it 
doesn't help much since it will continue to use information from the old 
link.

The last item above has some impact on your other high-level comments.

>    Also, it seems to go to great lengths to cover all sorts of
>    boundary cases that I think are unlikely and I don't think are
>    worth worrying about. Remember, DNA is an optimization to speed
>    things up in the common case. And nothing breaks if DNA fails to
>    detect that a node has reconnected to the same link...

The issue of "discard old information" above does have the potential to 
break things compared to a non-DNA host today.
Today a host (that only follows 2461/62) will assume it has the same 
information until the information times out (with default timers ranging 
from hours to weeks).

If a DNA capable host, after detecting a change in L2 attachment point ( 
a link up event) erroneously decides that it has moved at L3, and as a 
result discards its autoconfigured IPv6 addresses, this might cause 
failures that are visible to applications. (The disappeared IPv6 
addresses might cause existing connections to fail, even if an RA 
arrives milliseconds later and recreates the disappeared IPv6 address.)

So your comments seem to be based on the assumption that existing IPv6 
stacks always discard all IPv6 addresses and other information when they 
are connected to a different L2 attachment point. That certainly isn't 
the case for the implementation I use. If we can resolve the above 
point, then we can see what makes sense with respect to simplifications 
to the draft.


> 2)
> 
>>    If the host implementation does not provide any link-layer event
>>    notifications [9], and in particular, a link UP notification, the
>>    host needs additional logic to try to decide whether a received RA
>>    applies to the "old" link or a "new" link.
> 
> IMO, we shouldn't bother with this case. Indeed, 2461/2462 don't have
> any text about this, and so to the degree that this is a problem for
> DNA, its also a problem generally. If anything needs to be said, it
> should simply be:
>     This document assumes that upon movement from one link to another,
>     a "link-up" event of some sort will be generated, so that the IP
>     layer is informed that a change of attachment point may have
>     occurred.
> 
> Most if not all of Section 5 could safely be deleted.

I also feel we don't need to worry about this case.
What do others in the WG think?

    Erik