Using RPSL in Practice
RFC 2650
|
| Document |
Type |
|
RFC - Informational
(August 1999; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 2650 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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
Show full document text