Re: [DNA] Simple DNA [Fwd: I-D Action:draft-krishnan-dna-simple-03.txt]

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Suresh & Greg

Thanks for your trouble updating the draft. However, I can't but confess
that I'm still confused.

Here are my main concerns.

1. Link identification or not?

I kept assuming that DNA would be based on link identification,
i.e. to verify whether a DNA host remains in the same link or not.

Whereas recently Bernard expressed an opinion that
the assumption might not hold for simple DNA as below.

   "One question for simple DNA is whether we are attempting to determine
   a "link" or just connectivity to a particular router interface.
This is a subtle,
   but potentially important difference.  My impression had been that the goal
   was the latter."

From the draft, it's not clear to me, among above two,
which simple DNA aim to.

Kindly clarify whether simple DNA is based on link identification or not.

2. Link identification mechanism.

If simple DNA is based on link identification,
the link identification mechanism is not clear to me.

Link identification mechanism is mostly described in Sec 3.5
but it only listed the cases when
1) a solicited NA from a known test node arrives,
2) a solicited RA with a known prefix arrives
  (it's not clear whether the RA should come from a known router or not)
3) a solicited RA without a known prefix from a known router arrives.

I can't find the paragraphs for the case
when a solicited RA without a known prefix from un unknown router arrives
(which may occur the most in link change case.)

If you provide pseudocode as Sathya did in Sec 5.2.6.1. of DNAv6,
that would be of help.

3. Little improvement in case of link change.

Simple DNA optimization is mostly based on NS/NA exchange but
I am afraid that won't help for the case of link change,
i.e. when a host actually moves to a new link.

IMO, DNA optimization is needed the most for such link change case,
because then the host no longer has a valid IP address and
should configure a new address as soon as possible
lest there should be communication disruption.

According to Simple DNA, when a host moves to a new link,
it would receive no solicited NA and
should rely on a solicited RA which will arrive after random delay.
So if the host has an on-going session, that would likely
to be disrupted. unless, by chance,
1) the host happens to visit the currently attached link some time ago,
2) has kept the link's information even after it detached from it and
3) sends a NS to one of its routers with the preserved information.

I think DNA optimization should provide some improvement
for the case of link change.  From that viewpoint, I am not sure of
the suitability of NS/ NA based improvement.

4. Router Modification

The draft says that simple DNA assumes no router change. Is it
necessary? Previously router modification had been allowed.

Moreover simple DNA draft mandates that routers MUST support Tentative
Option and mentions token bucket control. Isn't it a router change?

Thanks for your kind consideration.

best regards

JinHyeock


> On Thu, Feb 28, 2008 at 8:36 AM, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:
>
> Hi Folks,
>    We have submitted a new version of the simple dna protocol. The new
>  draft addresses significant issues raised by Bernard Aboba, Jin-hyeock
>  Choi and Thomas Narten. Please take a look and send comments to the list
>  or to us personally. We would like to discuss this draft at the dna wg
>  meeting in Philly.
>
>  Thanks
>  Suresh
>
>
>  -------- Original Message --------
>  Subject: I-D Action:draft-krishnan-dna-simple-03.txt
>  Date: Wed, 27 Feb 2008 08:30:01 -0800 (PST)
>  From: Internet-Drafts@ietf.org
>  Reply-To: internet-drafts@ietf.org
>  To: i-d-announce@ietf.org
>
>  A New Internet-Draft is available from the on-line Internet-Drafts
>  directories.
>
>         Title           : Simple procedures for Detecting Network Attachment in
>  IPv6
>         Author(s)       : S. Krishnan, G. Daley
>         Filename        : draft-krishnan-dna-simple-03.txt
>         Pages           : 13
>         Date            : 2008-02-25
>
>  Detecting Network Attachment allows hosts to assess if its existing
>  addressing or routing configuration is valid for a newly connected
>  network.
>
>  This document provides simple procedures for detecting network
>  attachment in IPv6 hosts, and procedures for routers to support such
>  services.
>
>  A URL for this Internet-Draft is:
>  http://www.ietf.org/internet-drafts/draft-krishnan-dna-simple-03.txt
>
>  To remove yourself from the I-D Announcement list, send a message to
>  i-d-announce-request@ietf.org with the word unsubscribe in the body of
>  the message.
>  You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>  to change your subscription settings.
>
>  Internet-Drafts are also available by anonymous FTP. Login with the
>  username "anonymous" and a password of your e-mail address. After
>  logging in, type "cd internet-drafts" and then
>         "get draft-krishnan-dna-simple-03.txt".
>
>  A list of Internet-Drafts directories can be found in
>  http://www.ietf.org/shadow.html
>  or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>  Internet-Drafts can also be obtained by e-mail.
>
>  Send a message to:
>         mailserv@ietf.org.
>  In the body type:
>         "FILE /internet-drafts/draft-krishnan-dna-simple-03.txt".
>
>  NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>  Below is the data which will enable a MIME compliant mail reader
>  implementation to automatically retrieve the ASCII version of the
>  Internet-Draft.
>
>
> _______________________________________________
>  I-D-Announce mailing list
>  I-D-Announce@ietf.org
>  https://www.ietf.org/mailman/listinfo/i-d-announce
>
>
>