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

From: Thomas Narten <[email-masked]>
Date: Mon, 30 Jan 2006 15:57:17 -0500

I have some questions/comments/concerns on this draft.

General: I think the overall direction of this draft is OK (i.e.,
using prefixes to identify links), but I have some concerns about the
specifics of what is described in this document.

First, if I understand correctly, this is roughly what I think this
document should be doing:

Summary:

This document assume routers implement RFC 2461/2462 and have not been
upgraded with any DNA extensions. In addition, we assume that a node
may move back-and-forth between networks it has previously
visited. This could be be due to movement among a small set of links,
or because of network "hiccups" that cause one to momentarily loose
connectivity and then (re)connect to the same link again. This
document describes how a host keeps configuration information about
the links it has previously visited, attempting to reuse pre-existing
configuration information (when it is safe to do so) rather than wait
for the longer delay of going through the normal configuration steps.

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.

The above seems fairly straightforward to implement/understand. 

But, the current document includes a number of things that I am not
sure are needed at all, and some that I think are backwards.

1) the document is rather long and verbose. I actually find the text
   somewhat hard to follow, since the discussions seems fairly lengthy
   given what I understand to be a fairly simple algorithm.

   For example, it talks about numbers of times to transmit things,
   etc. I think this is all covered in 2461/2462 and shouldn't be
   mentioned here (I find it confusing to read about it because I'm
   not sure what is "new" to DNA vs. what is just being taken from
   other documents and should already be existing practice).

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

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.

3) The entire discussion/text surrounding building a "complete prefix
    list" seems unnecessary and from what I can tell, doesn't really
    matter. That is, if you go back to the summary algorithm at the
    top, it doesn't matter whether a node has a "complete prefix list"
    or not; the algorithm works the same in either case. If you get a
    prefix in an RA, and it matches one in your cache, voila, you have
    found a link you were previously connected to. I don't see why it
    matters whether you are 90% certain you have a complete prefix
    list or not.

    I wonder if all of section 3.1 could be removed.

4)  3.2  Erroneous Prefix Lists

>    The host may generate either 1) the Incomplete Prefix List, i.e. the
>    prefix list that does not include all the prefixes that are assigned
>    to the link or 2) the Superfluous Prefix List, i.e. the prefix list
>    that contains some prefix that is not assigned to the link.

How does this happen? why should we worry about this case? 2461/2462
doesn't...

5)

>    If the host is not sure that the prefix list was complete before the
>    hint reception, then the host needs to take several RAs into account
>    after the hint reception, before it can determine that it has moved
>    to a different link.

Maybe this is just a wording issue, but the above seems to me to be
backwards conceptually.  A host should always assume it has moved,
unless it learns of info that indicates otherwise. That should be a
base assumption. (Above, the assumption seems the other way around.)

If a host has multiple prefix lists, none of the prefixes in those
lists should intersect. If they do, that indicates the two lists
should be merged. It doesn't really matter whether a set is complete
or not.

>    work.  Thus the host needs to create a new Candidate Link object
>    based on the received RA, and make this object the CCL.  However, it
>    does not yet treat this as a new link; it is merely a candidate.
>    Thus it MUST NOT perform the actions in Section 4.6 at this point in
>    time.  Instead, the host should wait for MAX_RA_WAIT seconds, and all
>    RAs that are received during that time interval are processed as
>    specified above.

Again, I think this logic is wrong (and too complex). You always
assume a link is new as a starting point...

or:

>    Subject to local policy, and perhaps also the host's knowledge of the
>    packet loss characteristics of the interface or type of L2
>    technology, the host can try harder than just waiting for MAX_RA_WAIT
>    seconds, by sending additional Router Solicitations.  It is allowed
>    to multicast up to MAX_RTR_SOLICITATIONS [1] RS messages spaced
>    RTR_SOLICITATION_INTERVAL apart.  In the most conservative approach
>    this means a 12 second delay until the host will declare that is has
>    moved to a new link.  Just as above, this process should be
>    terminated should a new link UP notification arrive during the 12
>    seconds.

this seems overkill, as it doesn't take 12 seconds to configure a link
in the first place... so why are we making this so detailed/complex?
(and again why not just assume we are attaching to a new link, unless
we learn otherwise?)

6)

> 3.4  Renumbering
> 
>    When the host is sure that the prefix list is complete, a false
>    movement assumption may happen due to renumbering when a new prefix
>    is introduced in RAs at about the same time as the host handles the
>    'link UP' event.  We may solve the renumbering problem with minor
>    modification like below.

This will only happen if the RA is "weird' and includes only the one
new prefix... In practice, it should carry more than one prefix. Why
do we need to worry about this case?

7)

4.1: seems overly complicated to me.

Whenever you get a link up, you assume you are at a new
link. period. You then get RAs, and go from there, looking if they
match anything in the "recently visited" set. If you find a match, use
it. If not, you just continue doing normal ND/addrconf..

Thomas

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 30 Jan 2006 14:37:44 -0800

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

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

> 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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 31 Jan 2006 09:49:45 -0500

> continue without any changes.

Agreed.

> link will be added to the 2461/62 conceptual data structures for the old 

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.

> doesn't help much since it will continue to use information from the old 

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.

> information until the information times out (with default timers ranging 

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

> arrives milliseconds later and recreates the disappeared IPv6 address.)

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

> point, then we can see what makes sense with respect to simplifications 

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