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

Web Standards & Support: