Subject: [DNA] Reclassification of DNA Protocol and new Simple DNA protocol

From: Suresh Krishnan <[email-masked]>
Date: Thu, 01 Nov 2007 15:38:04 -0400

Hi Folks,
   The responses we received to the mail titled "Reality Check - 
Implementer Feedback" indicated that there is interest in developing a 
simple solution while retaining the work we did on the complete 
solution. Hence we propose the following course of action

* Reclassify draft-ietf-dna-protocol-06 to EXPERIMENTAL and simplify it 
by removing a  few of the steps there.
* Separate the TSLLAO into a new document
* Commence work on a new simple solution. Greg and I have written a 
small document to start up this effort.

http://tools.ietf.org/wg/dna/draft-krishnan-dna-simple-00.txt

Please let us know what you think about this course of action.

Thanks
Suresh & Greg

---

From: Jari Arkko <[email-masked]>
Date: Mon, 05 Nov 2007 16:15:57 +0200

I'd like to first see the simple solution as an RFC, and then
we can talk about Exp publications of the other results.

I did not see overwhelming support for doing both on the
list, so my suggestion would be to poll for this again
once the first document is an RFC. Then we will also get
a more realistic measure of what kind of energy is
available for the other RFCs.

And I would like to emphasize that getting progress
on the simple solution in a timely manner is extremely
important. I would like to see document reviews, revisions,
discussion, and a timely submission of the draft to the
IESG.

Jari

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 05 Nov 2007 10:55:40 -0500

Hi Jari,
   Thanks for the comments. I agree with you as well. I will be 
submitting a new version of the simple DNA that addresses few of the 
concerns raised with version -00.

Thanks
Suresh

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 05 Nov 2007 08:17:41 -0800

With respect to the simple solution, I think there are some basic 
requirements that it needs to meet.  These are summarized in RFC 4436 
Section 1.1 (paraphrased to fit DNAv6):

      o  DNAv6 is a performance optimization.  Its purpose is to speed
         up a process that may require as much as a few hundred
         milliseconds (DHCPv6), as well as to reduce multi-
         second conflict detection delays when a host changes networks.

      o  As a performance optimization, it must not sacrifice
         correctness.  In other words, false positives are not
         acceptable.  DNAv6 must not conclude that a host has returned
         to a previously visited link where it has an operable IP
         address if this is not in fact the case.

      o  As a performance optimization, false negatives are acceptable.
         It is not an absolute requirement that this optimization
         correctly recognize a previously visited link in all possible
         cases.  This is acceptable as long as the
         host still operates correctly as it did without DNAv6, just
         without the performance benefit.

      o  As a performance optimization, where DNAv6 fails to provide a
         benefit, it should add little or no delay compared to today's
         RS/RA and DHCPv6 processing.  In practice, this implies that this
         processing needs to proceed in parallel.  Waiting for DNAv6 to
         fail before beginning RS/RA and DHCPv6 processing can greatly 
increase
         total processing time, the opposite of the desired effect.

      o  Trials are inexpensive.  Assuming that DNAv6 performs its
         checks using small unicast packets (NS/ND), the
          cost of an unsuccessful attempt is small, whereas the cost of a
         missed opportunity (having the right address available as a
         candidate and choosing not to try it for some reason) is large.
         As a result, the best strategy is often to try all available
         candidate configurations, rather than try to determine which
         candidates, if any, may be correct for this link, based on
         heuristics or hints.  For a heuristic to offer the prospect of
         being a potentially useful way to eliminate inappropriate
         configurations from the candidate list, that heuristic has to
         (a) be fast and inexpensive to compute, as compared to sending
         a small unicast packet, and (b) have high probability of not
         falsely eliminating a candidate configuration that could be
         found to be the correct one.

Today, I do not believe that either the "simple solution" or the "advanced 
solution" meet these requirements.

>   Thanks for the comments. I agree with you as well. I will be submitting 
>a new version of the simple DNA that addresses few of the concerns raised 
>with version -00.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 05 Nov 2007 17:22:02 -0500

Hi Bernard,
   Thanks for the comments. Please see my responses inline for simple dna.

>         second conflict detection delays when a host changes networks.

I agree.

>         address if this is not in fact the case.

Simple DNA will not produce false positives unless two routers on two 
different links happen to have the same link local address and MAC 
address. Is this a likely scenario that needs to be addressed?

>         without the performance benefit.

I think Simple DNA works as quick as RFC4861 in the worst case (false 
negative) scenarios.

>         total processing time, the opposite of the desired effect.

This is why we send the RS and the NSs in parallel as you suggested. 
This ensures that the simple DNA procedure does not run slower than just 
using RSs.

>         found to be the correct one.

The heuristic in use for simple dna is to store and use the previous 'n' 
link configurations. Thus it satisfies (a). It we use a sufficiently 
large value of 'n' we can ensure that (b) is met. We recommend n to be 2 
but if you think that the number is too low we can increase it.

Thanks
Suresh

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 05 Nov 2007 17:03:49 -0800

>different links happen to have the same link local address and MAC address. 
>Is this a likely scenario that needs to be addressed?

The combination of same link local address *and* MAC address is unlikely, 
assuming that the MAC address is globally unique.  However, not all link 
layers will have a globally unique MAC address, so that there may be a need 
to restrict applicability to those that do.

>This is why we send the RS and the NSs in parallel as you suggested. This 
>ensures that the simple DNA procedure does not run slower than just using 
>RSs.

Right.

>link configurations. Thus it satisfies (a). It we use a sufficiently large 
>value of 'n' we can ensure that (b) is met. We recommend n to be 2 but if 
>you think that the number is too low we can increase it.

A previous link configuration should only be tried if it is still 
corresponds to a valid address.  Otherwise, confirming presence of the 
corresponding router could result in installation of a configuration which 
is no longer valid, which would create a false positive. In practice this 
will restrict the DNAv6 traffic substantially so I'm not clear that it is 
necessary to recommend a value of "n".

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 06 Nov 2007 10:11:45 -0500

Hi Bernard,
   Please see my responses inline

Bernard Aboba wrote:
> The combination of same link local address *and* MAC address is 
> unlikely, assuming that the MAC address is globally unique.  However, 
> not all link layers will have a globally unique MAC address, so that 
> there may be a need to restrict applicability to those that do.

I will add some text in the assumptions and mention the pitfalls if this 
does not hold true.

> 
>> The heuristic in use for simple dna is to store and use the previous 
>> 'n' link configurations. Thus it satisfies (a). It we use a 
>> sufficiently large value of 'n' we can ensure that (b) is met. We 
>> recommend n to be 2 but if you think that the number is too low we can 
>> increase it.
> 
> corresponding router could result in installation of a configuration 
> which is no longer valid, which would create a false positive. In 
> practice this will restrict the DNAv6 traffic substantially so I'm not 
> clear that it is necessary to recommend a value of "n".

The following text in Section 3.4 already sets this as a restriction

"If the addresses obtained from a previous router are no longer valid, 
the host SHOULD NOT send a Neighbour Solicitation to that router."

Does this convey what you want or Would you like some stronger text?

Thanks
Suresh

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 06 Nov 2007 10:11:21 -0800

>"If the addresses obtained from a previous router are no longer valid, the 
>host SHOULD NOT send a Neighbour Solicitation to that router."
>

The SHOULD does not explain what implementations need to do.  The host can't 
just use the address (since it's no longer valid) even if the router is 
confirmed.  So either there is no point in sending the NS, or some special 
procedure needs to be invoked (e.g. waiting for RA confirmation, or 
immediately invoking DHCPv6 if that is how the address was obtained).