Re: [dna] Review of draft-ietf-dna-simple-11

[Thomas Narten <[e-mail]>]

Ted Lemon <[e-mail]> writes:

> Ralph asked participants in the DHC working group to review the draft, so I gave it a read.   I have some comments.   I realize that some of these comments are partially addressed in the summary message Jari sent to the list recently, but it's difficult to know what to include and what to leave out, so I just included it all.

> >From section 2.1:

>   o  False positives are not acceptable.  A host should not conclude
>      that there is no link change when there is one.

>   o  False negatives are acceptable.  A host can conclude that there is
>      a link change when there is none.

> This seems backwards, unless there is no cost to a false negative.  If
> a host concludes that there was a link change when there was none, and
> as a consequence abandons the IP addresses it was using on the
> previous link, that's going to create a (potentially noticeable)
> hiccup while it reacquires its address.  Depending on the IP stack,
> it's possible that connections might also be broken, e.g. if a syscall
> returns EHOSTUNREACH due to a transient routing outage.

Note, as a comparison point, a stack that does not implement DNA. When
the node encounters a "link up" event, that presumably also implies a
"link down" event preceding the "link up" event, and the default
course of action should be to throw away all the old configuration
information and then start the configuration process from scratch.

Thus, the concern you cite above happens today with our current
specs. DNA doesn't make things worse.

(Of course, different stacks may do different things, but from a
specification perspective, I believe the above behavior is what the
specs imply, if they don't say it explicitely.)

Thomas