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

[Brijesh Kumar <kumarb@research.panasonic.com>]

Bernard:

Thanks a lot for taking time and giving your detailed comments
on various aspects.  I was travelling for last few week
hence, couln't join the discussion that followed.

Here are my brief responses.

<< long comment on IETF requirement docs snipped >>>

As you said, the requirements are hard to get right in
first instance, we welcome any feed back and comments that
will help us in improving the text.

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

We deliberately kept the introductory text simple, and brief.  I don't fully
understand the intent of your last sentence since not all movements will
result in new address assignments.  We will try to be a bit more specific
in the next release, and hopefully that should address your concern here.

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

I think that text has been misunderstood. This paragraph is only
describing the general behaviour of a device moving from one IP subnet
to another. I think the word "new" IP address perhaps caused the
misunderstanding. Will fix in the next release.

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

Bernard - it seems to me that your uncomfortable with the term
"unambiguous".
Basically, what we meant to say was that you either believe a hint to act
on it, or ignore it. You have to assign some level of trust to an event
before acting on it. That is all this meant. Will try to rephrase it a bit
differently.


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.

points taken - will look at them.

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

I don't understand why trigger implies reliability. We used term "trigger"
just to indicate an event notification - which has to be evaluated to assign
whatever reliability the receiver thinks appropriate. We used the term
"hint"
and "trigger" interchangeably as you would notice in section 4.

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

This section provided general background on how layer 2 hints/triggers
needs to be delivered/handled. I think it will provide necessary
background to many readers.

>>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 wit
>>h this requirement.

We think that any solution should utilize hints when available. We didn't
say "MUST" exactly for the reason you mentioned.

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

It is not clear if the solution should have the same behavior for both
STRONG and WEAK hints. If that is the case, then we don't need this
requirement. But, we don't think the answer is clear at this point.

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

Isn't link layer down events dependent on the particular access technology?
Some access technologies will give a reliable indication. Also, at the
requirements level do we want to completely ignore the link torn down event.
May be we should change the requirment to a SHOULD or a MAY.

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

Specifying the priority in which certain events, imo, are handled is
part of the part of the protocol design. Need to think how to reconcile
it with what you say.

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

These requirements only applicable when L2 hints are available.

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

Thats why we did have a requirement earlier to define STRONG and WEAK hints.
Hints that have no priority assigned may be assumed to be WEAK?

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

We believe these requirements need to be specified but will like to seek
more input on this.

>>"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.
We think network layer hints could initiate the reachability test.

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

We agree, this is only applicable for MIPv4 devices. Don't you think DNA
should
utilize MIPv4 features when available?

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

We are only talking about possibility rather than mandating the use of
verifying presence of DHCP server.

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

Will need to think about 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?

We thought it was the most logical option. Open for all ideas/
suggestions here.


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

You are right - we must relax this requirement. Will fix in the
next release.

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

Again, we do beleive DNA should utilize MIPv4 features when available.

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.

I believe the above has been misunderstood. You can only verify when you
are connected again.  I need to check DHCPv6 spec and will address this
appropriately. I agree that if reachability detection is successful,
and the host still has a valid lease - there is no need to communicate
with DHCP server.

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

oops! - the above text needs to be fixed. We missed the necessary
qualification clause for a routable device, and also the text should have
read - routable IP address (global address or RFC 1918 private address) in
the above sentence. It obviously was an oversight.

Thanks again for your very useful detailed comments and time.

cheers,

--brijesh