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

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

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

Agreed.

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

Hmm. One thing missing here is the high-level description of expected
behavior when a link goes "down" and then "comes back up". 2461/2462
(to the degree I recall) doesn't say a lot, but if it does say
anything, the implication is probably to "discard all information when
the link goes away" and "start fresh when a link comes up", which I
agree is not really what we want in practice.

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

Right. Though in the DNA context, "discard" probably needs more
description. We don't want the info assigned to the interface
anymore. But do we actually want all upper-layer uses of those
addresses to now explicitely fail? Or is it OK to allow continued use
(even if it doesn't really work) so that if we reconnect to the link
later, upper-layer applications may still recover (using the old
addresses)? I think there may be pros and cons to both sides on this
point.


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

Is this just what implementations do, or is this supported (or even
called for) in 2461/2462 (or other specs)?

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

Yep. I agree that this is probably not what we want.

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

That wasn't my intent.

But, this discussion is good. As I read through some of the other
documents I kept coming back to "what  is the abstract model"
governing the behavior we want?

I will step back and try to describe that as well, as I think it's
helpful to understand/clarify at an abstract level what the principles
are and how we think things should work. From that, it's a lot easier
to dive into details.

Thomas