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

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Thomas

Thanks for your helpful and detailed feedback.

In the draft, mainly we try to present a way for a host to check for
link change, whether it remains at the same link or not, upon
receiving a single RA (with prefixes).

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

The draft proposes that the node also assumes it is rejoining a new
link, if it doesn't find a match. To make such an assumption, the node
needs to keep the information of all the prefixes on a link.

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

We try to make a host correctly declare a link change when it receives
an RA with only unknown prefixes. Without maintaining the Complete
Prefix List, that would be difficult.

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

It's ok for me to remove Section 5 unless WG objects it.

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

The Complete Prefix List is to enable a node to correctly declare a
link change when the node get a prefix in an RA and it matches none in
its cache. Without the Complete Prefix List, the fact an RA includes
only unknown prefixes doesn't imply that the node is moved to a new
link.

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

The Incomplete Prefix List may result from packet losses and the
Superfluous Prefix List may result from the node mistakenly combines
the prefixes from different links to produce a single list. The first
may make a node mistakenly assume it has moved to a different link,
whereas the second may make a node mistakenly assume it remains at the
same link.


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

We present this as the most conservative approach and doesn't
recommend it. Even without the Complete Prefix List, it will take 4
secs to finish DNA according to our recommendation.

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

We try to prevent weird cases from happening by explicitly writing
down its pitfall. :-)

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

With our proposal, if you doesn't find a match, you can immediately
detect that you have moved to a new link and substitute existing
configuration information with new one. (It's also possible for you to
save the existing on for the future use.)

Thanks for your kind consideration.

Best Regards

JinHyeock