[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] RE: Review of draft-krishnan-dna-simple-01.txt
Hi Bernard,
Thank you very much for the detailed comments. I will try to get a new revision out that addresses your comments.
Thanks
Suresh
-----Original Message-----
From: Bernard_Aboba@hotmail.com [mailto:Bernard_Aboba@hotmail.com]
Sent: Fri 7/12/2007 4:58 PM
To: dna@eng.monash.edu.au; Suresh Krishnan; greg.daley@eng.monash.edu.au; narten@us.ibm.com; erik.nordmark@sun.com; Jari Arkko
Subject: Review of draft-krishnan-dna-simple-01.txt
Section 2
[BA] I would rewrite this section to state the goals in a more positive light. For example,
you might talk about the goals of DNAv6 and the implications of its being an
optimization (e.g. focus on the common case, desire to work with existing routers).
I would also include within this section a statement that DNAv6 optimizations work
regardless of whether stateless or stateful addressing is supported on a given network.
Section 2.1
Routers adopt procedures which allow for fast unicast Router
Advertisement (RA) messages. Routers that follow the standard
neighbor discovery procedure described in [2] will delay the router
advertisement by a random period between 0 and MAX_RA_DELAY_TIME
(defined to be 500ms) as described in Section 6.2.6 of [2]. This
delay can be significant and may result in service disruption.
[BA] To be clear, I don't believe that support for fast unicast RA is a pre-requisite for
the optimizations discussed in this document to work. For example, if NS/ND
completes prior to receipt of an RA, the network can still be identified.
The host detects that the link-layer may have changed, and then
probes the network with Router Solicitations (RSs) and Neighbour
Solicitations (NSs).
[BA] I would say "simultaneously probes".
Section 2.2
o All the prefixes advertised on the link need to fit into a single
RA. This implies that the number of prefixes on the link needs to
be limited. e.g. 15 prefixes per link. If all the prefixes on the
link do not fit into a single RA, the prefixes that are left out
of the first RA will be advertised in another RA. A host
receiving such an RA from another router on the link will
incorrectly assume that it has changed links.
o All the prefixes advertised on the link need to fit into a single
RA. This implies that the number of prefixes on the link needs to
be limited. e.g. 15 prefixes per link. If all the prefixes on the
link do not fit into a single RA, the prefixes that are left out
of the first RA will be advertised in another RA. A host
receiving such an RA from another router on the link will
incorrectly assume that it has changed links.
o All routers on the link advertise the same subnet prefixes.
o The number of advertising routers on the link needs to be limited
to the number defined in MAX_ROUTERS_FOR_SIMPLE_DNA.
[BA] I think there is an implicit assumption here that needs further discussion.
If NS/ND completes and identifies a network, I'd assume that receipt of a
single RA without the expected prefix would not be sufficient for the host
to conclude that the identification was wrong. The host would wait until
it concluded that no RAs with the expected prefix are forthcoming. If so,
are these limitations still operative?
If these assumptions do not hold, host change detection systems will
not function optimally. In that case, they may occasionally detect
change spuriously, or experience some delay in detecting network
attachment. The delays so experienced will be no longer than those
caused by following the standard neighbor discovery procedure
described in [2].
[BA] As noted above, I'm not clear that spurious change identification need
necessarily occur in these cases. It also bring up the question of the
overall assumptions underlying DNAv6. For example, do we have an
understanding of whether DNAv6 shares the objectives of DNAv4 as
expressed in RFC 4436 Section 1.1? To rephrase in DNAv6 terminology:
"The applicability of DNAv6 lead us to a number of conclusions:
o DNAv6 is a performance optimization. Its purpose is to speed
up a process that may require as much as a few hundred
milliseconds (RS/RA, DHCPv6), as well as to reduce multi-
second conflict detection delays when a host changes networks.
o As a performance optimization, it must not sacrifice
correctness. In other words, false positives are not
acceptable. DNAv6 must not conclude that a host has returned
to a previously visited link where it has an operable IPv6
address if this is not in fact the case.
o As a performance optimization, false negatives are acceptable.
It is not an absolute requirement that this optimization
correctly recognize a previously visited link in all possible
cases.
o As a performance optimization, where DNAv6 fails to provide a
benefit, it should add little or no delay compared to today's
processing. In practice, this implies that RS/RA
processing needs to proceed in parallel. Waiting for DNAv6 to
fail before beginning RS/RA processing can increase
total processing time, the opposite of the desired effect.
o Trials are inexpensive. DNAv6 performs its checks using small
unicast NS packets. This means that the
cost of an unsuccessful attempt is small, whereas the cost of a
missed opportunity (having the right address available as a
candidate and choosing not to try it for some reason) is large.
As a result, the best strategy is often to try all available
candidate configurations, rather than try to determine which
candidates, if any, may be correct for this link, based on
heuristics or hints. For a heuristic to offer the prospect of
being a potentially useful way to eliminate inappropriate
configurations from the candidate list, that heuristic has to
(a) be fast and inexpensive to compute, as compared to sending
a small unicast packet, and (b) have high probability of not
falsely eliminating a candidate configuration that could be
found to be the correct one.
o Time is limited. If DNAv6 is to be effective in enabling low
latency handoffs, it needs to complete in less than 10 ms.
This implies that any heuristic used to eliminate candidate
configurations needs to take at most a few milliseconds to
compute. This does not leave much room for heuristics based on
observation of link-layer or Internet-layer traffic."
Section 3
The steps involved in basic detection of network attachment are:
o Link-Layer Indication
o Optimistic DAD
o Router Solicitation
o Neighbour Solicitations to prior router(s)
o Response gathering and assessment
[BA] This list (and the sections that follow) are confusing because they don't describe the
precise order in which the actions occur. For example, router solicitations and neighbor
solicitations are sent simultaneously, but this is not obvious on reading Sections 3.3
and 3.4. I would add something like the following text to this Section:
" For each network that it connects to, it is assumed that the host
saves the following parameters to stable storage:
[1] The IPv6 and MAC address of one or more test nodes on the
network.
[2] The IPv6 configuration parameters, including the IPv6 address and
expiration time, and DHCPv6 DUID (if DHCPv6 was used).
From the set of networks that have operable IPv6 addresses associated
with them, the host selects a subset and attempts to confirm the
configuration for each network. "
Section 3.3
3.3. Router Solicitation
The primary mechanism used to detect network attachment in IPv6 is
router solicitation and advertisement. When a host receives a link-
layer indication, it SHOULD immediately send a Router Solicitation to
the All-routers address containing one of the host's optimistic
unicast source address [2][5].
[BA] I would rewrite this as follows:
"When a host receives a link-layer "up" indication, it SHOULD immediately
send both a Router Solicitation and if it retains at least one valid IPv6
address, one or more unicast Neighbor Solicitations. The Router
Solicitation is sent to the All-routers multicast address containing
one of the host's optimistic unicast source address [2][5]."
[BA] Question: If the host is in possession of more than one valid IPv6 address, which one
should it use? Should it send more than one RS with each valid IPv6 address?
Section 3.4
[BA] As written, this section is not very useful. I would suggest replacing it with the
following:
"Based on the subset of operable IPv6 addresses that the host selects, it sends
unicast Neighbor Solicitations to each of the corresponding test nodes [2][5].
The host SHOULD NOT send unicast Neighbor Solicitations to a test node
corresponding to an IPv6 address that is no longer valid."
[BA] Do we need to provide more detail on what the unicast NS should contain?
Section 3.5
The Simple IPv6 DNA assessment on the host relies upon tying
advertised prefixes to the advertising routers.
[BA] This is not really accurate given the use of NS/ND. I would delete this
sentence.
Reception of an
advertisement from a router which is known to advertise a prefix can
be used to indicate that the node has reconnected to a link it was
previously connected to.
Where a responding Neighbour Advertisement is received from a
previously configured router, the host MUST verify if the hardware
address of the router matches the one that was previously known. If
it does, the host can decide that it hasn't changed networks, and MAY
continue to use the link configuration information (prefixes, MTU
etc.) with high probability.
Reception of a Router Advertisement which contains prefixes which
intersect with those previously advertised by a known router
indicates that the host has returned to that link with high
likelihood.In this case the host can decide that it hasn't changed
networks, and MAY continue to use the existing prefixes with high
probability.
Additionally, where a host receives a solicited router advertisement
after sending an RS for the purpose of detecting network attachment,
and this prefix contains only prefixes which are disjoint from known
advertised prefixes, the host SHOULD conclude with high probability
that it has moved to a different link.
[BA] I would change this to the following:
" Where a responding Neighbour Advertisement is received from a
test node, the host MUST verify that both the IPv6 and link layer
addresses of the test node match the expected values before utilizing the
configuration associated with the detected network (prefixes, MTU
etc.).
On reception of a Router Advertisement which contains prefixes which
intersect with those previously advertised by a known router, the host
utilizes the configuration associated with the detected network.
If after sending an RS, a host receives a solicited router advertisement
containing only prefixes which are disjoint from known advertised prefixes,
the host SHOULD conclude that none of its operable IPv6 addresses are
valid and that it has moved to a new link.
Where the conclusions obtained from the Neighbor Solicitation/Advertisement and the
RS/RA exchange differ, the RS/RA (and potentially a subsequent DHCPv6 exchange)
will be considered definitive."
Section 3.6.2
3.6.2. Actions upon arrival at a new link
Upon arrival on a new link, the host should unconfigure its existing
addresses and routers, and begin address configuration techniques, as
indicated in the received Router Advertisement [2][8].
The host SHOULD keep information about prefixes advertised by routers
from the prior link, for the purposes of subsequent change detection
operations.
[BA] The last sentence belongs much earlier in the document (see comments on Section 3).
Section 4
Routers wishing to support host change detection need to provide them
with quick responses to queries. Basic support for DNA for IPv6
requires two basic operations.
These procedures allow for a host to receive immediate response to a
router solicitation, and may simplify a host's internal change
detection operations.
The simple IPv6 DNA router components are:
1. Tentative Option processing
2. Fast Unicast Response to Solicitation with Token Buckets
These are described in the following sections.
[BA] Recommend rewriting as follows:
" Routers wishing to support host change detection need to respond
quickly to queries. Basic support for DNA for IPv6 requires:
1. Tentative Option processing
2. Fast Unicast Response to Solicitation with Token Buckets
These procedures allow for a host to receive immediate response to a
router solicitation, and may simplify a host's internal change
detection operations. A detailed description is provided in the
following sections."
Section 6
Rate limitation for solicitations.
In some circumstances, the rate of transmissions for
solicitations may need to be restricted or limited. This
depends highly upon the movement pattern and quality of link-
layer indications. Hysteresis mechanisms which slow or prevent
solicitation operations may be necessary to prevent damage to
the local network environment.
Particularly, transmission of unicast solicitations may cause
packet flooding across a bridged network if received on a
network where the link-layer unicast destination is unknown.
This shouldn't cause wireless link utilization, where base
stations maintain state about attached subscribers.
[BA] "Flooding" implies high bandwidth consumption. This cannot occur
in bridges conforming to IEEE 802.1d, and implementations that have
exhibited this problem have acknowledged their lack of standards conformance
and have issued a fix.
What is more important, and what the document does not mention,
is the recommended retransmission behavior. Here is some
recommended text on the subject (rephrased from RFC 4436 for DNAv6):
" In situations where DNAv6, RS/RA and possibly DHCPv6 are used on the same link, it
is possible that the reachability test will complete successfully,
and then RS/RA or DHCPv6 will complete later with a different result. If this
happens, the implementation SHOULD abandon the reachability test
results and use the RS/RA or DHCPv6 result instead, unless the address confirmed
via the reachability test has been manually assigned.
Where the reachability test does not return an answer, this is
typically because the host is not attached to the network whose
configuration is being tested. In such circumstances, there is
typically little value in aggressively retransmitting unicast neighbor
solicitations that do not elicit a response.
Where unicast Neighbor Solicitations and Router Solicitations are sent in parallel, one strategy is to
forsake retransmission of Neighbor Solicitations and to allow retransmission only of Router Solicitations
or DHCPv6. In order to reduce competition between unicast Neighbor Solicitations and Router Solicitations
and DHCPv6 retransmissions, a DNAv6 implementation that retransmits may
utilize the retransmission strategy described in the
DHCPv6 specification [RFCDHCPv6], scheduling DNAv6 retransmissions
between Router Solicitation or DHCPv6 retransmissions.
If a response is received to any unicast Neighbor Solicitation, Router Solicitation or DHCPv6 message,
pending retransmissions are canceled. It is RECOMMENDED that a DNAv6
implementation retransmit a Neighbor Solicitation no more than twice. To provide damping in
the case of spurious "Link Up" indications, it is RECOMMENDED that
the DNAv6 procedure be carried out no more than once a second."
Hosts MAY implement hysteresis mechanisms to pace solicitations
where necessary to prevent damage to a particular medium.
Implementors should be aware that when such hysteresis is
triggered, Detecting Network Attachment may be slowed, which
may affect application traffic.