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

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

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