A BGP/IDRP Route Server alternative to a full mesh routing
RFC 1863

Document Type RFC - Historic (October 1995; No errata)
Obsoleted by RFC 4223
Author Dimitry Haskin 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 1863 (Historic)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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.


   This document describes the use and detailed design of Route Servers
   for dissemination of routing information among BGP/IDRP speaking

   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

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
Show full document text