Using RPSL in Practice
RFC 2650

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

Network Working Group                                           D. Meyer
Request for Comments: 2650                                 Cisco Systems
Category: Informational                                       J. Schmitz
                                                         America On-Line
                                                               C. Orange
                                                                RIPE NCC
                                                                M. Prior
                                                                 Connect
                                                         C. Alaettinoglu
                                                                 USC/ISI
                                                             August 1999

                         Using RPSL in Practice

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document is a tutorial on using the Routing Policy Specification
   Language (RPSL) to describe routing policies in the Internet Routing
   Registry (IRR). We explain how to specify various routing policies
   and configurations using RPSL, how to register these policies in the
   IRR, and how to analyze them using the routing policy analysis tools,
   for example to generate vendor specific router configurations.

1 Introduction

   This document is a tutorial on RPSL and is targeted towards an
   Internet/Network Service Provider (ISP/NSP) engineer who understands
   Internet routing, but is new to RPSL and to the IRR. Readers are
   referred to the RPSL reference document (RFC 2622) [1] for
   completeness.  It is also good to have that document at hand while
   working through this tutorial.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

Meyer, et al.                Informational                      [Page 1]
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