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

[Suresh Krishnan <suresh.krishnan@ericsson.com>]

Hi Bernard,
   Please find comments inline.

Bernard Aboba wrote:
> 
>  > 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.
> 
> [BA] I would agree that Simple DNA should handle common
> link change cases at least as well as DNAv4 does.  Overall,
> I think that this issue points out the need for an
> "Applicability" section in the Simple DNA specification, similar
> to that in DNAv4 Section 1.1, in order to point out exactly
> what the goals of Simple DNA are, and which cases it
> can handle.

I will add an applicability section in the next revision.

> 
>  > 4. Router Modification
>  >
>  > The draft says that simple DNA assumes no router change. Is it
>  > necessary? Previously router modification had been allowed.
> 
> [BA] Within DNAv4, the goal was first to "do no harm" -- no degradation
> if the router did not support unicast ARP.  The second goal was to
> "optimize for the common case" of a host moving between a common set of
> links.  So my opinion would be that Simple DNA should have a similar goal:
> never worse than today, and better in the common case (common router
> behavior).

Yes. This is my understanding as well. I think I will clarify this in 
the Applicability section.

> 
>  > Moreover simple DNA draft mandates that routers MUST support Tentative
>  > Option and mentions token bucket control. Isn't it a router change?
> 
> [BA] I don't understand why "token bucket" control is necessary.   I think
> the draft needs more discussion of the potential address duplication issues,
> so that we can understand the importance of Tentative Option support.
> 
> In Simple DNA, only a valid address can be reconfirmed, so that DAD
> had previously completed.  However, there may be circumstances in
> which another host had taken the address and completed DAD while
> the mobile host was away or asleep.   This could, for example,
> happen in the case of privacy addresses.   DNAv4 specification
> also mentions the case of a non-conformant DHCP server
> (Section 2).  I would suggest a section on Duplicate Address
> Detection be added to go over this.

I will add a section on DAD issues.

> 
> One other thing.  DNAv4 talks about confirmation of manually
> assigned addresses.  Is this not also possible in Simple DNA?

I am not sure how we can confirm a manually assigned address. Thinking 
aloud, we can associate a manually assigned address with a prefix 
announced by a router and confirm using the reachability of the router. 
Does that sound reasonable to you?

Thanks
Suresh