[dna] AD review of draft-ietf-dna-simple

[Jari Arkko <[e-mail]>]

Suresh,

I have reviewed this draft. Overall, the draft was easy to read and well 
written. I have no problem with the specified algorithms. However, the 
draft appears to contain a fair amount of extra material on Fast RAs and 
the full-blown dna-protocol that WG worked earlier on. These need to be 
removed; the specification can and should stand on its own, and not 
depend on these other components. In addition, there are a few technical 
issues, including the use of SLLA and lack of clear specification for a 
general purpose implementation wrt configuration.

Here are my specific comments:

Substantial:

> The probing node SHOULD include a Source link-layer address option in 
> the probe messages.  If the node believes that the source address of 
> the NS may not be unique on the newly attached link, it MAY omit the 
> Source link-layer address option in the probe messages.

I would like to understand this better.  How does a general purpose 
operating system implementation deal with the above? How does it know 
that "the source address of the NS may not be unique"?

AFAICT, if you omit the SLLA and no link change happened, then most 
likely the router will remember your NC anyway, and be able to respond. 
However, if it does not remember you, a new NS/NA would be required, but 
DNA would still succeed, albeit a bit slower.

However, if the host did move to a new link, then including the SLLA 
might cause disruption for another host that already holds the same 
address but uses a different link layer address.

Why is the recommendation written as it is above? Is the assumption that 
colliding addresses are so rare that the optimization makes sense? On 
the other hand, it would appear that even without the SLLA DNA would 
still work in most cases.

In any case, I don't think we can require general purpose 
implementations to assess the likelihood of collisions. Perhaps it would 
be easier to require that by default, no SLLA is included and that only 
through specific configuration option the SLLA use can be turned on and 
DNA made to operate faster/more reliably.

>    For the purpose of sending neighbor solicitations to previous
>    routers, the host first needs to pick a subset of operable IPv6
>    addresses (candidate set) that it wishes to use.  How this subset of
>    addresses is picked is based on host configuration. e.g.  The host
>    may select configured addresses from each of zero, one or two
>    previously connected links.

Please specify a default strategy. E.g., "How this subset of addresses 
is picked is based on host configuration. By default the host should 
select configured addresses from two previously connected links."

> Where flooding may cause performance issues within the LAN, host 
> SHOULD limit the number of unicast solicitations.

Again, the guidance for general purpose implementations in inadequate. 
Please specify a default strategy. I believe limiting the number of 
unicast solicitations to some small number (4?) by default is adequate 
(there are a number of messages on a new link even on DNAv4 and regular ND).

>    The probing node SHOULD NOT include a Source link-layer address
>    option if it has not performed duplicate address detection [RFC4862],
>    for the source address of the NS, on the newly attached link.
>

Performed DAD, when? Presumably it has been performed when the address 
first configured, no? And since DNA is the first thing that runs after a 
link change, DAD has not been run at this point either. So what does 
your recommendation really mean here? Never include SLLA?

In any case, at this point we do not yet *know* if we are on a newly 
attached link or not. Therefore, we do not know if we've run DAD in the 
past on this link.

Please clarify.

>    Hosts checking their network attachment are unsure of their address
>    status, and may be using Tentative link-layer addressing information
>    in their router or neighbour solicitations.
>
>    A router which desires to support hosts' DNA operations MUST process
>    Tentative Options from unicast source addressed Router and Neighbour
>    Solicitations, as described in [I-D.ietf-dna-tentative].

This is the first time dna-tentative is referenced in this document. I 
wonder if there's really a need to have a normative reference, or even 
mention this.

> 7. Constants
>
>
>    These constants are described as in [I-D.ietf-dna-protocol].
>
>       UNICAST_RA_INTERVAL
>
>          Definition: The interval corresponding to the maximum average
>          rate of Router Solicitations that the router is prepared to
>          service with unicast responses.  This is the interval at which
>          the token bucket controlling the unicast responses is
>          replenished.
>
>          Value: 50 milliseconds
>
>       MAX_UNICAST_RA_BURST
>
>          Definition: The maximum size burst of Router Solicitations that
>          the router is prepared to service with unicast responses.  This
>          is the maximum number of tokens allowed in the token bucket
>          controlling the unicast responses.
>
>          Value: 20
>

None of these appear to have anything to do with the Simple DNA 
procedure. Please remove. The only item that I can see be of relevance 
in this section is SEND_NA_GRACE_TIME.

>    When providing fast responses to router solicitations, it is possible
>    to cause collisions with other signaling packets on contention based
>    media.  This can cause repeated packet loss or delay when multiple
>    routers are present on the link.
>
>    As such the fast router advertisement system is NOT RECOMMENDED in
>    this form for media which are susceptible to collision loss.  Such
>    environments may be better served using the procedures defined in
>    [I-D.ietf-dna-protocol].

This does not appear to have anything to do with Simple DNA either 
(router-side fast responses are not a subject of this specification). 
Delete?

>    The host MAY delay SEND_NA_GRACE_TIME after transmission before
>    adopting a new default router, if it is operating on a network where
>    there is significant threat of RA spoofing.

I would simply say that this delay MAY be imposed when the host's 
current default router is a SEND-secured one. This prevents the 
downgrade from SEND to non-SEND, but does not require any configuration, 
and it doesn't slow things down when you were already using a non-SEND 
router.

>    It is easy for hosts soliciting without SEND to deplete a SEND
>    router's fast advertisement token buckets, and consume additional
>    bandwidth.  As such, a router MAY choose to preserve a portion of
>    their token bucket to serve solicitations with SEND signatures.

Again, this has very little to do with this specification. Move this to 
the fast RA spec instead.

Editorial:

Move draft-ietf-dna-protocol to informative references.

> After the indication is received, the host considers all currently 
> configured (non-tentative) IP addresses to as deprecated until the 
> change detection process completes.

s/to as/to be/

> addresses is picked is based on host configuration. e.g.  The host

s/The/the/

> If systems do not meet these assumptions or if systems seek 
> deterministic change detection operations they are directed to follow 
> the complete dna procedure as defined in [I-D.ietf-dna-protocol].
I would just delete this. I do not think we want to make what sounds 
like a fairly strong recommendation.

Section 4.5.1 mentions that there are no options, while Setion 4.5.2 
does not.

>    message contains an Identity Addociation for either a Temporary
Association?

Jari