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

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Bernard

thanks for your kind reply which helped me to understand the scheme the better.

> > 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 unknown router arrives
>
> > (which may occur the most in link change case.)
>
> [BA] I think that the case of an solicited (or unsolicited) RA coming from
> an unknown router needs to be discussed (whether it has a known prefix
> or not). My assumption is that this will result in additional addresses
> being configured in addition to any known addresses that may be
> confirmed in the simple DNA exchange.

I have a question.

Assume an unknown prefix arrives from an unknown router
before any NA arrives from a known router.

Shall a DNA host immediately configures a new address &
send a BU (in case of MIPv6) or
wait a little further for a might-be NA from a known router?

If the latter is the case,
how long shall the host wait? A second?

> > 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.
>
> [BA] I would say "not previously visited link".

ok. that's more precise.

> > 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.
>
> [BA] Steps 1-3 are at the core of DNAv4, in which the host may
> probe for any valid address.  This approach was based on the
> observation that most mobile hosts move between a stable
> set of links over the course of the day, which often they
> have previously visited.  As a result, they often have a valid
> address, yet existing TCP/IP stacks discard this address as
> soon as the host leaves the link.

thanks for your clarification. I had assumed that the case of Steps 1-3
is not common, whereas you assume it is.

> Since additional unicast NS/NA exchanges are inexpensive,
> DNAv4 does not restrict the host to only probing for 2 networks,
> because we found that it is often common for a host to have 3
> or more valid addresses on various links (e.g. home, work,
> hotspot).

ok. However, I wish we use the term 'valid address' in more clear
and precise way, lest there should be confusion.

The term 'valid address' may mean
1) an address which a host can use on the currently attached link or
2) an address with valid lifetime.

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

ok.

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

ok.

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

Is 'manually assigned address' different from
'statelessly autoconfigured address'?

I assumed that latter includes the former. In case I miss something,
kindly let me know.

Thanks for your kind consideration.

best regards

JinHyeock