Subject: router selection draft comments

From: Pekka Savola <[email-masked]>
Date: Sun, 17 Mar 2002 21:33:07 +0200 (EET)

Hello all,

A couple of comments on -01 draft.  Most are just clarifications and 
similar.

--8<--

Abstract

   This document describes an optional extension to Neighbor Discovery
   Router Advertisement messages for communicating default router
   preferences and more-specific routes from routers to hosts. This
   improves the ability of hosts to pick an appropriate router,
   especially when the host is multi-homed and the routers are on
   different links. The preference values and specific routes
   advertised to hosts require administrative configuration; they are
   not automatically derived from routing tables.

==> The preference values [...] could be removed IMO: this is being overly 
verbose detail for an abstract.

1. Introduction

   Neighbor Discovery [2] specifies a conceptual model for hosts that
   includes a Default Router List and a Prefix List. Hosts send Router
   Solicitation messages and receive from routers Router Advertisement
   messages.

==> s/receive from routers Router Advertisement messages/
      receive Router Advertisement messages from routers/

   Neighbor Discovery provides a Redirect message that routers can use
   to correct a host's choice of router. A router can send a Redirect
   message to a host, telling it to use a different router for a
   specific destination. However, the Redirect functionality is limited
   to a single link. A router on one link cannot redirect a host to a
   router on another link. Hence, Redirect messages do not help multi-
   homed hosts select an appropriate router.

==> Note about on-link redirecting.  Usually, this is interpreted to mean:

      +- router1 -x - routerA -->
host -|           X
      +- router2 -x - routerB -->

the only "trivial ones" are:

traffic: host -> router1 -> router2 -> router{A,B}, router1 redirect -> 
         router2
traffic: host -> router2 -> router1 -> router{A,B}, router2 redirect -> 
         router1

One should note that on-link redirection _could_ theoretically be done for 
more complex scenarios (e.g. host -> router1 -> routerB, router1 send 
redirects to host for router2), but that would be difficult 
algorithmically.

   We use Router Advertisement messages, instead of some other protocol
   like RIP [5], is that Router Advertisements are an existing
   standard, stable protocol for router-to-host communication.

==> Because we use ...

2.2. Changes to Router Advertisement Message Format
 
   Prf (Default Router Preference)
               2-bit signed integer. Indicates whether or not to prefer
               this router over other default routers. If Router
               Lifetime is zero, it MUST be initialized to zero by the
               sender and MUST be ignored by the receiver. If the
               Reserved (10) value is received, the receiver should
               treat the RA as having a zero Router Lifetime.

==> Is there a reason to specify any behaviour for 10 at this point?

2.3. Route Information Option
   Length      1, 2, or 3 depending on Prefix Length. If Prefix Length
               is greater than 64, then Length must be at least 3. If
               Prefix Length is greater than 0, then Length must be at
               least 2. If Prefix Length is zero, then Length may be 1.

==> Perhaps it would be best by defining that Length is the length of the 
option padded up to 8-byte blocks.

3.1. Conceptual Data Structures for Hosts

   Host B uses a Default Router List augmented with preference values.
   Host B does not have a routing table. Host B uses the Default Router
   Preference value in the Router Advertisement header. Host B ignores
   Route Information Options.

==> doesn't every host have a routing table of sorts..?

   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
   prefix, prefix length, preference value, lifetime, and next-hop
   router. Host C uses both the Default Router Preference value in the
   Router Advertisement header and Route Information Options.

==> I think Routing Table shouldn't be capitalized, because it isn't an 
"official" term anywhere.

   When host C receives a Router Advertisement, it modifies its Routing
   Table as follows. If a route's lifetime is zero, the route is

==> s/If a route's/If the received route's/

   prefix, prefix length, and next-hop router. When processing a Router
   Advertisment, host C first updates a ::/0 route based on the Router

==> Advertisement

   For example, suppose a host receives a Router Advertisement from
   router X with a Router Lifetime of 100 seconds and Default Router
   Preference of Medium. The body of the Router Advertisement contains
   a Route Information Option for ::/0 with a Route Lifetime of 200
   seconds and a Route Preference of Low. After processing the Router
   Advertisement, host A will have an entry for router X in its Default
   Router List with lifetime 100 seconds. If host B receives the same
   Router Advertisement, it will have an entry in its Default Router
   List for router X with Medium preference and lifetime 100 seconds.
   Host C will have an entry in its Routing Table for ::/0 -> router X,
   with Low preference and lifetime 200 seconds.

==> Depending on the implementation, there may be a race condition if the 
implementation don't wait until the end of the processing of the whole 
message (first accept lifetime 100, pref=low for a very short time until 
the rest of the message is parsed).  I'm not sure whether this is obvious 
or not..

3.2. Conceptual Sending Algorithm for Hosts

   When host B does next-hop determination and consults its Default
   Router List, it first prefers reachable routers over non-reachable
   routers and second uses the router preference values. 

==> first .. second sounds a bit awkward: "secondarily" would perhaps be a 
bit better, or via some rephrasing.

   If all default
   routers are not reachable, then it SHOULD round-robin among them all
   regardless of preference value.

==> s/not reachable/unreachable/

==> Is this similar policy already used somewhere (e.g. RFC2461)?  Some 
comparison with "old" mechanism in this case might be in order.

   If there are no routes matching the destination, then if host C has
   a single interface then it SHOULD assume the destination is on-link.
   If host C has multiple interfaces then it SHOULD discard the packet
   and report a Destination Unreachable / No Route To Destination error
   to the upper layer.

==> how does this relate to current mechanism?

3.4. Router Reachability Probing

   When a host avoids using a non-reachable router X and instead uses a
   reachable 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. These probes MUST be rate-
   limited to no more than one per minute per router.

==> ditto.

4. Router Configuration
    As one exception to this general rule, the administrator of a router
   that does not have a connection to the internet, or is connected
   through a firewall that blocks general traffic, may configure the
   router to advertise a Low Default Router Preference.

==> usually if there is such a policy in the firewall, it's there for a 
reason, and should not be tried to be avoided.  Therefore, I think the 
firewall part of the above should be removed.

   Routers SHOULD NOT send more than 17 Route Information Options in
   Router Advertisements per link.

==> due to XXX? (MTU concerns?)

5.2. Multi-Homed Host and Isolated Network

   Here's another scenario: a multi-homed host is connected to the
   6bone/internet via router X on one link and to an isolated network
   via router Y on another link. The multi-homed host might have a
   tunnel into a fire-walled corporate network, or it might be directly
   connected to an isolated test network.

   In this situation, a multi-homed host A (which has no default router
   preferences or more-specific routes) will have no way to choose
   between the two routers X and Y on its Default Router List. Users of
   the host will see unpredictable connectivity failures, depending on
   the destination address and the choice of router.

==> just a note: in this kind of scenario, there would be static routes in 
the nodes...

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------