EGP and policy based routing in the new NSFNET backbone
RFC 1092

Document Type RFC - Unknown (February 1989; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1092 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         J. Rekhter
Request for Comments: 1092                  T. J. Watson Research Center
                                                           February 1989

        EGP and Policy Based Routing in the New NSFNET Backbone

Status of this Memo

   This memo discusses implementation decisions for routing issues in
   the NSFNET, especially in the NSFNET Backbone.  Of special concern is
   the restriction of routing information to advertize the best route as
   established by a policy decision.  Distribution of this memo is


   The NSFNET backbone routes packets between the Regionals Networks to
   which it is connected, (i.e., the packets arriving at a backbone
   entry node are routed to an exit node).  How they travel through the
   network is determined by two components:

     the NSFNET backbone routing protocol/algorithm, and

     additional information about the externally connected networks.

   This paper is concerned with how reachability information between the
   external networks and the NSFNET backbone is exchanged so that
   packets can be routed to the correct destination by using a
   reasonable path.

EGP as reachability protocol

   The EGP (Exterior Gateway Protocol) routing method will be used to
   exchange reachability information between the NSFNET backbone and the
   regional networks.

   There are several problems with using EGP as a reachability protocol
   for routing in a meshed environment.  Some EGP components require
   further definitions for the NSFNET backbone - regional network
   interactions.  It should be noted that the use of EGP is only viewed
   as an interim measure until better inter autonomous system protocols
   are defined and widely deployed for gateways used by regional

   The following is a list of some EGP problems and issues:

      The EGP model assumes an engineered spanning tree topology,

Rekhter                                                         [Page 1]
RFC 1092            IP EGP and Policy Based Routing        February 1989

      however, the NSFNET (due to the presence of backdoor routes) does
      not fit into this model.  In the NSFNET the same network may be
      advertized as reachable by more than one regional network.
      Besides the fact that the overall NSFNET does not fit into a
      spanning tree model there are serious concerns with the concept
      of the "core" (central to the EGP) and its obvious deficiencies.

      While EGP is going to isolate intra-Regional routing from the
      intra-NSFNET-Backbone routing, it does not address the issue of
      false information which may be supplied by regional networks.
      EGP by itself does not protect a particular network from unwanted
      and unsolicited representation by some regional network.  As an
      example, if network N1 is reachable through regional network R1
      as well as through regional network R2, EGP has no provisions to
      specify one of these paths as a primary and one as a secondary,
      since there is not generally accepted interpretation of EGP
      metrics today.  Also, there is nothing in EGP which can prevent one
      or more regional networks from advertizing other networks (in
      particular, networks which belong to other regional networks) as
      reachable with zero distance.  This could result in the creation
      of a "black hole" or at least in suboptimal IP routing.

      EGP by itself has no provisions to guarantee that routes through
      the NSFNET Backbone will be preferred over routes through the
      backdoor routers or vice versa.

Policy Based Routing

   Looking at the problems listed above the appearance of the new
   factors like autonomy and mutual trust becomes obvious.  While trying
   to achieve the routing functionality required for the new NSFNET
   backbone we should realize that one of our primary concerns has to be
   the accommodation of those new factors.

   This means that some kind of a rudimentary Policy Based Routing
   method becomes imperative.  We would like to emphasize, however, that
   we are not talking about complete Policy Based Routing, but that we
   are rather concerned about supporting a minimum subset of a policy
   functionality to be an initial solution to the above mentioned
   problems.  This requires support and cooperation between the
   management of each of the networks connected to the NSFNET backbone.

   We need to support the ability of a particular network N, which
   belongs to one of the regional networks, to establish a bilateral
   agreement with one or more regional networks of the type "network N
   can be reached via one or more regional networks (RN1, RN2, ...
   RNx)".  This allows each network to select one or more
   representatives at the regional network level.  Once this agreement

Rekhter                                                         [Page 2]
Show full document text