> 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.
Thanks Thomas for the detailed review!!! > 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.) Yes, originally this document was entirely optional but when I merged in load-sharing it picked up a mandatory requirement. The main rationale for merging is that both affect the same code (next-hop determination). On the other hand, it is confusing to have mandatory & optional mixed. Bob, what do you think? > 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. Section 4 specifies a couple exceptions to the usual rule that advertising preferences or specific routes requires coordinated admin of the routers. In particular, I think common scenarios like VPN or two independent ISPs should be handled correctly without coordinated admin of the routers. > 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? I view this as a quality of implementation issue. In many environments advertised preferences & routes might change rarely so a minimal implementation might choose simplicity. However my implementation does what you want - it incrementally revalidates Destination Cache Entries when routes & preferences change. > 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? I've implemented it (except for the new load-sharing part). Yes, the kernel needs to know all the routes. Keep in mind that the new Conceptual Sending Algorithm (section 3.2) applies only to hosts. Optimized router implementations, designed to support zillions of routes, are not affected. Now my route lookup is not particularly optimized so this wasn't an issue. But I have thought a bit about how I'd use a fancy longest-matching-prefix data structure. I think you could do a first tree search looking for a reachable router. If that fails, then you search again for an unreachable router. In either case, you end up at a node that has all the routes of the same length, and you pick the one with the best preference. And for load-sharing, choose randomly among the routes with the same preference. > ================ > 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? I'd like to hear from Bob on this. > > > 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. I like the analogy, but your reword is fine. > > 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? Again, I'd like to hear from Bob. > > 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/ OK > > 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. You mean you don't understand the distinction between "best default router" and "best router for default"? I have to give credit to Steve Deering for pointing it out to me. Here's the idea again (although I think section 5.1 already says this): Suppose you have a host with two next-hop routers, R1 and R2. R1 connects the host to the rest of the internet. R2 connects the host to a specific /48. 99% of the host's traffic goes to that /48. Then R2 is the best default router for the host, because sending traffic to R2 will produce the fewest Redirects. But R1 is the best router for ::/0. > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > | > > + > + > > | > | > > + Prefix > + > > | > | > > + > + > > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Shouldn't the picture show the prefix to be a variable width field? Sure, would you just use "..."? > > 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. OK > > 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? Actually, when Prf in the message header is 10, the rules say to treat the *Router Lifetime* as 0. This means there is no default route, which is like ignoring the Route Information Option. So I think the two cases are handled similarly. > > 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? Actually, ND is inconsistent wrt lifetimes. Router Lifetime is 16 bits but Prefix Lifetimes are 32 bits. > > 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. OK > > The Prefix field is 0, 8, or 16 octets depending on Length. > > Move sentence to description of Prefix field? OK > > 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? OK. I don't know of a valid reason. > > 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. OK > > 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. OK > > 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. OK > > 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. Yes, the ::/0 routes in the routing table constitute in some sense the default router list. > > 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. The probes are normal Neighbor Solicits. They will either be unicast or multicast depending on the state of the NCE. Probes are not retransmitted, unless the host continues to generate new Destination Cache Entries. To go into more detail - per the Conceptual Sending Algorithm, sometimes a host will send a packet to a reachable router instead of an otherwise-better unreachable router. If the unreachable router would have been used if it were reachable, then the host sends a probe to the unreachable router. But these probes are rate-limited, so the host doesn't send too many, and the probes are only sent if the host is continuing to generate traffic that would have been sent to the router if it were reachable. Hence, the host will notice when the unreachable router becomes reachable so the host can start to use the better router. > > 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.) Picking a random order once and then using RR would not be sufficient. It would be vulnerable to periodic application traffic patterns. On the other hand, designs that for example hash the destination address to choose among the routers should be allowed. In any case, sounds like this text will be moving to another document. > > 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. Of course if you are a network administrator managing your own routers this is workable. If you are a large customer you might have sufficient leverage. > 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. Would it be OK to mark each reference as normative/non-normative? Thanks, Rich -------------------------------------------------------------------- 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] --------------------------------------------------------------------
