The WG has requested that this document be advanced as a PS. I have
completed my pre-IESG/pre-Last Call review (the one that shepherding
AD makes prior to authorizing the IETF Last Call) and have some
questions/comments. Main comments come first, more detailed
comments/nits come at the end.
Note that these comments come from me, not the IESG as a whole. The
IESG as a whole won't review the document until the IETF Last Call has
completed, I verify that any Last Call comments have been dealt with,
and then formally request that the IESG consider the document for
advancement.
General comments:
1) I assume router-select is an optional document, and there is no
intent to require all IPv6 nodes to implement it.
However, it appears to contain a change to the ND specification, one
intended that all ND implementations make.
The Abstract says:
The second
change is a mandatory modification of the conceptual sending
algorithm to support load-sharing among equivalent routers.
The intro says:
This document also describes a mandatory change in host behavior.
Neighbor Discovery�s conceptual sending algorithm is modified to
require hosts to select randomly among equivalent routers. This
distributes traffic to different destinations among the routers.
Traffic to a single destination continues to use a single router,
because of the Destination Cache.
I assume that the above text resulted from a merging of
draft-ietf-ipv6-host-load-sharing-00.txt with router-selection.
If I understand the intent, I believe it is a mistake to merge the two
documents. It would be better to keep all mandatory changes to the ND
spec in a way that they are clearly identifiable. Burying mandatory
changes to the ND document within a related (but
optional-to-implement) document will make it hard for folks to find
those changes.
Resurrecting host-load-sharing seems a fine way to go. At some point,
it would probably make sense to incorporate the text directly in the
ND spec anyway. (Or maybe we should just delay making the update until
ND needs to be respun -- this depends on what other issues people have
with the ND spec.)
2) There is an assumption here that the adminstrators involved will
coordinate with one another to configure sensible router preference
values. However, I'm concerned that this assumption won't hold in
practice. E.g., if I'm at home, I may have a tunnel to my corporation
and a connection to the Internet (or multiple ones). (This scenario is
described in the document). Howver, my ISP and my corporation simply
won't coordinate here. Consequently, I'm wondering whether more
guidance can be given here on how to set the preferences (in the
absence of coordination among the site admins) and/or to make them
configurable/mappable (on the user's host) so that if the preferences
don't achieve the desired results by default, the user has some
recourse to adjust them to result in better behavior. Indeed, adding
more configuration capabilities on the host may make sense to go in
also to help deal with Routers that aren't upgraded, in order to
assign them preferences.
Here is what the document says:
> The preference values (both Default Router Preferences and Route
> Preferences) should not be routing metrics or automatically derived
> from metrics: the preference values should be configured. The High
> and Low (non-default) preference values should only be used when
> someone with knowledge of both routers and the network topology
> configures them explicitly. For example, it could be a common
> network administrator, or it could be a customer request to
> different administrators managing the routers.
I worry that the above will not hold in practice in a majority of
cases.
I wonder if a better applicability section would help, that describes
where this is expected to be used and how things need to be configured
by default in such environments.
3) The document isn't very clear about exactly when to probe, and what
the actual probe algorithm is. ND has a very simple probe
model. Whenever sending to/through a neighbor, if that neighbor is not
known to be reachable (and sufficient time has elapsed), one
probes. Probes are then retransmitted if not responded to. In ND, one
never needs to probe neighboring routers that one is not actually
using (except when all routers are unreachable). This is OK, because
the assumption/model is that all neighboring routers are equal, and if
you have a working one, there is no need to check for a better
one. NUD handles the case where a next-hop fails and another one
should be tried.
With this document, the model changes. There is an assumption that
some routers are better than others, and which router is better for a
destination depends on the actual route prefixes that are
advertised. That raises an issue of consistency. Are the neighbors
that are being used always consistent with the known preferences of
the routers? In particular, if a higher preference router is not
reachable, when is it probed? Or, suppose there is a change in the
routing table (a prefix is added or deleted), is there an attempt to
(or a need to) revalidate that all the next-hops currently in use are
the right ones based on the priorities/prefixes?
It seems to me that a users of this document will intuitively expect
that when the highest preference router is reachable, it will be
used. Or when a higher preference router becomes available, routes
will be updated to use it.
the document says:
> 3.3. Destination Cache Management
>
> When host C processes a Router Advertisement and updates its
> conceptual Routing Table, it SHOULD invalidate or remove Destination
> Cache Entries and redo next-hop determination for destinations
> affected by the Routing Table changes. The host MAY implement this
> requirement by flushing its entire Destination Cache.
Seems like the above SHOULD should be a MUST, in order to meet the
principle of least astonishment.
However, the MAY seems ill-advised, as the Destination Cache may also
include other information (e.g., path MTU info?) that should not be
flushed as a side-effect of such a route change. Can the above be
implemented reasonably without resorting to just flushing the table
and rebuilding whenever a change is present?
4) I'm also unclear as to how easy it will be to implement the
specific lookup algorithm that type C hosts will implement. My
understandinng is that routing lookups today are done using
longest-match, where the lookup stops at a particular node in the
tree. I could imagine multiple nodes being at the same point in the
tree (i.e., corresponding to two or more instances of a prefix but
using different routers with possibly different preferences).
But the algorithm specified actually says reachable routers are to be
preferred over unreachable ones. This means that the longest-match
lookup may stop at a node with an unreachable router. What is done in
this case? Does one have to unwind the tree search to try a node
visited earlier (i.e., a shorter match?)? Is this reasonable for
implementations? [note: its not immediately clear that one can just
remove nodes from the routing tree that correspond to unreachable
routers, because one must also probe these routers in some cases.]
Another implementation complexity is due to the preferences combined
with the reachability status. Many implementations have a user-level
process which takes preferences into account and only installs the
most preferred route for a given prefix into the kernel. Hence the
kernel need not be aware of preferences. Given the reachability status
all routes need to be in the kernel since the most preferred for a
given prefix might be unreachable and a less preferred route might
exist for the identical prefix.
Q: who has implemented this draft? Can they comment on the
implementations issues mentioned above?
================
Specific comments and nits:
> The second
> change is a mandatory modification of the conceptual sending
> algorithm to support load-sharing among equivalent routers.
remove per earlier comments?
> Neighbor Discovery is to
> unicast routing as Multicast Listener Discovery is to multicast
> routing. In both cases, a single simple protocol insulates the host
> from the variety of router-to-router protocols.
The comparison of MLD with ND seems pretty weak to me. Sure, they both
isolate Host<->router interaction from router<->router interaction,
but beyond that they are very different. Suggested reword:
Neighbor Discovery shares with Multicast Listener Discovery the
property that they both define host-to-router interactions, while
shielding the host from having to participate in more general
router-to-router interactions.
> This document also describes a mandatory change in host behavior.
> Neighbor Discovery�s conceptual sending algorithm is modified to
> require hosts to select randomly among equivalent routers. This
> distributes traffic to different destinations among the routers.
> Traffic to a single destination continues to use a single router,
> because of the Destination Cache.
Update per earlier comment?
> 10 Reserved - MUST NOT be sent
> If the
> Reserved (10) value is received, the receiver should
> treat the RA as having a zero Router Lifetime.
s/should/MUST/
> Note that in addition to the preference value in the message header,
> a Router Advertisement can also contain a Route Information Option
> for ::/0, with a preference value and lifetime. Encoding a
> preference value in the Router Advertisement header has some
> advantages:
>
> 1. It allows for a distinction between "best default router" and
> "best router for default", as described below in section 5.1.
>
> 2. When the best default router is also the best router for
> default (which will be a common case), encoding the preference
> value in the message header is more efficient than having to send
> a separate option.
After a number of re-reads, I still do not understand the above
distinction. I think I understand the example, but the explanatory
text above is not intuitive at all.
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> + +
> | |
> + Prefix +
> | |
> + +
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shouldn't the picture show the prefix to be a variable width field?
> Prf (Route Preference)
> 2-bit signed integer. Indicates whether or not to prefer
> this router for the prefix over others.
reword for clarity (?):
2-bit signed integer. The Route Preference indicates whether to
prefer the router associated with this prefix over others, when
multiple identical prefixes (for different routers) have been
received.
> If the Reserved
> (10) value is received, the Route Information Option
> MUST be ignored.
Why ignored? In the case where PrF is in the message header, the rules
say treat the value as 00. What is the motivation for handling these
two case differently?
> Route Lifetime
> 32-bit unsigned integer. The length of time in seconds
> (relative to the time the packet is sent) that the
> prefix is valid for route determination. A value of all
> one bits (0xffffffff) represents infinity.
Note that the lifetimes in ND are only 16-bits. It seems like it would
be better to be consistent in the two documents. It is not immediately
clear that a lifetime of longer htan 18.2 hours (the max per ND's 16
bits) is useful in practice. (Indeed, it may be worse the useful in
that an (incorrect) entry with a long timeout can take days to weeks
to expire.)
Use 16 bits here as well?
> The Length field is 1, 2, or 3 depending on Prefix Length. If Prefix
> Length is greater than 64, then Length must be 3. If Prefix Length
> is greater than 0, then Length must be 2 or 3. If Prefix Length is
> zero, then Length must be 1, 2, or 3.
This text might be placed by moving up to the desription of the
"Length" field.
> The Prefix field is 0, 8, or 16 octets depending on Length.
Move sentence to description of Prefix field?
> Routers SHOULD NOT include in a Router Advertisement two Route
> Information Options with the same Prefix and Prefix Length.
Seems like MUST NOT would be better. Is there ever a valid reason to
allow routers to include two such options?
> 3. Conceptual Model of a Host
>
> There are three possible conceptual models for host implementation
> of default router preferences and more-specific routes,
> corresponding to different levels of support. We refer to these as
> host A, host B, and host C. Note that these are really classes of
> hosts, not individual hosts.
It would be more clear to use different terminology here. Rather than
saying "host A", say something like "Type-A host", "or level-1
compliant host", etc. This change would need to be made throughout
the document.
> Host A ignores default router preferences and more-specific routes.
> Host A uses the conceptual data structures described in Neighbor
> Discovery [2].
>
More clear to say something like
Host [type] A implements Neighbor Discovery as defined in [2] and
does not implement any of the extensions described in this document.
> Host B uses a Default Router List augmented with preference values.
> Host B does not have a routing table.
replace second sentence with:
, but ignores all Route Information Options.
> Host C uses a Routing Table instead of a Default Router List. (The
> Routing Table may also subsume the Prefix List, but that is beyond
> the scope of this document.) Entries in the Routing Table have a
Host C still DOES use a Default router list of some sort, but it is
presumably integrated with the routing table.
> When a host avoids using a non-reachable router X and instead uses
> another router Y, and the host would have used router X if router X
> were reachable, then the host SHOULD probe router X's reachability
> by sending a Neighbor Solicitation. A host MUST NOT probe a router's
> reachability in the absence of useful traffic that the host would
> have sent to the router if it were reachable. In any case, these
> probes MUST be rate-limited to no more than one per minute per
> router.
details are left unspecified here, but may be significant. For one
thing, the above says "sending a Neighbor Solicitation". Is that what
a probe is? Or does sending probes include retransmitting? The
document isn't clear on this.
> When a host chooses from multiple equivalent routers, it MUST choose
> randomly.
Define random better. Is it OK to pick a random order once (when the
list is built) and then do RR on the resultant list? Or must each new
choice of a router for a destination result in new random choice? (I
would assume the former is sufficient.)
> 4. Router Configuration
applicability? intended usage, restrictions?
The preference values (both Default Router Preferences and Route
Preferences) should not be routing metrics or automatically derived
from metrics: the preference values should be configured. The High
and Low (non-default) preference values should only be used when
someone with knowledge of both routers and the network topology
configures them explicitly. For example, it could be a common
network administrator, or it could be a customer request to
different administrators managing the routers.
Not clear this is workable in practice.
An administrator of a router may configure the router to advertise
specific routes for directly connected subnets and any shorter
prefixes (eg, site, NLA, or TLA prefixes) for networks to which the
router belongs.
Nit: TLA/NLA terminology is no longer in use.
Separate references into normative/non-normative sections.
Thomas
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
