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

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Thomas

> >  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.
>
> >    This processing might result in finding a prefix in common between a
> >    Candidate Link object and the CCL, in which case the host knows
> >    whether and to which link it has moved.  But should the MAX_RA_WAIT
> >    seconds expire without any common prefix, then it will conclude that
> >    it has moved to a new link and inform the rest of the host of the
> >    movement (Section 4.6.)
>
> Could you clarify for me how the above relates to normal 2461/2462
> processing? I.e., I would assume that the new prefix should be
> configured on the link immediately. Is this the case?

The new prefix is immediately assumed to be assigned on the currently
attached link (which is obvious). Main issue is what we will do with
the existing prefix list.

In case the host remains at the same link, the new prefix is added to
the existing prefix list. In case of a link change, the host makes a
new prefix list with the new prefix.

> Also, I'm not sure it's worth the complexity of waiting another 4
> seconds to gather additional RAs before declaring a move.
>
> Or maybe I don't understand what it means to "declare a move" and what
> impact that has on the addresses configured on the interface. This
> goes back to my message yesterday asking what processing we are
> assuming happens upon a "link down" event.

When a host declare a move, it should discard current IP configuration
information such as IP address. Declaring a move implies not only the
host's existing link is down but also the host  is attached to a
different link. So on the currently attached link, the host can't use
its existing configuration information and needs new one. The host
should configure a new IP address and re-establish its TCP connections
(assuming no MIPv6).

> Given that as far as we know,  most RAs include complete information,
> why go to so much trouble to handle the case where this is not the
> case, and where the cached information is "incomplete" (which also is
> probably not the normal case), etc.
>
> I agree that having a Complete Prefix List would be good, in the sense
> that upon receipt of an RA, one is more likely to make a correct
> determination about whether one has rejoined an existing link.
>
> However, the current document formalizes this too much, including
> algorithms that are used to (in some sense) "declare" when one has a
> complete list as opposed to maybe not having a complete list. I'm just
> not convinced (yet) that this complexity has sufficient benefit in
> practice.

Usually a host will keep the Complete Prefix List and check for link
change with just one RA. Most complexity is from maintaining Complete
Prefix List to make DNA more precise/ stable.

> > 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.
>
> So, it takes 4 seconds to complete  DNA?

This is the worst case, an upper bound. In general DNA will be
completed upon the receipt of the first RA.

> I thought the whole point was
> for DNA to complete quickly. Recall, using normal 2461/2462 in _MOST_
> cases, a single RS will trigger the transmission of RAs from _all_
> routers, and this will complete within .5 seconds. Thus, having DNA
> operate for 4 seconds seems to miss the bigger picture.

I agree that DNA is to complete quickly but think it also is to decide
correctly. We aimed both Speed and Precision (sounds like a NIKE ad.
:-))

Usually Speed and Precision is in a kind of trade off, the quicker you
decide, the less precise the decision. We try to strike a healthy
balance between them.

To increase the speed, we may make the policy that the host makes a
decision upon receiving the first RA (even without the Complete Prefix
List). But that will decrease the precision and may result in falsely
declaring a move. When a host declare a move, it should discard its IP
address and tear down TCP connections. Hence we recommend a different
policy for the host to wait up till 4 secs (this is upper bound) to
enhance the precision. It may worthwhile to wait a few additional
seconds instead of instantly jumping to the conclusion and tearing
down all TCP connections.

Thanks for your kind consideration.

Best Regards

JinHyeock