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

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

Hi Jin,
   Please find responses inline.

JinHyeock Choi wrote:
> Dear Suresh
> 
> Thanks to your kind clarification. Now I understand the draft better.
> 
> Since the scheme is no longer based on link identification, there
> follow some changes. Some previous assumptions won't hold no longer.
> 
> Here are my modified concerns.
> 
> 1. Applicability statement
> 
> I understand that
> Simple DNA aims to optimize for the common case of
> a host moving between a common set of links.
> 
> i.e. when a host performs simple DNA operation,
> the optimization happens mostly when
> 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.
> 
> Do I understand right?

Yes. This is correct.

> 
> If so, as Bernard wrote, this approach is 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.
> 
> Maybe we'd better mention the above in the applicability section.

OK.

> 
> 2. The term 'valid address'
> We need to define & use the term 'valid address' in more precise & clear way.
> 
> The term 'valid address' may mean two different things.
> 
> 1) An address which a host can use on the currently attached link.
> 2) An address which has valid lifetime left, i.e. non-zero lifetime.
> 
> The fist is a proper subset (but not equal) of the second.
> 
> The first depends on where the host is currently attached,
> whereas,
> the second is independent of the host's current Point of Attachment.
> 
> Because now a host keeps addresses with non-zero life time,
> even after it moved to another link,
> I propose to make a clear distinction between two,
> unless there should be a confusion.

In the draft, the term "valid address" refers to option 2)

> 
> For example, the following expression in 3.4. confused me.
> 
>                                            The host SHOULD NOT send
>    unicast Neighbor Solicitations to a test node corresponding to an
>    IPv6 address that is no longer valid.

This sentence means that "if there is an address stored in the SDAT, and 
the valid lifetime has passed, do not send an NS to check for the 
router's reachability".

> 
> 3. Deactivating 'Valid address'
> 
> If a host moves to a different link,
> it should stop using its existing IP addresses,
> even though they still have non-zero lifetime.
> 
> DNA needs a procedure to deactivate (i.e. stop using) existing addresses.
> 
> Previously DNA deactivated (dumped) the existing addresses,
> when a link change is confirmed.
> 
> Because now DNA is no longer perform link identification,
> I wonder how a simple DNA deactivates existing addresses?
> i.e. when a simple DNA host stop using the existing addresses?
> 
> I understand that
> Simple DNA address table (SDAT) includes both types of valid addresses
> 1) addresses which the host can use on the currently attached link and
> 2) addresses which the host can't, while they still have valid lifetime.

Correct.

> 
> In my opinion, SDAT may need to distinguish those two kinds of addresses,
> for example with flags.

Not really. When a link change occurs, the host will consider all the 
addresses to be type 2). i.e. None of the addresses in the table are 
usable until confirmed usable.

> 
> Then a DNA host can deactivate existing addresses,
> when one of the second class addresses is confirmed with NS/ NA exchange.

You mean activate instead of deactivate, right? If so, the answer is yes.

> 
> 4. DHCPv6 address
> To which router does a DNA host send an NS to confirm an DHCPv6 address?
> 
> In current SDAT form, for DHCPv6 address, only DUID is recorded.

The DHCPv6 operation is not specified in the draft. It is only for 
future proofing the table.

> 
> 5. Not previously visited link
> I wish the draft describe in more detail the case
> when a host moves in to a 'not previously visited link'.
> 
> For example, when a host receives un unknown prefix from an unknown router,
> shall the host immediately configure a new address with the address
> and send a BU (in case of MIPv6) or
> wait still further for a might-be reply from a known node?

This is my subjective take on this. Feel free to disagree. The idea of 
the NS/NA exchange is to complete BEFORE the RA arrives. If an RA 
arrives before the NA, the host will configure an address out of the RA 
and send a BU. Note that this does not mean that, the other yet to be 
confirmed addresses are invalid. An NA that arrives after the RA will 
still confirm the address as usable. I think I can add some text to make 
it clearer.

Cheers
Suresh