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

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

JinHyeock Choi <jinchoe@gmail.com> writes:

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

rereading section 4.5:  Receiving valid Router Advertisements,

I'm (generally) fine with the first part of this section. I.e., it
says that when a host receives the first RA (after a link up event):

1) if it contains a prefix in the CCL, assume no link change.

2) if it contains a prefix in retained Candidate Link Object, assume
   host has moved back to that link.

The interesting case is where one receives an RA containing only
prefixes that one has not seen before. It is this case that makes use
of the "complete" state. I.e., if the CCL is complete, one assumes
that learning a new prefix means an immediate move. But if the CCL is
not complete, one doesn't assume one has moved (yet). Specifically:

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

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.

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.

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

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

Thomas