[Search] [txt|ps|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 rfc2650                                  
Internet Draft                                                   David Meyer
Expires  May 18, 1999                                          Cisco Systems
draft-ietf-rps-appl-rpsl-03.txt                              Joachim Schmitz
                                                                Carol Orange
                                                                    RIPE NCC
                                                         Cengiz Alaettinoglu
                                                           November 18, 1998

                           Using RPSL in Practice

Status of this Memo

This document is an Internet Draft, and can be found as draft-ietf-rps-appl-
rpsl-03.txt in any standard internet drafts repository.  Internet Drafts are
working documents of the Internet Engineering Task Force (IETF), its  Areas,
and its Working Groups.  Note that other groups may also distribute  working
documents as Internet Drafts.

Internet Drafts  are draft  documents valid  for a  maximum of  six  months.
Internet Drafts may be  updated, replaced, or  obsoleted by other  documents
at any time.   It  is not appropriate  to use Internet  Drafts as  reference
material, or to cite  them other than  as a ``working  draft'' or ``work  in

Please check  the I-D  abstract  listing contained  in each  Internet  Draft
directory to learn the current status of this or any other Internet Draft.

1 Introduction

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.    This  document  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 [1] for completeness.   It is  also
good to have that document at hand while working through this tutorial.
Internet Draft                  Using RPSL                 November 18, 1998

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, MCI 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).   MCI,
Ca*Net and ANS are private registries which contain the routing policies  of
the networks and the customer networks of MCI, 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.  MCI, 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 [2, 3].

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

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   The output of  the
whois command is the ASCII representation of  the route object.  The  syntax
and semantics of the route object are described in Appendix A.3.  Registered
policies can also be  compared with others for  consistency and they can  be
used to diagnose operational routing problems in the Internet.

The RAToolSet [6]  is a  suite of  tools which can  be used  to analyze  the
routing registry data.  It  includes tools to configure routers  (RtConfig),
tools to analyse paths on the Internet (prpath and prtraceroute), and  tools

Meyer et.  al.                Expires  May 18, 1999                 [Page 2]

Internet Draft                  Using RPSL                 November 18, 1998

       % whois -h radb.ra.net
         descr:       UONet
         descr:       University of Oregon
         descr:       Computing Center
         descr:       Eugene, OR 97403-1212
         descr:       USA
         origin:      AS3582
         mnt-by:      MAINT-AS3582
         changed:     meyer@ns.uoregon.edu 19960222
         source:      RADB

                Figure 1:  whois command and a route object.

to compare, validate and register RPSL objects (roe, aoe and prcheck).

In the following section, we will  describe how common routing policies  can
be expressed in RPSL.  The objects themselves are  described in Appendix  A.
Authoritative information on the IRR objects,  however, should be sought  in
RFC-2280, and authoritative information on general database objects (person,
role, and maintainers) and on querying and updating the registry  databases,
should be sought in RIPE-157 [4].  Section 3.2 describes the use of RtConfig
to generate vendor specific router configurations.

2 Specifying Policy in RPSL

The  key  purpose  of  RPSL  is  to  allow  you  to  specify  your   routing
configuration in the public Internet Routing Registry (IRR), so that you and
others can check your policies and announcements for consistency.  Moreover,
in the process  of setting policies  and configuring routers,  you take  the
policies and configurations of others into account.

In this section, we  begin by showing how  some simple peering policies  can
be expressed in RPSL.  We will build on  that to introduce various  database
objects that will be needed in order to register policies in the IRR, and to
show how more complex policies and be expressed.

2.1 Common Peering Policies

The peering policies  of an  AS are registered  in an  aut-num object  which
looks something like that in  Figure 2.  We  will focus on the semantics  of

Meyer et.  al.                Expires  May 18, 1999                 [Page 3]

Internet Draft                  Using RPSL                 November 18, 1998

the import and export  attributes in which  peering policies are  expressed.
We will  also describe  some of  the  other key  attributes in  the  aut-num
object, but  the reader  should refer  to RFC-2280  or to  RIPE-157 for  the
definitive descriptions.

        aut-num:     AS2
        as-name:     CAT-NET
        descr:       Catatonic State University
        import:      from AS1 accept ANY
        import:      from AS3 accept <^AS3$>
        export:      to AS3 announce ANY
        export:      to AS1 announce AS2 AS3
        admin-c:     AO36-RIPE
        tech-c:      CO19-RIPE
        mnt-by:      OPS4-RIPE
        changed:     orange@ripe.net
        source:      RIPE

                    Figure 2:  Autonomous System Object

Now consider Figure 3.   The peering policies  expressed in the AS2  aut-num
object in  Figure 2  are  typical for  a  small service  provider  providing
connectivity for a customer  AS3 and using  AS1 for transit.   That is,  AS2
only accepts announcements from AS3 which:

 o  are originated in AS3; and

 o  have path length 1 (<^AS3$>  means that AS3 is  the first and last  path

To AS1, AS2 announces only  those routes which originate  in their AS or  in
their customer's AS.

In the example above, ``accept ANY'' in the import attribute indicates  that
AS2 will accept any  announcements that AS1 sends,  and ``announce ANY''  in
the export attribute indicates  that any route that  AS2 has in its  routing
table will be passed on to AS3.  Assuming that AS1 announces ``ANY'' to AS2,
AS2 is taking full routing from AS1.

 1.  AS-PATH regular expressions are POSIX compliant regular expressions.

Meyer et.  al.                Expires  May 18, 1999                 [Page 4]

Internet Draft                  Using RPSL                 November 18, 1998

                                       |           |
                                       |           |
                                     AS4        AS5

                     Figure 3:  Some Neighboring ASes.

Note that  with this  peering  arrangement, if  AS1  adds or  deletes  route
objects, there is no need to update  any of the aut-num objects to  continue
the full routing policy.   Added (or deleted) route objects will  implicitly
update AS1's and AS2's policies.

While the  peering policy  specified  in Figure  2  for AS2  is  common,  in
practice many peering agreements are more complex.  Before we consider  more
examples, however, let's  first consider the  aut-num object  itself.   Note
that it is just a set of attribute labels and values which can be  submitted
to one of the registry  databases.  This  particular object is specified  as
being in (or headed for) the RIPE registry (see the last line in Figure  2).
The source should  be specified as  one of  ANS, CANET, MCI,  RADB, or  RIPE
depending on the registry  in which the  object is maintained.   The  source
attribute must be specified in every database object.

It is also  worth noting  that this  object is  ``maintained by''  OPS4-RIPE
(the value of the mnt-by  attribute), which references a ``mntner''  object.
Because the aut-num object  may be used for  router configuration and  other
operational purposes, the readers need to  be able to count on the  validity
of its contents.   It is  therefore required that a  mntner be specified  in
the aut-num and in most other database objects, which means you must  create
a mntner object before you  can register your peering  policies.  For  brief
information on the ``mntner'' object and object writeability, see Appendix A
of this document.  For more extensive information on how to set up and use a
mntner to protect your database objects, see Section 2.3 of RIPE-157.

2.2 ISP Customer - Transit Provider Policies

It is  not  uncommon for  an  ISP to  acquire  connectivity from  a  transit
provider which announces all routes to it, which it in turn passes on to its
customers to allow them to access hosts on the global Internet.   Meanwhile,
the ISP will generally announce the routes of its customers networks to  the
transit ISP, making them  accessible on the  global Internet.   This is  the
service that is specified in Figure 2 for AS3.

Consider again Figure 3.   Suppose  now that AS2 wants  to provide the  same
service to AS4.  Clearly, it would  be easy to modify the import and  export
lines in the aut-num object for AS2 (Figure 2) to those shown in Figure 4.

Meyer et.  al.                Expires  May 18, 1999                 [Page 5]

Internet Draft                  Using RPSL                 November 18, 1998

        import:      from AS1 accept ANY
        import:      from AS3 accept <^AS3$>
        import:      from AS4 accept <^AS4$>
        export:      to AS3 announce ANY
        export:      to AS4 announce ANY
        export:      to AS1 announce AS2 AS3 AS4

         Figure 4:  Policy for AS3 and AS4 in the AS2 as-num object

These changes are trivial to  make of course, but  clearly as the number  of
AS2 customers grows,  it becomes  more difficult to  keep track  of, and  to
prevent errors.   Note also that  if AS1 is  selective about only  accepting
routes from the customers of AS2 from AS2, the aut-num object for AS1  would
have to be adjusted to accomadate AS2's new customer.

By using the RPSL ``as-set'' object, we can simplify this significantly.  In
Figure 5, we describe the customers of AS2.   Having this set to work  with,
we can now rewrite the policies in Figure 2 as shown in Figure 6.

        as-set:      AS2:AS-CUSTOMERS
        members:     AS3 AS4
        changed:     orange@ripe.net
        source:      RIPE

                        Figure 5:  The as-set object

        import:      from AS1 accept ANY
        import:      from AS2:AS-CUSTOMERS accept <^AS2:AS-CUSTOMERS$>
        export:      to AS2:AS-CUSTOMERS announce ANY
        export:      to AS1 announce AS2 AS2:AS-CUSTOMERS

     Figure 6:  Policy in the AS2 aut-num object for all AS2 customers

Note that if the aut-num object for AS1 contains the line:

       import:      from AS2 accept <^AS2+ AS2:AS-CUSTOMERS*$>

Meyer et.  al.                Expires  May 18, 1999                 [Page 6]

Internet Draft                  Using RPSL                 November 18, 1998

then no changes  will need  to be  made to the  aut-num objects  for AS1  or
AS2 as the AS2 customer  base grows.  The  AS numbers for new customers  can
simply be added to the as-set AS2:AS-CUSTOMERS, and everything will work  as
for the existing customers.   Clearly in  terms of readability,  scalability
and maintainability, this is a far better mechanism when compared to  adding
policy for the customer AS's  to the aut-num objects  directly.  The  policy
in this particular example states  that AS1 will accept route  announcements
from AS2 in which  the first element  of the path is  AS2, followed by  more
occurrences of AS2, and then 0 or more occurrences of any AS2 customer (e.g.
any member of the as-set AS2:AS-CUSTOMERS).

Alternatively, one may  wish to limit  the routes one  accepts from a  peer,
especially if the  peer is  a customer.    This is  recommended for  several
reasons, such as preventing  the improper use  of unassigned address  space,
and of course malicious use of another organization's address space.

Such filtering can be expressed in various ways in RPSL. Suppose the address
space has been allocated to  the ISP managing AS3 for  assignment
to its customers.   AS3 may want  to announce part or  all of this block  on
the global Internet.  Suppose AS2  wants to be certain that it only  accepts
announcements from AS3 for address space that has been properly allocated to
AS3.  AS2 might then modify the AS3 import line in Figure 2 to read:

       import:      from AS3 accept {^16-19 }

which states  that  route  announcements  for this  address  block  will  be
accepted from AS3 if they are of length upto /19.  This of course  will have
to be modified if  and when AS3 gets  more address space.   Moreover, it  is
again clear that for an ISP with  a growing or changing customer base,  this
mechanism will not scale well.

        route-set:   AS2:RS-ROUTES:AS3
        changed:     orange@ripe.net
        source:      RIPE

                      Figure 7:  The route-set object

Luckily RPSL  supports the  notion of  a ``route-set''  which, as  shown  in
Figure 7, can be  used to specify  the set of routes  that will be  accepted
from a given customer.   Given  this set (and  a similar one  for AS4),  the
manager of AS2 can  now filter on  the address space  that will be  accepted
from their customers by modifying the import lines in the AS2 aut-num object
as shown in Figure 8.

Meyer et.  al.                Expires  May 18, 1999                 [Page 7]

Internet Draft                  Using RPSL                 November 18, 1998

        import:      from AS1 accept ANY
        import:      from AS3 accept AS2:RS-ROUTES:AS3
        import:      from AS4 accept AS2:RS-ROUTES:AS4
        export:      to AS2:AS-CUSTOMERS announce ANY
        export:      to AS1 announce AS2 AS2:AS-CUSTOMERS

Figure 8:  Policy in the AS2  aut-num object for address based filtering  on
AS2 customers

Note that  this  is now  only  slightly more  complex  than the  example  in
Figure 6.  Furthermore,  nothing need be changed  in the AS2 aut-num  object
due to address  space changes  for a  customer,  and this  filtering can  be
supported without any  changes to the  AS1 aut-num object.   The  additional
complexity is due to the two  route set names being different, otherwise  we
could have combined the two  import statements into one.   Please note  that
the set names are constructed hierarchically.   The first AS number  denotes
whose sets these are,  and the  last AS number  parameterize these sets  for
each peer.  RPSL allows the peer's  AS number to be replaced by the  keyword
PeerAS. Hence,

        import:      from AS3 accept AS2:RS-ROUTES:PeerAS
        import:      from AS4 accept AS2:RS-ROUTES:PeerAS

has the same  meaning as the  corresponding import statements  in Figure  6.
This lets  us  combine  the two  import  statements  into one  as  shown  in
Figure 9.

        import:      from AS1 accept ANY
        import:      from AS2:AS-CUSTOMERS accept AS2:RS-ROUTES:PeerAS
        export:      to AS2:AS-CUSTOMERS announce ANY
        export:      to AS1 announce AS2 AS2:AS-CUSTOMERS

          Figure 9:  Policy in the AS2 aut-num object using PeerAS

2.3 Including Interfaces in Peering Definitions

In the above examples  peerings were only  given among ASes.   However,  the
peerings may be described  in much more detail  by RPSL, where peerings  can

Meyer et.  al.                Expires  May 18, 1999                 [Page 8]

Internet Draft                  Using RPSL                 November 18, 1998

    +--------------------+                +--------------------+
    |   |-----+    +-----|            |
    |                    |     |    |     |                    |
    | AS1                |    ========    |                AS2 |
    |                    |    IX    |     |                    |
    |                    |          +-----|            |
    +--------------------+                +--------------------+

          Figure 10:  Including interfaces in peerings definitions

be specified between physical routers using  IP addresses in the import  and
export attributes.  Figure  10 shows a simple example  in which AS1 and  AS2
are connected to an exchange point IX. While AS1 has only one connection  to
the exchange point via a router  interface with IP address, AS2  has
two different connections with IP address and  The first AS
may then define its routing policy in more detail by specifying its boundary

    aut-num:   AS1
    import:    from AS2 at accept <^AS2$>

Because AS1 has only one connection  to the exchange point in this  example,
this specification does  not differ from  that in which  no boundary  router
is specified.    However, AS1  might want  to choose  to  accept only  those
announcements from AS2 which  come from the router  with IP address
and disregard those announcements from router  AS1 can specify this
routing policy as follows:

    aut-num:   AS1
    import:    from AS2 at accept <^AS2$>

By selecting certain pairs of routers in a peering specification, others can
be denied.  If no routers are included in a policy clause then it is assumed
that the policy applies to all peerings among the ASes involved.

2.4 Describing Simple Backup Connections

The specification of peerings  among ASes is not  limited to one router  for
each AS. In  figure 10 one  of the two  connections of AS2  to the  exchange
point IX might be used as backup in case the other connection fails.  Let us

Meyer et.  al.                Expires  May 18, 1999                 [Page 9]

Internet Draft                  Using RPSL                 November 18, 1998

assume that AS1 wants to use the connection to router of AS2  during
regular operations, and router as backup.  In a router configuration
this may be done by setting a local  preference.  The equivalent in RPSL  is
a corresponding action definition  in the peering description.   The  action
definitions are inserted directly before the accept keyword.

    aut-num:   AS1
    import:    from AS2 at action pref=10;
               from AS2 at action pref=20;
               accept <^AS2$>

pref is different than local-pref in  that the smaller values are  preferred
over larger  values.   Actions  may also  be defined  without specifying  IP
addresses of routers.  If no routers are included in the policy clause  then
it is asumed that  the actions are  carried out for  all peerings among  the
ASes involved.

In the previous example  AS1 controls where it  sends its traffic and  which
connection is  used as  backup.    However,  AS2 may  also define  a  backup
connection in an export clause:

    aut-num:   AS2
    export:    to AS1 at action med=10;
               to AS1 at action med=20;
               announce <^AS2$>

The definition  given here  for  AS2 is  the  symmetric counterpart  to  the
routing policy of  AS1.   The selection  of routing information  is done  by
setting the multi exit discriminator metric med.  Actually, med metrics will
not be used in practice like this; they are more suitable for load balancing
including backups.   For  more details  on med  metrics refer  to the  BGP-4
RFC [7].  To use the med to achieve load balancing, one often sets it to the
``IGP metric''.  This is specified in RPSL as:

    aut-num:   AS2
    export:    to AS1 action med=igp_cost; announce <^AS2$>

Hence, both  routers will set  the med  to the  IGP metric  at that  router,
causing some routes to be preferred at  one of the routers and other  routes
at the other router.

Meyer et.  al.                Expires  May 18, 1999                [Page 10]

Internet Draft                  Using RPSL                 November 18, 1998

2.5 Multi-Home Routing Policies using the community Attribute

RFC 1998 [9] describes the use of the BGP community attribute to handle  the
load balancing and backup connection of multi-homed autonomous systems.   In
this section, we simply illustrate how those policies are specified in RPSL.

AS3561 bases  its route  selection preference  on the  community  attribute.
Other ASes may indirectly affect  AS3561's route selection by including  the
appropriate communities in their route announcements.   In our example,  AS1
is connected to AS2 and AS3 which are  both connected to AS3561.  AS1  wants
AS3561 to prefer the AS2 connection over the AS3 connection.

AS3561 prefers the routes with no community attribute followed by the routes
with community 3561:90, followed by  the routes with community 3561:80,  and
followed by the  routes with  community 3561:70.   AS1  achieves its  policy
by adding the community  3561:90 to the  routes it exports  to AS2, and  the
community 3561:80 to  the routes  it exports  to AS1.    Hence, AS3561  will
assign a lower  preference value to  the routes it  receives from AS2  (note
that, in  RPSL smaller integers  represents higher  preferences).   This  is
illustrated in Figure 11.

 as-set: AS3561:AS-PEERS
 members: AS2, AS3, . . .

 aut-num: AS3561
 import: from AS3561:AS-PEERS action pref=30; accept community(3561:70)
 import: from AS3561:AS-PEERS action pref=20; accept community(3561:80)
 import: from AS3561:AS-PEERS action pref=10; accept community(3561:90)
 import: from AS3561:AS-PEERS action pref=0;  accept ANY

 aut-num: AS1
 export: to AS2 action community.={3561,90};
         to AS3 action community.={3561,80};
         announce AS1

        Figure 11:  Policy example using the community rp-attribute.

3 Tools

In this section, we briefly  introduce a number of  tools which can be  used
to inspect data in the database, to determine optimal routing policies,  and
enter new data.

Meyer et.  al.                Expires  May 18, 1999                [Page 11]

Internet Draft                  Using RPSL                 November 18, 1998

3.1 The aut-num Object Editor

All the examples shown in the previous sections may well be edited by  hand.
They may be  extracted one  by one  from the  IRR using  the whois  program,
edited, and then handed  back to the  registry robots.   However, again  the
RAToolSet [6] provides  a very nice  tool which makes  working with  aut-num
objects much easier:  the aut-num object editor aoe (please see Figure 12).

             Figure 12:  Autonomous System object editor (aoe).

The aut-num  object  editor has  a  graphical  user interface  to  view  and
manipulate aut-num objects registered at any IRR. New aut-num objects may be
generated using templates and  submitted to the registries.   Moreover,  the
routing policy from  the databases may  be compared to  real life  peerings.
Therefore,  aoe is  highly  recommended  as  an interface  to  the  IRR  for
aut-num objects.  Further information on aoe is available together with  the
RAToolSet [6].

Meyer et.  al.                Expires  May 18, 1999                [Page 12]

Internet Draft                  Using RPSL                 November 18, 1998

3.2 Router Configuration Using RtConfig

RtConfig is  a  tool  developed  by  the  Routing  Arbiter  project  [8]  to
generate vendor specific  router configurations  from the  policy data  held
in the various  IRRs.   RtConfig  currently supports  Cisco,  gated and  RSd
configuration formats.   It  has been  publicly available  since late  1994,
and is currently being  used by many  sites for router  configuration.   The
next section describes a methodology  for generating vendor specific  router
configurations using RtConfig.(2)

3.3 Using RtConfig

The general paradigm for  using RtConfig involves  registering policy in  an
IRR, building a RtConfig source file, then running running RtConfig  against
the source  file and  the  IRR database  to  create vendor  specific  router
configuration for the specified policy.  The source file will contain vendor
specific commands as well as RtConfig commands.  To make a source file, pick
up one of your  router configuration files and  replace the vendor  specific
policy configuration commands with the RtConfig commands.

Commands beginning  with  @RtConfig  instruct RtConfig  to  perform  special
operations.   An  example  source file  is shown  in  Figure 13.    In  this
example, commands  such as  ``@RtConfig  import AS3582  AS3701'' instruct RtConfig to generate vendor specific import policies
where the  router  in AS3582  is importing  routes from  router in AS3701.  The other @RtConfig commands instruct the  RtConfig
to use certain  names and numbers  in the output  that it generates  (please
refer to RtConfig manual [8] for additional information).

Once a  source file  is created,  the  file is  processed by  RtConfig  (the
default IRR is the RADB, and the  default vendor is Cisco; however,  command
line options  can  be  used to  override  these  values).    The  result  of
running RtConfig on the source  file in Figure 13 is  shown in Figure 21  in
Appendix B.

A RPSL Database Objects

In this appendix, we introduce the  RPSL objects required to implement  many
typical Internet  routing  policies.    RFC-2280 and  RIPE-157  provide  the
authoritative description for  these objects and  for the  RPSL syntax,  but
this appendix will often be sufficient in practice.

 2.  Discussion of RtConfig internals is beyond the scope of this document.

Meyer et.  al.                Expires  May 18, 1999                [Page 13]

Internet Draft                  Using RPSL                 November 18, 1998

  router    bgp 3582
  !       Start with access-list 100
  @RtConfig set cisco_access_list_no = 100
  !       NERO
  neighbor remote-as 3701
  @RtConfig set cisco_map_name = "AS3701-EXPORT"
  @RtConfig export AS3582 AS3701
  @RtConfig set cisco_map_name = "AS3701-IMPORT"
  @RtConfig import AS3582 AS3701
  !       WNA/VERIO
  neighbor remote-as 2914
  @RtConfig set cisco_map_name = "AS2914-EXPORT"
  @RtConfig export AS3582 AS2914
  @RtConfig set cisco_map_name = "AS2914-IMPORT"
  @RtConfig import AS3582 AS2914

                     Figure 13:  RtConfig Template File

The frequently needed objects are:

 o  maintainer objects (mntner)

 o  autonomous system number objects (aut-num)

 o  route objects (route)

 o  set objects (as-set, route-set)

and they are  described in the  following sections.   To  make your  routing
policies and configuration  public, these  objects should  be registered  in
exactly one of the IRR registries.

In general, you  can register  your information by  sending the  appropriate
objects to an  email address for  the registry you  use.   The email  should
consist of the objects  you want to have  registered or modified,  separated
by empty lines,  and preceded by  some kind of  authentication details  (see
below).   The  registry robot  processes your  mail and  enters new  objects
into the database, deletes old ones  (upon request), or makes the  requested

Meyer et.  al.                Expires  May 18, 1999                [Page 14]

Internet Draft                  Using RPSL                 November 18, 1998


You will receive a response  indicating the status of  your submission.   As
the emails are handled automatically,  the response is generally very  fast.
However, it should be  remembered that a significant  number of updates  are
also sometimes submitted to the database (by other robots), so the  response
time cannot be guaranteed.   The email  addresses for submitting objects  to
the existing registries are listed in Figure 14.

                        ANS    auto-dbm@ans.net
                        CANET  auto-dbm@canet.net
                        MCI    auto-rr@mci.net
                        RADB   auto-dbm@radb.ra.net
                        RIPE   auto-dbm@ripe.net

       Figure 14:  Email addresses to register policy objects in IRR.

Because it  is  required that  a  maintainer be  specified  in many  of  the
database objects, a mntner is usually the first  to be created.  To have  it
properly authenticated, a mntner object is added manually by registry staff.
Thereafter, all database submissions, deletions and modifications should  be
done through the registry robot.

Each of the registries should can provide additional information and support
for users.  For the public registries this support is available at:
RADB  db-admin@radb.ra.net
RIPE  ripe-dbm@ripe.net

If you are using one of the private registries, your service provider should
be able to address your questions.

A.1 The Maintainer Object

The maintainer  object  is used  to  introduce some  kind  of  authorization
for  registrations.     It  lists  various  contact  persons  and  describes
security mechanisms  that  will be  applied  when updating  objects  in  the
IRR. Registering a  mntner object  is the  first step  in creating  policies
for an AS.  An example  is shown in  Figure 15.   The  maintainer is  called
MAINT-AS3701.   The  contact  person here  is  the same  for  administrative
(admin-c) and technical (tech-c) issues and is referenced by the  NIC-handle
DMM65.  NIC-handles are unique identifiers for persons in registries.  Refer
to registry documentation for further details on person objects and usage of

The example shows  two authentication mechanisms:   CRYPT-PW and  MAIL-FROM.
CRYPT-PW takes  as its  argument  a password  that  is encrypted  with  Unix

Meyer et.  al.                Expires  May 18, 1999                [Page 15]

Internet Draft                  Using RPSL                 November 18, 1998

crypt(3) routine.    When sending  updates, the  maintainer adds  the  field
password:  <cleartext password> to the beginning of any requests that are to
be authenticated.  MAIL-FROM takes an argument that is a regular  expression
which covers a set  of mail addresses.   Only users with  any of these  mail
addresses are authorized to work  with objects secured by the  corresponding

The security mechanisms of the mntner  object will only be applied on  those
objects referencing a  specific mntner  object.   The reference  is done  by
adding the attribute mnt-by to an object using the name of the mntner object
as its value.   In Figure 15, the  maintainer MAINT-AS3701 is maintained  by

mntner:      MAINT-AS3701
descr:       Network for Research and Engineering in Oregon
remark:      Internal Backbone
admin-c:     DMM65
tech-c:      DMM65
upd-to:      noc@nero.net
auth:        CRYPT-PW  949WK1mirBy6c
auth:        MAIL-FROM .*@nero.net
notify:      noc@nero.net
mnt-by:      MAINT-AS3701
changed:     meyer@antc.uoregon.edu 970318
source:      RADB

                       Figure 15:  Maintainer Object

A.2 The Autonomous System Object

The autonomous system object describes the import and export policies of  an
AS. Each organization registers an autonomous system object (aut-num) in the
IRR for its AS. Figure 16 shows the aut-num for AS3582 (UONET).

The autonomous  system  object  lists  contacts  (admin-c,  tech-c)  and  is
maintained by (mnt-by)  MAINT-AS3701 which  is the  maintainer displayed  in
Figure 15.

The most important attributes of the  aut-num object are import and  export.
The import clause of an aut-num specifies import policies, while the  export

 3.   Clearly,   neither  of  these  mechanisms  is  sufficient  to  provide
strong authentication  or  authorization.    Other public  key  (e.g.,  PGP)
authentication mechanisms are available from some of the IRRs.

Meyer et.  al.                Expires  May 18, 1999                [Page 16]

Internet Draft                  Using RPSL                 November 18, 1998

clause specifies export policies.   The corresponding  clauses allow a  very
detailed description of the routing policy of the AS specified.  The details
are given in section 2.

With these  clauses,  an aut-num  object  shows  its relationship  to  other
autonomous systems by describing its peerings.  In addition, it also defines
a routing  entity  comprising a  group  of  IP networks  which  are  handled
according to the  rules defined in  the aut-num  object.   Therefore, it  is
closely linked to route objects.

In this example, AS3582 imports all routes from AS3701 by using the  keyword
ANY. AS3582 imports only  internal routes from  AS4222, AS5650, and  AS1798.
The import policy for  for AS2914 is  slightly more complex.   Since  AS2914
provides transit to various other  ASes, AS3582 accepts routes with  ASPATHs
that begin with AS2194  followed by members  of AS-WNA, which  is an as  set
(see section A.4.1 below) describing those customers that transit AS2914.

Since AS3582 is a multi-homed stub  AS (i.e., it does not provide  transit),
its export policy consists simply of  ``announce AS3582'' clauses; that  is,
announce internal routes of AS3582.  These routes are those in route objects
where the origin attribute is AS3582.

aut-num:     AS3582
as-name:     UONET
descr:       University of Oregon, Eugene OR
import:      from AS3701 accept ANY
import:      from AS4222 accept <^AS4222$>
import:      from AS5650 accept <^AS5650$>
import:      from AS2914 accept <^AS2914+ (AS-WNA)*$>
import:      from AS1798 accept <^AS1798$>
export:      to AS3701 announce AS3582
export:      to AS4222 announce AS3582
export:      to AS5650 announce AS3582
export:      to AS2914 announce AS3582
export:      to AS1798 announce AS3582
admin-c:     DMM65
tech-c:      DMM65
notify:      nethelp@ns.uoregon.edu
mnt-by:      MAINT-AS3582
changed:     meyer@antc.uoregon.edu 970316
source:      RADB

                    Figure 16:  Autonomous System Object

The aut-num object  forms the basis  of a scalable  and maintainable  router
configuration system.   For example,  if AS3582 originates  a new route,  it
need only create a route object for  that route with origin AS3582.   AS3582

Meyer et.  al.                Expires  May 18, 1999                [Page 17]

Internet Draft                  Using RPSL                 November 18, 1998

      origin:      AS3582
      descr:       UONet
      descr:       University of Oregon
      descr:       Computing Center
      descr:       Eugene, OR 97403-1212
      descr:       USA
      mnt-by:      MAINT-AS3582
      changed:     meyer@ns.uoregon.edu 960222
      source:      RADB

                   Figure 17:  Example of a route object

can now build  configuration using  this route object  without changing  its
aut-num object.

Similarly, if  for example,  AS3701 originates  a new  route,  it need  only
create a route object for  that route with origin AS3701.   Both AS3701  and
AS3582 can now build configuration using this route object without modifying
its aut-num object.

A.3 The Route Object

In contrast  to  aut-num  objects  which  describe  propagation  of  routing
information for an autonomous system as a whole, route objects define single
routes from an AS. An example is given in Figure 17.

This route object  is maintained  by MAINT-AS3582 and  references AS3582  by
the origin attribute.  By this  reference it is grouped together with  other
routes of the same origin AS, becoming member of the routing entity  denoted
by AS3582.  The routing policies can then be defined in the aut-num  objects
for this group of routes.

Consequently, the  route objects  give the  routes from  this AS  which  are
distributed to  peer ASes  according to  the rules  of the  routing  policy.
Therefore, for any  route in the  routing tables of  the backbone routers  a
route object must exist in one of the registries in IRR. route objects  must
be registered in the IRR only for the routes seen outside your AS. Normally,
this set of external routes is different from the routes internally  visible
within your AS.  One of the  major reasons  is that external  peers need  no
information at  all  about your  internal  routing specifics.     Therefore,
external routes are in general  aggregated combinations of internal  routes,
having shorter IP  prefixes where  applicable according to  the CIDR  rules.
Please see the  CIDR FAQ  [5] for  a tutorial  introduction to  CIDR. It  is
strongly recommended that  you aggregate  your routes as  much as  possible,
thereby minimizing the number of routes  you inject into the global  routing

Meyer et.  al.                Expires  May 18, 1999                [Page 18]

Internet Draft                  Using RPSL                 November 18, 1998

table and  at the  same  time reducing  the  corresponding number  of  route
objects in the IRR.

While you may easily query single route objects using the whois program, and
submit objects via mail to the registry robots, this becomes kind of awkward
for larger sets.  The RAToolSet [6] offers several tools to make handling of
route objects easier.   If  you want to  read policy data  from the IRR  and
process it by other programs, you  might be interested in using peval  which
is a low level policy evaluation tool.  As an example, the command

    peval -h radb.ra.net AS3582

will give you all route objects from AS3582 registered with RADB.

A much more sophisticated  tool from the RAToolSet  to handle route  objects
interactively is the route object editor roe (please see Figure 18).  It has
a graphical user interface to  view and manipulate route objects  registered
at any IRR. New route objects may be generated from templates and  submitted
to the registries.   Moreover, the route objects  from the databases may  be
compared to real life routes.   Therefore, roe  is highly recommended as  an
interface to the IRR for  route objects.   Further information on peval  and
roe is available together with the RAToolSet [6].

A.4 Set Objects

With  routing  policies  it  is  often  necessary  to  reference  groups  of
autonomous systems or  routes which  have identical  properties regarding  a
specific policy.   To make working  with such groups  easier RPSL allows  to
combine them in set objects.   There are two  basic types of predefined  set
objects, as-set, and route-set.  The RPSL set objects are described below.

A.4.1 AS-SET Object

Autonomous system set objects (as-set)  are used to group autonomous  system
objects into  named sets.    An as-set  has an  RPSL name  that starts  with
``AS-''.  In the example in Figure 19, an as-set called AS-NERO-PARTNERS and
containing AS3701, AS4201, AS3582,  AS4222, AS1798 is  defined.  The  as-set
is the RPSL replacement  for the RIPE-181  as-macro.   It has been  extended
to include ASes in  the set indirectly  by referencing as  set names in  the
aut-num objects.

AS-SETs are particularly  useful when  specifying policies  for groups  such
as customers, providers,  or for transit.   You  are encouraged to  register
sets for these groups  because it is  most likely that  you will treat  them
alike, i.e.  you  will have  a  very similar  routing  policy for  all  your

Meyer et.  al.                Expires  May 18, 1999                [Page 19]

Internet Draft                  Using RPSL                 November 18, 1998

                   Figure 18:  route object editor (roe).

customers which have an  autonomous system of  their own.   You may as  well
discover that this  is also  true for the  providers you  are peering  with,
and it  is most  convenient to  have the  ASes combined  in one  as-set  for
which you offer transit.  For  example, if a transit provider specifies  its
import policy using its customer's as-set  (i.e., its import clause for  the
customer contains the customer's as-set), then that customer can modify  the
set of ASes  that its transit  provider accepts from  it.   Again, this  can
be accomplished without requiring  the customer or  the transit provider  to
modify its aut-num object.

   as-set:    AS3582:AS-PARTNERS
   members:   AS3701, AS4201, AS3582, AS4222, AS1798

                         Figure 19:  as-set Object

The ASes of the set are simply compiled in a comma delimited list  following
the members attribute  of the  as-set.   This  list may  also contain  other
AS-SET names.

Meyer et.  al.                Expires  May 18, 1999                [Page 20]

Internet Draft                  Using RPSL                 November 18, 1998

A.4.2 ROUTE-SET Object

A route-set is a way to  name a group of routes.   The syntax is similar  to
the as-set.   A route-set has an  RPSL name that starts  with ``RS-''.   The
members attribute lists  the members of  the set.   The value  of a  members
attribute is a list of  address prefixes, or route-set  names.  The  members
of the route-set are the address prefixes  or the names of other route  sets

Figure 20 presents some example route-set  objects.  The set rs-uo  contains
two address  prefixes,  namely  and     The
set rs-bar contains  the members  of the set  rs-uo and  the address  prefix  The  set rs-martians illustrate the  use of range  operators.^32 are the length  32 more specifics of, i.e. the  host
routes;^+ are the more specifics of, i.e. the routes
falling into the multicast address space.   For more complete list of  range
operators please refer to RFC-2280.

   route-set: rs-uo

   route-set: rs-bar
   members:, rs-uo

   route-set: rs-martians
   remarks: routes not accepted from any peer
   members:,              # default route
  ^32,           # host routes
  ^+,          # multicast routes
  ^9-32, . . .

                       Figure 20:  route-set Objects

B Output of RtConfig:  An Example

In Figure 21, you see the result  of running RtConfig on the source file  in
Figure 13.


 [1] C.  Alaettinoglu, T.  Bates, E.  Gerich, D.  Karrenberg, D.  Meyer,  M.
     Terpstra,  and C. Villamizer:   Routing  Policy Specification  Language
     (RPSL), RFC 2280.

Meyer et. al.                Expires  May 18, 1999                 [Page 21]

Internet Draft                  Using RPSL                 November 18, 1998

 [2] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and  M. Terpstra.
     Representation of IP  Routing Policies in the RIPE database,  Technical
     Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993.

 [3] T.  Bates, E.  Gerich,  J. Joncharay,  J-M. Jouanigot,  D.  Karrenberg,
     M.  Terpstra,  and J.  Yu. Representation  of  IP Routing  Policies  in
     a  Routing  Registry,  Technical  Report  ripe-181,   RIPE,  RIPE  NCC,
     Amsterdam, Netherlands, October 1994.

 [4] A.  M. R.  Magee.  RIPE NCC  Database Documentation.  Technical  Report
     RIPE-157, RIPE NCC, Amsterdam, Netherlands, May 1997.

 [5] Hank  Nussbacher. The CIDR  FAQ. Tel  Aviv University  and IBM  Israel.

 [6] The RAToolSet. http://www.ra.net/ra/RAToolSet/

 [7] Y. Rekhter adn T. Li. A Border Gateway Protocol 4 (BGP-4).  Request for
     Comment RFC 1654. Network Information Center, July 1994.

 [8] RtConfig        as         part        of        the         RAToolSet.

 [9] E. Chen,  T. Bates. An  Application of the  BGP Community Attribute  in
     Multi-Home Routing. RFC 1998.

Meyer et.  al.                Expires  May 18, 1999                [Page 22]

Internet Draft                  Using RPSL                 November 18, 1998

  router    bgp 3582
  !       NERO
  neighbor remote-as 3701

  no access-list 100
  access-list 100 permit ip
  access-list 100 deny ip
  no route-map AS3701-EXPORT
  route-map AS3701-EXPORT permit 1
   match ip address 100
  router bgp 3582
  neighbor route-map AS3701-EXPORT out
  no route-map AS3701-IMPORT
  route-map AS3701-IMPORT permit 1
   set local-preference 1000
  router bgp 3582
  neighbor route-map AS3701-IMPORT in
  !       WNA/VERIO
  neighbor remote-as 2914
  no route-map AS2914-EXPORT
  route-map AS2914-EXPORT permit 1
   match ip address 100
  router bgp 3582
  neighbor route-map AS2914-EXPORT out
  no ip as-path access-list  100
  ip as-path access-list 100 permit ^_2914(((_[0-9]+))*_             \
        (13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937|    \
         4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \
  no route-map AS2914-IMPORT
  route-map AS2914-IMPORT permit 1
   match as-path 100
   set local-preference 998
  router bgp 3582
  neighbor route-map AS2914-IMPORT in
Me!yothereciscorcommandset.  al.                Expires  May 18, 1999                [Page 23]

                       Figure 21:  Output of RtConfig