RFC 2650 (rfc2650) - Page 2 of 26
Using RPSL in Practice
Alternative Format: Original Text Document
RFC 2650 Using RPSL in Practice August 1999
The IRR is a repository of routing policies. Currently, the IRR
repository is a set of five repositories maintained at the following
sites: the CA*Net registry in Canada, the ANS, CW and RADB
registries in the United States of America, and the RIPE registry in
Europe. The five repositories are run independently. However, each
site exchanges its data with the others regularly (at least once a
day and as often as every ten minutes). CW, CA*Net and ANS are
private registries which contain the routing policies of the networks
and the customer networks of CW, CA*Net, and ANS respectively. RADB
and RIPE are both public registries, and any ISP can publish their
policies in these registries.
The registries all maintain up-to-date copies of one another's data.
At any of the sites, the five registries can be inspected as a set.
One should refrain from registering his/her data in more than one of
the registries, as this practice leads almost invariably to
inconsistencies in the data. The user trying to interpret the data
is left in a confusing (at best) situation. CW, ANS and CA*Net
customers are generally required to register their policies in their
provider's registry. Others may register policies either at the RIPE
or RADB registry, as preferred.
RPSL is based on RIPE-181 [2, 3], a language used to register routing
policies and configurations in the IRR. Operational use of RIPE-181
has shown that it is sometimes difficult (or impossible) to express a
routing policy which is used in practice. RPSL has been developed to
address these shortcomings and to provide a language which can be
further extended as the need arises. RPSL obsoletes RIPE-181.
RPSL constructs are expressed in one or more database "objects" which
are registered in one of the registries described above. Each
database object contains some routing policy information and some
necessary administrative data. For example, an address prefix routed
in the inter-domain mesh is specified in a route object, and the
peering policies of an AS are specified in an aut-num object. The
database objects are related to each other by reference. For
example, a route object must refer to the aut-num object for the AS
in which it is originated. Implicitly, these relationships define
sets of objects, which can be used to specify policies effecting all
members. For example, we can specify a policy for all routes of an
ISP, by referring to the AS number in which the routes are registered
to be originated.
When objects are registered in the IRR, they become available for
others to query using a whois service. Figure 1 illustrates the use
of the whois command to obtain the route object for 128.223.0.0/16.
The output of the whois command is the ASCII representation of the
route object. The syntax and semantics of the route object are
Meyer, et al. Informational