doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc1863.txt b/doc/rfc/rfc1863.txt
new file mode 100644
index 0000000..e9e7126
--- /dev/null
+++ b/doc/rfc/rfc1863.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                          D. Haskin
+Request For Comments: 1863                            Bay Networks, Inc.
+Category: Experimental                                      October 1995
+
+
+       A BGP/IDRP Route Server alternative to a full mesh routing
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes the use and detailed design of Route Servers
+   for dissemination of routing information among BGP/IDRP speaking
+   routers.
+
+   The intention of the proposed technique is to reduce overhead and
+   management complexity of maintaining numerous direct BGP/IDRP
+   sessions which otherwise might be required or desired among routers
+   within a single routing domain as well as among routers in different
+   domains that are connected to a common switched fabric (e.g. an ATM
+   cloud).
+
+1. Overview
+
+   Current deployments of Exterior Routing protocols, such as the Border
+   Gateway Protocol [BGP4] and the adaptation of the ISO Inter-Domain
+   Routing Protocol [IDRP], require that all BGP/IDRP routers, which
+   participate in inter-domain routing (border routers) and belong to
+   the same routing domain, establish a full mesh connectivity with each
+   other for purpose of exchanging routing information acquired from
+   other routing domains. In large routing domains the number of intra-
+   domain connections that needs to be maintained by each border route
+   can be significant.
+
+   In addition, it may be desired for a border router to establish
+   routing sessions with all border routers in other domains which are
+   reachable via a shared communication media. We refer to routers that
+   are directly reachable via a shared media as adjacent routers.  Such
+   direct peering allows a router to acquire "first hand" information
+   about destinations which are directly reachable through adjacent
+   routers and select the optimum direct paths to these destinations.
+   Establishment of BGP/IDRP sessions among all adjacent border routers
+   would result in a full mesh routing connectivity.  Unfortunately for
+
+
+
+Haskin                        Experimental                      [Page 1]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+   a switched media as ATM, SMDS or Frame Relay network which may
+   inter-connect a large number of routers,  due to the number of
+   connections that would be needed to maintain a full mesh direct
+   peering between the routers,  makes this approach impractical.
+
+   In order to alleviate the "full mesh" problem, this paper proposes to
+   use IDRP/BGP Route Servers which would relay external routes with all
+   of their attributes between client routers. The clients would
+   maintain IDRP/BGP sessions only with the assigned route servers
+   (sessions with more than one server would be needed if redundancy is
+   desired).  All routes that are received from a client router would be
+   propagated to other clients by the Route Server.  Since all external
+   routes and their attributes are relayed unmodified between the client
+   routers, the client routers would acquire the same routing
+   information as they would via direct peering.  We refer to such
+   arrangement as virtual peering.  Virtual peering allows client
+   routers independently apply selection criteria to the acquired
+   external routes according to their local policies as they would if a
+   direct peering were established.
+
+   The routing approach described in this paper assumes that border
+   routers possess a mechanism to resolve the media access address of
+   the next hop router for any route acquired from a virtual peer.
+
+   It is fair to note that the approach presented in this paper only
+   reduces the number of routing connection each border router needs to
+   maintain. It does not reduce the volume of routing information that
+   needs to maintained at each border router.
+
+   Besides addressing the "full mesh" problems,  the proposal attempts
+   to achieve the following goals:
+
+   - to minimize BGP/IDRP changes that need to be implemented in client
+     routers in order to inter-operate with route servers;
+
+   - to provide for redundancy of distribution of routing information to
+     route server clients;
+
+   - to minimize the amount of routing updates that have to be sent to
+     route server clients;
+
+   - to provide load distribution between route servers;
+
+   - to avoid an excessive complexity of the interactions between Route
+     Servers themselves.
+
+
+
+
+
+
+Haskin                        Experimental                      [Page 2]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+2. Terms And Acronyms
+
+   The following terms and acronyms are used in this paper:
+
+  Routing Domain     -  a collection of routers with the same set of
+                        routing policies.  For IPv4 it can be identified
+                        with an Autonomous System Number, for IPv6
+                        it can be identified with a Routing Domain
+                        Identifier.
+
+  Border Router (BR) -  a router that acquires external routes, i.e.
+                        routes to internet points outside its routing
+                        domain.
+
+  Route Server (RS)  -  a process that collects routing information
+                        from border routers and distributes this
+                        information to 'client routers'.
+
+  RS Client (RC)     -  a router than peers with an RS in order to
+                        acquire routing information.  A server's client
+                        can be a router or another route server.
+
+  RS Cluster (RSC)   -  two or more of route servers that share the same
+                        subset of clients.  A RS Cluster provides
+                        redundancy of routing information to its
+                        clients,  i.e. routing information is provided
+                        to all RS Cluster clients as long as there is
+                        at least one functional route server in the RS
+                        Cluster.
+
+  RCID             -    Cluster ID
+
+3. RS Model
+
+   In the proposed scheme a Route Server (RS) does not apply any
+   selection criteria to the routes received from border routers for the
+   purpose of distributing these routes to its clients.  All routes
+   acquired from border routers or other Route Servers are relayed to
+   the client border routers.
+
+   There can be two classes of Route Servers: Route Servers that relay
+   external routes between routers in a single routing domain and Route
+   Servers that relay external routes between border routers in
+   different routing domains.  The former are Intra-Domain Route Servers
+   and the latter are Inter-Domain Route Servers.
+
+   In the RS model proposed in this document there is no routing
+   exchange between Intra-Domain Route Servers and Inter-Domain Route
+
+
+
+Haskin                        Experimental                      [Page 3]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+   Servers.  Routes that cross a domain boundary must always pass
+   through a border router of such a domain which may apply
+   administrative filters to such routes.
+
+   Operations of Intra-Domain Route Servers and Inter-Domain Route
+   Servers are identical.
+
+   One or more Route Servers form an RS Cluster (RSC).  For redundancy's
+   sake two or more RSs can be configured to operate in an RS Cluster.
+   All route servers in an RSC share the same clients,  i.e. cluster
+   clients establish connections to all route servers in such an RSC for
+   the purpose of exchanging routing information. Each cluster is
+   assigned an unique RSC Identifier (RCID) represented by a 2-octet
+   unsigned integer.
+
+   Clusters which provide virtual connectivity between their clients
+   would be normally exchanging routing information among themselves so
+   that all external routes are propagated to all participating clients.
+
+   Though a Route Server Client (RC) can be associated with multiple
+   RSC, it seems that there is no real advantage of doing so except for
+   a short transition period to provide a graceful re-assignment from
+   one RSC to another or, if for some reason, there are multiple RS
+   groups that don't exchange routing information with each other.
+
+   The inter-cluster route exchange can be accomplished by forming a
+   full mesh routing adjacency between clusters.  In this approach,
+   illustrated in the diagram below,  each RS in each RSC would maintain
+   a routing connection with every RS in other RS clusters.  Only routes
+   that are acquired from border routers are propagated to RSs in other
+   RS clusters.
+
+         BR11   BR12   BR1n     BR21  BR22  BR2n
+           |     |  ... |        |     | ...  |
+          -----------------     ------------------
+          !  RS11  RS12   ! --- !  RS21    RS22  !
+          -----------------     ------------------
+               <RSC#1>  \           /    <RSC#2>
+                         \         /
+                       -----------------
+                       !  RS31  RS32   !   <RSC#3>
+                       -----------------
+                         |     | ... |
+                        BR31  BR32  BR3n
+
+   Another way to propagate routing information between clusters would
+   be to form a cluster hierarchy in which an RS in one cluster
+   maintains sessions only with RSs in designated clusters.  In this
+
+
+
+Haskin                        Experimental                      [Page 4]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+   approach an RS must advertise all acquired routes to an RS in another
+   cluster except the routes that are acquired from that cluster.
+   Nevertheless,  it allows for minimizing the number of routing
+   sessions which can be highly desirable in some network.  It is
+   important for the hierarchical scheme that the inter-cluster route
+   exchange links form a tree, i.e. there is only one route propagation
+   path between any two clusters, otherwise routing loops may result.
+   For detection and pruning of routing loops in a hierarchical cluster
+   topology, it is advisable to include the "RCID Path" attribute (see
+   4.3.4) in all routing updates sent between route servers. This
+   attribute lists IDs of all clusters in the route propagation path.
+   When a duplicate ID is detected in this attribute an offending route
+   needs to be discarded.
+
+   The diagram below which illustrates the hierarchical approach is
+   created from the diagram above by removing the route exchange link
+   between clusters 2 and 3.
+
+         BR11   BR12   BR1n     BR21  BR22  BR2n
+           |     |  ... |        |     | ...  |
+          -----------------     ------------------
+          !  RS11  RS12   ! --- !  RS21    RS22  !
+          -----------------     ------------------
+               <RSC#1>  \                <RSC#2>
+                         \
+                       -----------------
+                       !  RS31  RS32   !   <RSC#3>
+                       -----------------
+                         |     | ... |
+                        BR31  BR32  BR3n
+
+   It seems that the only disadvantage of the hierarchical model, is the
+   management headache of avoiding routing loops and redundant
+   information flow by insuring that inter-cluster links always form a
+   tree.  But more study is needed to fully evaluate the comparative
+   merits of the full-mesh and hierarchical models.
+
+   Since RSs in the same cluster maintain routing sessions with the same
+   set of clients, it may seem that there is no need to exchange routing
+   information between RSs in the same cluster. Nevertheless, such a
+   route exchange may help to maintain identical routing databases in
+   the servers during client acquisition periods and when a partial
+   failure may affect some routing sessions.
+
+   Route servers in the same RS cluster exchange control messages in
+   attempt to subdivide the responsibilities of providing routing
+   information to their clients.  In order to simplify the RS design,
+   the RS messaging is implemented on top of exterior protocol which is
+
+
+
+Haskin                        Experimental                      [Page 5]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+   used by route servers for the routing information exchange.
+
+4. Operation
+
+4.1 ADVERTISER Path Attribute
+
+   Route servers act as concentrators for routes acquired by border
+   routers so that the border routers need to maintain routing
+   connections with only one or two designated route servers.  Route
+   Servers distribute routing information that is provided to them by
+   the border routers to all their client.
+
+   If routing information were relayed to RS clients in UPDATE messages
+   with only those path attribute that are currently defined in the
+   BGP-4/IDRP specification, the RS clients would not be able to
+   associate external routes they receive with the border routers which
+   submitted that routes to route servers. Such an association is
+   necessary for making a correct route selection decision. Therefore,
+   the new path attribute, ADVERTISER, is defined.
+
+   The ADVERTISER is an optional non-transitive attribute that defines
+   the identifying address of the border router which originally
+   submitted the route to a router server in order for it to be relayed
+   to other RS clients. Type Code of the ADVERTISER attribute is 255.
+   This attribute must be included in every UPDATE message that is
+   relayed by route servers and must be recognized by RS clients.
+
+4.2 Route Client Operation
+
+   An RS client establishes an BGP/IDRP connection to every route server
+   in the RS cluster to which the route client is assigned.
+
+   RS clients must be able to recognize the ADVERTISER path attribute
+   that is included in all UPDATE messages received from route servers.
+   Routes received in UPDATE messages from route servers are processed
+   as if they were received directly from the border routers specified
+   in the ADVERTISER attributes of the respective updates.
+
+   If an RS client receives a route from a Intra-Domain Route Server, is
+   assumed that the border router identified in the ADVERTISER attribute
+   is located in the receiving client's own routing domain.
+
+   If an RS client receives a route from a Inter-Domain Route Server,
+   the locality of the border router identified in the ADVERTISER
+   attribute can be determined from the BGP's AS_PATH attribute or
+   IDRP's RD_PATH attribute respectively.
+
+
+
+
+
+Haskin                        Experimental                      [Page 6]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+   If no ADVERTISER attribute was included in an UPDATE message from a
+   route server it is assumed that the route server itself is the
+   advertiser of the corresponding route.
+
+   If the NEXT_HOP path attribute of an UPDATE message lists an address
+   of the receiving router itself, the route that is carried in such an
+   update message must be declared unreachable.
+
+   In addition, it is highly desirable, albeit not required,  to
+   slightly modify the "standard" BGP/IDRP operation when acquiring
+   routes from RSs:
+
+    when a route is received from an RS and a route with the completely
+    identical attributes has been previously acquired from another RS
+    in the same cluster,  the previously acquired route should be
+    replaced with the newly acquired route.  Such a route replacement
+    should not trigger any route advertisement action on behalf of the
+    route.
+
+   RSs are designed to operate in such a way that eliminates the need to
+   keep multiple copies of the same route by RS clients and minimizes
+   the possibility of a route flap when the BGP/IDRP connection to one
+   of the redundant route servers is lost.
+
+   It is attempted to subdivide the route dissemination load between
+   route servers such that only one RS provides routing updates to a
+   given client.  But since, for avoiding an excessive complexity, the
+   reconciliation algorithm does not eliminate completely the
+   possibility of races, it is still possible that a client may receive
+   updates from more than one route server.  Therefore, the client's
+   ability to discard duplicate routes may reduce the need for a bigger
+   routing database.
+
+4.3 Route Server Operation
+
+   A Route Server maintains BGP-4/IDRP sessions with its clients
+   according to the respective BGP-4/IDRP specification with exception
+   of protocol modifications outlined in this document.
+
+   UPDATE messages sent by route servers have the same format and
+   semantics as it respective BGP-4/IDRP counterparts but also carry the
+   ADVERTISER path attribute which specifies the BGP Identifier of the
+   border router that submitted the route advertised in the UPDATE
+   message. In addition, if the hierarchical model is deployed to
+   interconnect Route Server clusters, it is advisable to include the
+   "RCID Path" attribute in all routing updates sent between route
+   servers as described in 4.3.4.
+
+
+
+
+Haskin                        Experimental                      [Page 7]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+   When route servers exchange OPEN messages they include the Route
+   Server protocol version (current version is 1) as well as Cluster IDs
+   of their respective clusters in an Optional Parameter of the OPEN
+   message. The value of Parameter Type for this parameter is 255. The
+   length of the parameter data is 3 octets. The format of parameter
+   data is shown below:
+
+    +-----------------------+------------------------------------+
+    | Version = 1 (1 octet) |      Cluster ID (2 octets)         |
+    +-----------------------+------------------------------------+
+
+   Also, route servers that belong to the same cluster send to each
+   other LIST messages with lists of clients to which they're providing
+   routing information.  In the LIST message an RS specifies the Router
+   Identifier of each client to which that RS is providing routing
+   updates. Since LIST messages are relatively small there is no need to
+   add a processing complexity of generating incremental updates when a
+   list changes; instead the complete list is sent when RSs need to be
+   informed of the changes.  The format of the LIST message is presented
+   in 4.3.1.
+
+4.3.1 LIST Message Format
+
+   The LIST message contains the fixed BGP/IDRP header that is followed
+   with the fields shown below.  The type code in the fixed header of
+   the LIST message is 255.
+
+     +----------+----------+----------+----------+
+     |        Client Identifying Address         | Repeated for each
+     +-------------------------------------------+ informed client
+   The number of Client Identifying Address" fields is not encoded
+   explicitly,  but can be calculated as:
+
+     (<LIST message Length> - <Header Length>) / <Address Length>,
+
+   where <LIST message Length> is the value encoded in the fixed
+   BGP/IDRP header, <Header Length> is the length of that header, and
+   <Address Length> is 4 for IPv4 and 16 for IPv6.
+
+4.3.2 External Route Acquisition And Advertisement
+
+   A route server acquires external routes from RS clients that are also
+   border routers.  A RS also may acquire external routes from other
+   RSs.  Route servers relay all acquired routes unaltered to their
+   clients.  No route selection is performed for purpose of route re-
+   advertisement to RS clients.
+
+
+
+
+
+Haskin                        Experimental                      [Page 8]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+   While route servers receive and store routing data from all their
+   client,  Routing Servers in the same cluster coordinate their route
+   advertisement in the attempt to ensure that only one RS provides
+   routing updates to a given client.  If an RS fails,  other Route
+   Servers in the cluster take over the responsibility of providing
+   routing updates to the clients that were previously served by the
+   failed RS.  A route flap that can result from such switch-over can be
+   eliminated by the configuring client's "Hold Time" of their BGP-
+   4/IDRP sessions with the route servers to be larger than the switch-
+   over time.  The switch-over time is determined by the Hold Time of
+   BGP-4/IDRP sessions between the route servers in the cluster and the
+   period that is needed for that route servers to reconcile their route
+   advertisement responsibilities.  The reconciliation protocol is
+   described in 4.3.3.
+
+   The BGP-4/IDRP operations of route servers differs from the
+   "standard" operation in the following ways:
+
+   -    when receiving routes from another RS, the RS Client mode of
+        operation is assumed, i.e., when a route with completely
+        identical attributes has been previously acquired from an RS
+        belonging to the same cluster as the RS that advertises the new
+        route, the previously acquired route should be discarded and
+        the newly acquired route should be accepted.  Such a route
+        replacement should not trigger any route advertisement action
+        on behalf of the route.
+
+   -    all acquired routes are advertised to a client router except
+        routes which were acquired from that client (no route echoing);
+
+   -    if the hierarchical model of inter-cluster route exchange is
+        used,  all acquired routes are advertised to an RS in another
+        RSC except routes that are acquired from that RSC.  In the
+        full-mesh model, only routes which are acquired from border
+        routers are advertised to route servers in other clusters;
+
+   -    if route servers in the same RS cluster are configured to
+        exchange routing information,  only external routes that are
+        acquired from border routers are advertised to route servers in
+        the local cluster;
+
+   -    the ADVERTISER path attribute is included in every UPDATE
+        messages that is generated by RS.  This attribute must
+        specify the identifying address of the border router from which
+        information provided in UPDATE has been acquired.  All other
+        routing attributes should be relayed to RS's peers unaltered.
+
+
+
+
+
+Haskin                        Experimental                      [Page 9]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+   -    when a route advertised by to an RS by a client becomes
+        unreachable such a route needs to be declared unreachable to
+        all other clients.  In order to withdraw a route,  the route
+        server sends an UPDATE for that route to each client (except
+        the client that this route was originally acquired) with the
+        NEXT_HOP path attribute set to the address of the client to
+        which this UPDATE is sent to.  The the ADVERTISER path attribute
+        with the identifying address of the border router that
+        originally advertised the withdrawn route must be also included
+        in such an update message.
+
+   -    if the hierarchical model is deployed to interconnect Route
+        Server clusters,  it is advisable to include the RCID_PATH
+        attribute in all routing updates sent between route servers as
+        described in 4.3.4.  The RCID_PATH attribute is never included
+        in UPDATE messages sent to border routers.
+
+4.3.3 Intra-Cluster Coordination
+
+   In order to coordinate route advertisement activities,  route servers
+   which are members of the same RS cluster establish and maintain
+   BGP/IDRP connections between themselves forming a full-mesh
+   connectivity.  Normally, there is no need for more than two-three
+   route servers in one cluster.
+
+   Route servers belonging to the same cluster send to each other LIST
+   messages with lists of clients to which they're providing routing
+   information;  let's call such clients "informed clients".
+
+   Each RS maintains a separate "informed client" list for each RS in
+   the local cluster including itself.  All such lists are linked in an
+   ascending order that is determined by the number of clients in each
+   list; the order among the lists with the same number of clients is
+   determined by comparing the identifying addresses of the
+   corresponding RSs -- an RS in such a "same number of clients" subset
+   is positioned after all RSs with the lower address.
+
+   An RS can be in one of two RS coordination states: 'Initiation' and
+   'Active'.
+
+4.3.3.1 Initiation State
+
+   This is the initial state of route server that is entered upon RS
+   startup.  When the Initiation state is entered the 'InitiationTimer'
+   is started.  The Initiation state transits to the Active state upon
+   expiration of the 'InitiationTimer' or as soon as all configured
+   BGP/IDRP connections to other route servers in the local RS Cluster
+   are established and LIST messages from that route servers are
+
+
+
+Haskin                        Experimental                     [Page 10]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+   received.
+
+   In the Initiation state an RS:
+
+    o   tries to establish connections with other RSs in the local and
+        remote clusters.
+
+    o   accepts BGP/IDRP connections from client routers.
+
+    o   receives and process BGP/IDRP updates but doesn't send any
+        routing updates.
+
+    o   stores "informed client" lists received from other RSs in the
+        local cluster - a newly received list replaces the existing list
+        for the same RS. If a LIST message is received from the route
+        server in another RS cluster, it should be silently ignored.
+
+    o   initializes an empty "informed client" list for its own clients.
+    o   as soon as a BGP/IDRP connection to an RS in the same RS Cluster
+        is established, transmits an empty LIST message to such an RS.
+
+4.3.3.2 Active State
+
+This state is entered upon expiration of the 'InitiationTimer' or as
+soon as all configured BGP/IDRP connections to other route servers in
+the local RS Cluster are established and LIST messages from that route
+servers are received.
+
+In the Active state an RS:
+
+    o   continues attempts to establish connections with other route
+        servers in the local and remote clusters;
+
+    o   accepts new BGP/IDRP connections;
+
+    o   transmits a LIST message to an RS in the local cluster as soon
+        as an BGP/IDRP session with the RS is established and then
+        whenever the local "informed client" list changes;
+
+    o   receives and process BGP/IDRP updates;
+
+    o   receives and processes "informed client" lists as described
+        below:
+
+        a) If a LIST message is received from the route server in
+           another RS cluster, it should be silently ignored.
+
+
+
+
+
+Haskin                        Experimental                     [Page 11]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+        b) If a LIST message is received from a route server that
+           belongs to the same RS Cluster,  the differences between
+           the old and the new list are determined and the old "informed
+           client" list for that RS is replaced by the list from the new
+           message.  For each client that was in the old list but not in
+           the new list it is checked whether the server has
+           an established BGP/IDRP connection to that client and
+           the client is not in any of the other "informed client"
+           lists.  If both conditions are met,  the processing described
+           for a new client takes place (see 4.3.3.3).
+
+    o   for each new BGP/IDRP client (including connections established
+        in Initiation state),  decides if that client should become an
+        "informed client", i.e. whether routing updates are to be sent
+        to the client or that client has been already taken care by
+        another RS in the local cluster.  The decision process is
+        described in the next section.
+
+4.3.3.3 New Client Processing
+
+   Whenever an RS acquires a new BGP/IDRP peer it scans through all
+   "informed client" lists in order to determine if this peer has
+   already been receiving routing updates from another RS in the local
+   RS cluster.  If the identifying address of the peer is found in one
+   of the list,  no routing updates are sent to that peer.
+
+   If the peer's Router Id is not found,  the route server initiates a
+   'DelayTimer' timer for that peer and the decision is postponed until
+   that timer expires.  The delay value is calculated as followed:
+
+      the RS determines the relative position of its own "informed
+      client" list in the linked list of all "informed client" lists.
+      If such position is expressed with a number, say N,  in the 1 to
+      "maximum number of lists" range, then the delay value is set to
+      (N-1)*<DelayGranularity>.
+
+   Upon expiration of the DelayTimer,  the "informed client" lists are
+   scanned once again to see if the corresponding peer has already been
+   receiving routing updates from another RS in the local RS cluster.
+   If the Router Id of the peer is found in one of the lists as a result
+   of receiving a new LIST message, no routing updates are sent to that
+   peer.  Otherwise,  the peer's Router ID is entered in the "informed
+   client" list that belongs to the RS,  the transmission of the updated
+   LIST message is immediately scheduled, and routing updates are sent
+   to the client.
+
+   The rational for the delay is to minimize races in the decision as
+   which RS among route servers in the same RSC is going to provide
+
+
+
+Haskin                        Experimental                     [Page 12]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+   routing information to a given client.  The RS with least number of
+   "informed clients" would have a shortest delay and is the most
+   probable to win the race.  This helps to equalize the number of
+   "informed clients" between RSc in a cluster.
+
+   After an BGP/IDRP peer is placed in the "informed client" list, it is
+   only removed from the list when the BGP/IDRP connection to this peer
+   is lost.  While an RS client is in the list it is accurately updated
+   with all routing changes.
+
+4.3.3.5 Inter-RS Connection Failure
+
+   If a route server loses a routing session with a route server in the
+   same cluster,  it must consider taking the responsibilities of route
+   advertisement to the clients that are in the "informed client" list
+   of the remote route server of the failed session.
+
+   For each such client it is checked whether the server has an
+   established BGP/IDRP connection to that client and the client is not
+   in any of the "informed client" lists of active RS.  If both
+   conditions are true,  the processing described for a new client takes
+   place (see 4.3.3.3).
+
+   After advertisement responsibilities are reconciled the "informed
+   client" list associated with the failed session should be discarded.
+
+4.3.4 RCID_PATH Attribute
+
+   The RCID_PATH is an optional non-transitive attribute that is
+   composed of a sequence of RS Cluster Identifiers (RCID) that
+   identifies the RS Cluster through which routing information carried
+   in the UPDATE message has passed.  Type Code of the RCID_PATH
+   attribute is 254.  The attribute value field contains one or more RS
+   Cluster Identifiers, each encoded as a 2-octets long field.
+
+   When a route server propagates a route which has been learned from
+   nother Route Server's UPDATE message, the following is performed with
+   respect to the the RCID_PATH attribute:
+
+  -     if the destination of the route is not a route server, the
+        RCID_PATH Attribute is excluded from the UPDATE message sent to
+        that client.
+
+  -     if the destination of the route is another route server that is
+        located in the advertising server's own RS cluster,  the
+        RCID_PATH attribute is sent unmodified.
+
+
+
+
+
+Haskin                        Experimental                     [Page 13]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+  -     if the destination of the route is a route server in a different
+        RS cluster,  the advertising route server shall verify that the
+        RCID of the destination speaker's cluster is not present in
+        the RCID_PATH attribute associated with route.  If it does,
+        the route shall not be advertised and an event indicating
+        that a route loop was detected should be logged, otherwise
+        the advertising router shall prepend its own RCID to the RCID
+        sequence in the RCID_PATH attribute (put it in the leftmost
+        position).
+
+   When a route server propagates a route which has been learned from a
+   border router to another route server then:
+
+  -     if the destination of the route is a route server that is
+        located in the advertising router's own RS cluster,  an empty
+        RCID_PATH attribute shall be included in the UPDATE message
+        (an empty RCID_PATH attribute is one whose length field contains
+        the value zero).
+
+  -     if the destination of the route is a route server in a different
+        RS cluster,  the advertising route server shall include its own
+        RCID in the RCID_PATH attribute.  In this case, the RCID of
+        advertising route server will be the only entry in the RCID_PATH
+        attribute.
+
+4.3.5 NOTIFICATION Error Codes
+
+   In addition to the error codes defined in the BGP-4/IDRP
+   specification, the following error can be indicated in a NOTIFICATION
+   message that is sent by a route server:
+
+     255  LIST Message Error
+
+   The following error subcodes can be associated with the LIST Message
+   Error:
+
+     1  - Bad Address.  This subcode indicates that a Client Identifying
+          Address in the received LIST message does not represent
+          a valid network layer address of a router interface.
+
+   The following additional UPDATE error subcodes are also defined:
+
+     255 - Invalid ADVERTISER Attribute.  This subcode indicates that
+           a value of the ADVERTISER Attribute does not represent
+           a valid network layer address of a router interface.
+
+
+
+
+
+
+Haskin                        Experimental                     [Page 14]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+4.3.7 Timers
+
+   The InitiationTimer value of 5 minutes is suggested.
+
+   In order to avoid route flaps during an RS switch-over, a value of
+   DelayGranularity should be such so the maximum possible value of the
+   DelayTimer (see 4.3.3.3) combined with the Hold Time of inter-RS
+   connections would be shorter than two-third of the smallest Hold Time
+   interval of all BGP/IDRP connections between the route servers and
+   their clients (including RSs in other clusters).  So in a cluster
+   with three RSs and the respective Hold Times of 30 and 90 seconds the
+   DelayGranularity of 15 seconds would be a recommended value.
+
+   For the same reason it is recommended that the Hold Time of BGP/IDRP
+   connections between route servers in the same cluster is set to one-
+   third of the smallest Hold Time of all BGP/IDRP connections between
+   the route servers and their clients (including RSs in other
+   clusters).  So, if the smallest Hold Time of BGP/IDRP sessions with
+   clients is 90 seconds,  the recommended  value of the Hold Time of
+   BGP/IDRP connections between route servers in that cluster would be
+   30 seconds.
+
+5. Route Server Discovery
+
+   This document does not propose any mechanism for the dynamic RS
+   discovery by RS clients or/and by other route servers.  It is assumed
+   that at minimum a manual configuration will be provided in
+   participating routers to achieve the needed connectivity.
+
+7. Security Considerations
+
+   Security issues are not discussed in this document.
+
+8. Acknowledgment
+
+   Some design concepts presented in this paper benefited from
+   discussions with Tony Li (cisco Systems).
+
+   Author likes to thank John Krawczyk (Bay Networks) and Susan Harris
+   (Merit) for their review and valuable comments.
+
+   Also, author would like to thank Yakov Rekhter (IBM) for the review
+   of the earlier version of this document and constructive comments.
+
+   Special thanks to Ray Chang (Bay Networks) whose experience in
+   implementing the concepts presented in this document helped to refine
+   the route server design.
+
+
+
+
+Haskin                        Experimental                     [Page 15]
+
+RFC 1863                A BGP/IDRP Route Server             October 1995
+
+
+9. References
+
+   [BGP4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
+          (BGP-4)", RFC 1771, T.J. Watson Research Center, IBM Corp.,
+          cisco Systems, March 1995.
+
+   [IDRP] Rekhter, Y., and P. Traina, "IDRP for IPv6", Work In Progress.
+
+10. Author's Address
+
+   Dimitry Haskin
+   Bay Networks, Inc.
+   2 Federal Street
+   Billerica, MA 01821
+
+   EMail: dhaskin@baynetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haskin                        Experimental                     [Page 16]
+