As per Relevance of the word regional, we have this rfc below:
Network Working Group J.
Request for Comments: 1092 T. J. Watson Research
February 1989
EGP and Policy Based Routing in the New NSFNET
Status of this
This memo discusses implementation decisions for routing issues
the NSFNET, especially in the NSFNET Backbone. Of special concern
the restriction of routing information to advertize the best route
established by a policy decision. Distribution of this memo
unlimited
The NSFNET backbone routes packets between the Regionals Networks
which it is connected, (i.e., the packets arriving at a
entry node are routed to an exit node). How they travel through
network is determined by two components
the NSFNET backbone routing protocol/algorithm,
additional information about the externally connected networks
This paper is concerned with how reachability information between
external networks and the NSFNET backbone is exchanged so
packets can be routed to the correct destination by using
reasonable path
EGP as reachability
The EGP (Exterior Gateway Protocol) routing method will be used
exchange reachability information between the NSFNET backbone and
regional networks
There are several problems with using EGP as a reachability
for routing in a meshed environment. Some EGP components
further definitions for the NSFNET backbone - regional
interactions. It should be noted that the use of EGP is only
as an interim measure until better inter autonomous system
are defined and widely deployed for gateways used by
networks
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)
not fit into this model. In the NSFNET the same network may
advertized as reachable by more than one regional network
Besides the fact that the overall NSFNET does not fit into
spanning tree model there are serious concerns with the
of the "core" (central to the EGP) and its obvious deficiencies
While EGP is going to isolate intra-Regional routing from
intra-NSFNET-Backbone routing, it does not address the issue
false information which may be supplied by regional networks
EGP by itself does not protect a particular network from
and unsolicited representation by some regional network. As
example, if network N1 is reachable through regional network R
as well as through regional network R2, EGP has no provisions
specify one of these paths as a primary and one as a secondary
since there is not generally accepted interpretation of
metrics today. Also, there is nothing in EGP which can prevent
or more regional networks from advertizing other networks (
particular, networks which belong to other regional networks)
reachable with zero distance. This could result in the
of a "black hole" or at least in suboptimal IP routing
EGP by itself has no provisions to guarantee that routes
the NSFNET Backbone will be preferred over routes through
backdoor routers or vice versa
Policy Based
Looking at the problems listed above the appearance of the
factors like autonomy and mutual trust becomes obvious. While
to achieve the routing functionality required for the new
backbone we should realize that one of our primary concerns has to
the accommodation of those new factors
This means that some kind of a rudimentary Policy Based
method becomes imperative. We would like to emphasize, however,
we are not talking about complete Policy Based Routing, but that
are rather concerned about supporting a minimum subset of a
functionality to be an initial solution to the above
problems. This requires support and cooperation between
management of each of the networks connected to the NSFNET backbone
We need to support the ability of a particular network N,
belongs to one of the regional networks, to establish a
agreement with one or more regional networks of the type "network
can be reached via one or more regional networks (RN1, RN2, ...
RNx)". This allows each network to select one or
representatives at the regional network level. Once this
Rekhter [Page 2]
RFC 1092 IP EGP and Policy Based Routing February 1989
is established the information will be available to
The network which initiated the agreement
The management of the regional network(s) with whom
agreement has been established
The NSFNET backbone Network Operation Center where it will
entered into the Routing Policy Data Base which will be
through the NSFNET information services
Supporting multiple routes to the NSFNET core requires the
that for a certain network N, no regional network other than
one(s) selected by N, will advertize N as reachable,
necessitates that the NSFNET core will ignore
advertisements for network N
EGP and Rudimentary Policy Based
Each network which belongs to the NSFNET will select a
regional network as its primary representative to the NSFNET core
bilateral agreement with the management of same regional network
well as the NSFNET backbone management. The same network
furthermore select an arbitrary number of other regional networks
their secondary, tertiary, etc., representative by
bilateral agreements with the management of the
regional networks as well as the NSFNET backbone management
Reachability information supplied by each regional network will
distributed to all other NSS nodes of the NSFNET Backbone. We
like to emphasize that we are not going to flood EGP
internally within the backbone, but to rather use the
information for the interior gateway protocol, which uses the
IS-IS protocol
The implementation allows for a defined regional network to
a particular leaf network in the EGP NR packets with a distance
zero. Secondary representatives may advertize the same network
distance one or higher. If the path through the primary
representative is available all secondary paths will be ignored.
the path through the primary regional representative goes down (
will be discovered via the EGP NR information), the next path
the lowest available EGP metric will be used
We will also be able to detect and report
representations. This will be done by examining (on a
basis) all reachability information obtained via EGP. The
will be compared against the Routing Policy Data Base which will
Rekhter [Page 3]
RFC 1092 IP EGP and Policy Based Routing February 1989
information about all bilateral agreements between networks and
regional representatives. Any mismatch will cause an alarm to
Network Operations Center. For example, network N established
bilateral agreement with the regional network R1 electing it as
primary representative. The EGP NR record received from the
network R5 advertizes the network N as reachable with distance zero
By comparing the Routing Policy Data Base entry for the network
with the EGP NR record a mismatch will be detected and an alarm
forwarded to the Network Operation Center
Since the whole scheme is based on a combination of the
number and the autonomous system number, to allow for
verification, it is also important to insure the correctness of
autonomous system numbers as advertized by the regionals networks
the NSFNET core
The autonomous system number validation for each regional
will be performed at the NSS which connects the particular
network to the NSFNET backbone. All discrepancies wil be reported
the Network Operations Center
The NSFNET backbone will be considered as a separate
System with its own autonomous system number
Backbone versus Backdoor
There are instances where regional networks prefer paths through
backdoor route over paths through the NSFNET backbone. Therefore
the reachability information advertized by the NSFNET core to
regional networks (via EGP NR records) will always use a fixed
of 128 for all routes. This may aid to encourage traffic to
through backdoors, if desired and available
The regional networks can use a variety of techniques to
how they route traffic for any particular network at their
option
What do we expect from the Regional
Each regional network should get its own Autonomous System number
The connection between regional networks to NSFNET backbone will
done via EGP. It is the responsibility of the regional backbone
provide an EGP functionality via the attachment to the E-
dedicated to the regional network
The EGP functionality may require a translation of network numbers
and out of the regional network. In any case, the NSFNET
Rekhter [Page 4]
RFC 1092 IP EGP and Policy Based Routing February 1989
expects individual network numbers of the leaf networks of
regional network, as long as they should be advertised, and
announce individual networks known to the NSFNET core to the
network
The EGP support should includes the ability to configure EGP
from some statically definable configuration table. If the
metrics cannot be defined or if they are not fixed the
determination will be done by the NSFNET backbone routers, as
from their databases, themselves. In that case, it is
responsibility of the regional network to provide the NSFNET
management with the metric data to allow for proper use of metrics
We also expect each regional network to handle all
agreements with its leaf networks regarding Policy Based Routing
supply a copy of those agreements to the NSFNET backbone management
I would like to express my thanks to Barry Appelman (T.J.
Research Center, IBM Corp.) and Hans-Werner Braun (Merit) for
contributions to this document
Author's
Jacob
T.J. Watson Research
IBM
P.O. Box 218
Yorktown Heights, NY 10598
Phone: (914) 945-3896
Email: YAKOV@IBM.
Rekhter [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
