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

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

Hi Jin,
   Thanks for the comments. Please find responses inline.

JinHyeock Choi wrote:
> 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.

It is the latter. The node verifies viability of a set of addresses it 
owns by verifying the reachability of the router that advertised the 
corresponding prefixes.

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

I would say no.

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

OK. Will do.

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

Yes. Your understanding is correct.

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

As discussed above, the improvement results from the NS/NA exchange. The 
goal is to be no slower than standard NS behavior and optimize for the 
use cases where possible.

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

I don't think we need token bucket control. But the idea is that 
tentative options are required for oDAD and hence independent of DNA

Thanks
Suresh