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

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Suresh

Thanks for your clarification. I think we're almost there. :-)

Kindly fine my inline comments.

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

I forgot a few questions.

First, I assume that the expression 'verify VIABILITY of an address' means

'determine whether a host can use the address on the currently attached link'.

Second, I assume that
a DNA host verifies the viability of each address INDIVIDUALLY or
INDEPENDENTLY,
i.e.
the viability of one address doesn't imply
the viability of another address (or its negation).

In case I misunderstand, kindly let me know.

Then I have two questions.

1. How does simple DNA verifies an address with DHCPv6?

There may be no router associated with the corresponding address.

IMO, it's better for simple DNA to deal with DHCPv6 addresses also
and the simplest way may be
1) associate a DHCPv6 address with one of default routers and
2) verify its viability by confirming the reachability with the router.

2. How does a simple DNA verify other IP configuration parameters
such as prefix or MTU.

Previously link identification verifies all IP configuration parameters
in one stroke.
i.e.
If a host remains at the same link, its all IP configuration are still valid,
If not, it's all IP configuration are invalid.

Because now simple DNA verifies only addresses,
it's not clear to me how a host would verify other parameters.

>  > 2. The term 'valid address'
>  > 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.
>
>  In the draft, the term "valid address" refers to option 2)

I have an impression that, in the existing documents,
the term 'valid address' mostly refers option 1).

Even in Sec 3 of simple DNA, the term 'valid' is used as below.

   When the link-layer becomes available again, it is important to
   determine whether the existing addressing and routing configuration
   are still valid.

'valid' in the above seems to refer option 1).

So I don't feel comfortable using 'valid' as option 2).

Instead I propose that we use
'valid address' for option 1) and 'address with non-zero lifetime' for
option 2).

Also it would be better for the draft to define option 1) & option 2)
in a clear & explicit way.

While working on DNA, I got burned much from the confusion surrounding
the term 'link' and became almost paranoia about unclear definitions.
The experience taught me 'a term which can confuse will'. :-)

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

We can make matters simpler by stating that

"SDAT only stores an address with valid lifetime.
When the valid life time expires, SDAT omits the address".

Then we don't have to worry about sending an NS for expired address
and entailing paragraphs.

>  > 3. Deactivating 'Valid address'
>  >
>  > 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.

ok. I think 'a link change occurs' in the above is an error.

Let me rephrase it as below.
when a link-layer indication occurs to initiate DNA procedures,
a DNA host will consider all the address to be type 2) and stop using them,
until each address is verified by NS/ NA exchange with an associated router.

In this sense, a simple DNA host deactivates all its existing addresses
upon DNA initiation.

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

I meant 'deactivate' but we don't have to worry about this anymore
because your explanation above made this irrelevant.

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

IMO, simple DNA would better provide a way to
verify an address configured with DHCPv6.

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

ok. this is reasonable. I agree.

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

ok. thanks for your trouble.

best regards

JinHyeock