[DNA-BOF] Comments on draft-kumar-dna-reqmnt-ipv4-00.txt

[Bernard Aboba <aboba@internaut.com>]

One of the reasons that we do requirements documents in the IETF is to
ensure that we understand the problem we're trying to solve before going
off to do design work.

That implies that an important part of a requirements document is not just
the requirements themselves, but the thought process that justifies them.

To be successful at this, I think a requirements document needs to do a
lot of hard work -- not just to state requirements, but also to look at
the nature of the problem in a fundamental way and argue for a point of
view.

There is a growing realization of in the IETF that requirements documents
have not been doing this lately -- too many of them have either were done
well after the specification itself was done -- or were abandoned in
mid-stream as not worth completing.

Given this, I think we need to take a very hard look at requirements
documents -- in order to decide whether they are really helpful or not.
The rate of failure of requirements documents has been so high lately that
these kind of documents probably need to be considered guilty until proven
innocent.

In that spirit, here is a review of draft-kumar-dna-reqmnt-ipv4-00.txt:

Section 1

"The problem of network attachment detection can be broken into three
basic steps:

a) Movement detection
b) Determine the Next Action
c) Change Configuration if Needed"

While I agree with step a), "determining the next action" is not very
specific, nor is "change configuration if needed."  In the DNAv4
specification, a reachability test is proposed to reliably (and
quickly) determine the point of attachment.  That seems like a better
place to start than "determine the next action".  Similarly "change
configuration if needed" seems unnecessarily vague since in IPv4, address
assignment and configuration are handled in the same protocol (DHCPv4).

Section 2

"The second step involves getting a new IP address from the network"

One of the major objectives of DNAv4 is to avoid having to acquire an IPv4
address if a valid address is already available.  That is why the second
step in DNAv4 is reachability test, *not* address acquisition. Given
that, this statement seems less than helpful.

"Network attachment detection should define mechanisms and procedures
that rely on unambiguous movement information rather than depending on prediction."

One of the fundamental assumptions of DNAv4 is that movement information
is by nature a "hint" that must be confirmed through reachability testing
or address acquisition.  The hints can be "strong" ( likely to
be correct) or they can be "weak" (often wrong) but they are never taken
at face value, ensuring that the IP stack will always come to the correct
conclusion even if the "hints" are unreliable.  As a result, it seems
important to me *not* to assume that unambiguous movement information is
available.

Section 3 Terminology

This section includes lots of Mobile IPv4 terms.  However, the document
does not make a case that these terms are relevant to the problem of IPv4
DNA, which is not dependent on Mobile IPv4.

Section 4 Movement Detection

As detailed in the DNAv4 specification, there are many types of Layer 2
hints, but unfortunately most of these are classified as "weak" --
unreliable indications.  The term "trigger" is not really appropriate here
because it suggests something that is reliable -- which these layer 2
mechanisms are not.

All that is really needed for the purpose of DNAv4 is the determination of
the "most likely point of attachment".  Therefore abstraction of
"triggers" is neither required nor relevant to this problem, and
discussion of "delivery of triggers to foreign agents" seems to be a
distraction to me.

The requirements generated in Section A do not seem useful to me.

"SHOULD use link layer hints" -- why? I'd argue that an important
requirement is that a DNA specification work fine if the link layer hints
aren't available or are misleading. So I don't agree with this
requirement.

"Link layer hints MUST be defined as STRONG or WEAK" -- Again, why? There
are very few STRONG L2 hints at present, and even if the implementation
guesses wrong, if the protocol is robust then the right answer will
eventually be arrived at.

"process the event notification of a link torn down"
I'd argue that it is critical that an implementation *not* process link
down events, because these are very unreliable.  All that is relevant is
"link up".  So this requirement is not only unhelpful -- it's
wrong.

"the DNA protocol MUST be able to process the event notification of a link
reestablishment event immediately"

This is an implementation issue.  A good implementation will process
notifications quickly, but this isn't a protocol problem.

"the DNA protocol MUST be able to differentiate between old and new L2
links"

Depending on the L2 hints this may or may not be possible.  So again, it's
not a protocol issue.

"MUST prefer STRONG hints over WEAK hints"  This one does make sense I
think. But one person's STRONG hint may be another's WEAK hint.  For
example,  Handoff ECSG is talking about advertising prefixes in L2 network
discovery messages.  The problem is that VLANIDs can be dynamically
determined -- so that the hint could actually be WEAK rather than STRONG
in some circumstances. So it may not always be possible to differentiate a
STRONG from a WEAK hint apriori.

"L2 hints MUST NOT overwhelm the upper layer"

This is an implementation issue and does not belong in a
requirements document.

"DNA mechanism MUST apply suitable damping mechanism"

Again, an implementation issue.  Specification of damping mechanisms is
not a protocol issue.  In any case, it doesn't make sense both to have
these kind of "requirements" and *also* to require processing of
link-down, which is rarely useful.

"MUST use network layer hints"  It makes sense for a DNA protocol to
support them, but how can we mandate use?  Since even when IRDP packets
are received it's still necessary to confirm reachability (to confirm
bi-directional connectivity) and also to acquire an address (since IPv4
addresses cannot be determined via IRDP), the reality is that IRDP is
just a STRONG hint. As a result, the STRONG hint preference is described
above, there's not much more that needs to be said.

"SHOULD immediately confirm the movement"
This might be useful for MIPv4 but I don't see the benefit for DNAv4.
Instead, the host should do a reachability test to the default gateway or
acquire a CoA.

"Also Network layer can detect movement by detecting presence or absence
of a DHCP server"

I'd argue that one of the fundamental requirements of DNAv4 is that it
*not* have to detect presence or absence of a DHCP server.  If a host has
a valid address, why does it care if a DHCP server is present? It only
needs to confirm reachabilty to the default gateway.

"MUST be able to learn and remember configuration for previously visited
networks"

This is an implementation issue. It does make sense for implementations to
do this but the protocol doesn't require it.

"MUST assume it is still attached to the most recent network"
I agree this makes sense in most cases.  But why is it a MUST?

"Every element of the assumed configuration MUST be verified"
I strongly disagree with this requirement. If a saved configuration is
valid and available and the host can determine it is still connected to
the network on which it received that configuration why must it verify
every element of the configuration?  This requirement is not only
unhelpful -- it would make optimization impossible!

5 Mobile IPv4 Movement Detection

While I see the relevance to MIPv4, I don't see why this section is
relevant to DNAv4. After all, a host does not need to implement MIPv4 to
do DNAv4.

Section 5.1

"if a client has a valid lease and loses network connectivity,.. it SHOULD
reacquire or verify its IP address"

This is incorrect.  There is no reason for a host losing network
connectivity to attempt to acquire an IP address.  How is this possible if
there is no network connectivity?  This statement (taken from RFC 2131) is
wrong and is being corrected in the DHCPv6 specification.  I'd even argue
that a host with a valid lease does not need to do DHCP on gaining network
connectivity -- if reachability detection is successful.  So this
requirement is misleading.

"A "Zeroconf" capable host will have at least two addresses - routable IP
address (RFC 1918 address) and a zeroconf link-local address"

This is wrong in multiple aspects. Firstly, the ZEROCONF spec recommends
use of a routable address only if available.  Secondly, a routable address
is includes RFC 1918 addresses but also globally routable addresses.