Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_q_t/draft-ietf-rps-appl-rpsl-00.txt

Text File | 1997-03-26 | 38KB | 987 lines

Internet Draft                                           Cengiz Alaettinoglu
Expires  September 26, 1997                                          USC/ISI
draft-ietf-rps-appl-rpsl-00.txt                                  David Meyer
                                                        University of Oregon
                                                             Joachim Schmitz
                                                                     DFN-NOC
                                                              March 26, 1997



Application of Routing Policy Specification Language (RPSL) on the Internet




Status of this Memo


This document is an Internet Draft, and can be found as
draft-ietf-rps-appl-rpsl-00.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
progress.''

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 specify routing policies.  It
covers registering policies in an Internet Routing Registry
(IRR) using RPSL, and  the use of tools  to generate vendor
specific router  configuration.  It  is targeted towards  an
Internet/Network Service  Provider (ISP/NSP)  engineer who  is
new  to  RPSL and to IRR.  Readers are  referred to the  RPSL
reference  document [1]  for completeness.    We  recommend
reading this  document  before  reading  the reference document.
We hope  that for  many cases, this  document will  be
sufficient.

IRR is a  repository of routing  policies.   It currently
consists of  five sites:  CA*Net  registry in  Canada,  ANS, MCI
and RADB  registries in  the

Internet Draft Application of RPSL              March 26, 1997

United States  of America,  and RIPE  registry in  Europe.
Each of  these sites run independent  of each  other.   However,
each  site exchanges  its data with each other at some frequency
(at  least once a day or as often  as every ten minutes).  MCI,
Ca*Net and ANS are private registries and  contain routing
policies  of MCI,  Ca*Net, ANS,  and their  customers
respectively. RADB and RIPE are public registries, and any ISP
can publish their  policies in these registries.   Since
registries exchange  their data regularly,  you need to  register
your policies  in  only one  of  them.    If you  are  an MCI,
ANS or CA*Net  customer, we recommend you  register your policies
with them.  Otherwise, please register your  policies either at
the RIPE or  RADB registry, whichever is closer to you.   We
recommend against registering  in multiple registries since  it
often  eventually leads  to inconsistent  data between the
registries.

Routing policies registered in IRR are  specified using
RPSL. RPSL is  based on an earlier language known as RIPE-181 [2,
3].  Through operational use of RIPE-181 it has become  apparent
that certain  policies cannot be  specified and a  need for  an
enhanced  and more  general language  is needed. RPSL addresses
RIPE-181's limitations.  RPSL obsoletes RIPE-181 [2, 3].

RPSL is  object oriented;  that is,  objects  contain pieces  of
policy  and administrative information.  For example, each
address prefix routed in  the inter-domain mesh is specified in a
route object and policies of each AS are specified in an aut-num
object.  Objects have relations between each  other. For example,
all route objects of an ISP refer to the Autonomous System (AS)
number of the ISP. These  relations form sets of objects.   We
can then  use these set names to specify policies collectively to
all their members. For example, we can use the  AS number of an
ISP  to specify policy against  all of its routes.   In the
following sections, we  will describe each of  these objects
(rather object classes)  in more detail  and give numerous
examples for you to create your own  objects.  In most  cases,
you should be able  to cut and paste our examples to create your
own objects.

Once you register  your policies in  IRR, they are  available for
others  to query using a  whois service.   For  example, to  see
the  route object  for 128.223.0.0/16, please try the following
UNIX command:


    % whois -h radb.ra.net 128.223.0.0/16
      route:       128.223.0.0/16
      descr:       UONet
      descr:       University of Oregon
      descr:       Computing Center
      descr:       Eugene, OR 97403-1212
      descr:       USA
      origin:      AS3582
      mnt-by:      MAINT-AS3582
      changed:     [e-mail] 960222
      source:      RADB




Alaettinoglu et.  al.          Expires  September 26, 1997          [Page 2]
Internet Draft               Application of RPSL             March 26, 1997

The output of the  command is the ASCII  representation of the
route  object whose details will be  covered in Section 2.3.
That is  not all, once  you register your policies in IRR, they
can be analyzed for consistency or  used to diagnose Internet's
operational routing problems.   RAToolSet  [5] is  a suite of
tools for  analyzing this data.   It  contains tools (RtConfig)
to configure routers, tools (prpath and  prtraceroute) to analyse
paths on  the Internet, tools (roe,  aoe and  prcheck) to
compare,  validate and  register RPSL objects, and others.

The remainder  of  this  document  is  organized  as  follows:
Section  2 introduces the fundamental RPSL objects.  Section 3
discusses implementation of various common policies using
RPSL. Finally, Section 4 describes the  use of RtConfig to
generate vendor specific router configurations.


2 RPSL Objects


This section introduces the fundamental RPSL objects required to
implement many typical Internet routing policies.  The basic
elements 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.   These
objects must  be registered in the IRR, in only one of the
existing registries.  In  general, registration is  done  by
sending  mail  to a  registry  robot. The  mail addresses are
different for different registries.  The contents of the  mail
consists of the  objects you  want to  have registered,
separated by  empty lines, and  often some  kind of
authorization (see  below).   The  registry robot automatically
processes your  mail,  entering  new objects  into  the database,
deleting old ones, or activating  changes.  Moreover, it may
send notifications and replies with an error or success report
about its actions. The first object which  has to be  registered,
normally is the  mntner.   In general, to have  it properly
authenticated, a maintainer  object is  added manually by
registry staff.   Afterwards, all  other actions should be  done
through the registry robot.  Each registry provides documentation
on how  to use it.  If problems arise your registry staff is
willing to assist you.



Alaettinoglu et.  al.          Expires  September 26, 1997          [Page 3]
Internet Draft               Application of RPSL              March 26, 1997

2.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 other  objects in  an  IRR. Registering a
mntner object  is the  first step  in creating  policies  for an
AS.  An  example  is shown  in  Figure  1.    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
NIC-handles.

The example shows  two authentication mechanisms:   CRYPT-PW and
MAIL-FROM. CRYPT-PW takes  as its  argument  a password  that  is
encrypted  with  Unix 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 maintainer(1).

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  1, the maintainer  MAINT-AS3701 is maintained  by itself.


2.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 2 shows the
aut-num for AS3582 (UONET).

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

The most important attributes  of the aut-num object  are as-in
and  as-out. The as-in clause of an aut-num  specifies import
policies, while the  as-out 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 3.

------------------------------
 1.  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.


Alaettinoglu et.  al.          Expires  September 26, 1997          [Page 4]
Internet Draft               Application of RPSL              March 26, 1997



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


                        Figure 1:  Maintainer Object



With these  clauses  the aut-num  object  shows the  relationship
to  other autonomous systems by describing the 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  ASs, AS3582 accepts routes with  ASPATHs that
begin with  AS2194 followed by  members of AS-WNA,  which is an
AS-SET (see section 2.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.

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 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.


Alaettinoglu et.  al.          Expires  September 26, 1997          [Page 5]
Internet Draft               Application of RPSL              March 26, 1997



      aut-num:     AS3582
      as-name:     UONET
      descr:       University of Oregon, Eugene OR
      as-in:       from AS3701  100 accept ANY
      as-in:       from AS4222  100 accept <^AS4222$>
      as-in:       from AS5650  100 accept <^AS5650$>
      as-in:       from AS2914  100 accept <^AS2914+ (AS-WNA)*$>
      as-in:       from AS1798  100 accept <^AS1798$>
      as-out:      to AS3701 announce AS3582
      as-out:      to AS4222 announce AS3582
      as-out:      to AS5650 announce AS3582
      as-out:      to AS2914 announce AS3582
      as-out:      to AS1798 announce AS3582
      guardian:    [e-mail]
      admin-c:     DMM65
      tech-c:      DMM65
      notify:      [e-mail]
      mnt-by:      MAINT-AS3582
      changed:     [e-mail] 970316
      source:      RADB


                    Figure 2:  Autonomous System Object


      route:       128.223.0.0/16
      descr:       UONet
      descr:       University of Oregon
      descr:       Computing Center
      descr:       Eugene, OR 97403-1212
      descr:       USA
      origin:      AS3582
      mnt-by:      MAINT-AS3582
      changed:     [e-mail] 960222
      source:      RADB

                    Figure 3:  Example of a route object


2.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 was
already given in the introduction:



Alaettinoglu et.  al.          Expires  September 26, 1997          [Page 6]
Internet Draft               Application of RPSL              March 26, 1997

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

Consequently, the  route objects  give the  routes from  this AS
which  are distributed to  peer ASs  according  to the  rules  of
the  routing  policy. Therefore, for  any route  in the  global
routing  table of  the real  world a route object  must exist in
one registry  of the IRR.  Since routes  from the global routing
table come  from external  peerings alone,  as they  are
described in the aut-num  object, only route objects  must be
registered  in the IRR which should be 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 [4] 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 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 [5]
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 -expand_all 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.
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 [5].

2.4 Set Objects

With  routing  policies it is often  necessary  to  reference
groups  of autonomous systems or  routes which  have identical
properties regarding  a


Alaettinoglu et.  al.          Expires  September 26, 1997          [Page 7]
Internet Draft               Application of RPSL              March 26, 1997

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.

2.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
4, 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.  Functionality is
the  same but syntax is different.

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 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  ASs
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  as-in clause for  the
customer contains the customer's as-set), then that customer can
modify  the set of ASs  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:    AS-NERO-PARTNERS
   members:   AS3701, AS4201, AS3582, AS4222, AS1798

   aut-num:   AS3701
   member-of: AS-NERO-PARTNERS
   ...

   aut-num:   AS4201
   member-of: AS-NERO-PARTNERS
   ...
   [etc]


                          Figure 4:  as-set Object


The ASs 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-SETs. For an AS being member of an as-set
is indicated by  the member-of attribute of the aut-num object.



Alaettinoglu et.  al.          Expires  September 26, 1997          [Page 8]
Internet Draft                Application of RPSL            March 26, 1997

2.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 specified.

Figure 5 presents some  example route-set objects. The set
rs-uo  contains two address  prefixes, namely 128.223.0.0/16
and 198.32.162.0/24. The set rs-bar contains  the members  of the
set  rs-uo and  the address  prefix 128.7.0.0/16.  The set
rs-empty contains no members.


   route-set: rs-uo
   members: 128.223.0.0/16, 198.32.162.0/24

   route-set: rs-bar
   members: 128.7.0.0/16, rs-uo

   route-set: rs-empty


                        Figure 5:  route-set Objects


3 Specifying Policies using RPSL

In this section we show how the various RPSL objects can be used
to  specify typical Internet policies.


3.1 Provider-Customer Policies


In typical customer-provider  relationships,  the customer
imports all  the routes that the provider has  and exports its
routes to  the provider.   The provider's policies are
symmetrical in the sense that it exports all  routes that it has
to the  customer,  and it  imports only  the customers
routes. Figure 6 illustrates one way of  expressing these
policies using RPSL  where AS3701 is the provider and  AS3582 is
the customer.   Refer to Figure 2  for AS3582's aut-num.

In this example, ``announce ANY'' means  export any route  that
AS3701  has registered, and  ``accept <^AS3582$>'' means  accept
only  AS3582's  routes (i.e., that  have AS-PATHs of length
one, where the AS in the path is


Alaettinoglu et.  al.          Expires  September 26, 1997          [Page 9]
Internet Draft                Application of RPSL            March 26, 1997


  aut-num:     AS3701
  as-name:     NERO-NET
  descr:       Network for Engineering and Research in Oregon
  ...
  as-in:       from AS3582 100 accept <^AS3582$>
  as-out:      to AS3582 announce ANY
  ...
  guardian:    [e-mail]
  admin-c:     DMM65
  tech-c:      DMM65
  notify:      [e-mail]
  mnt-by:      MAINT-AS3701
  changed:     [e-mail] 970316
  source:      RADB


               Figure 6:  Provider-Customer Policies in RPSL

AS3582)(2). Note that  AS3582 is  taking full  routing from
AS3701;  this can be seen in  that AS3701 is announcing  ``ANY'',
and AS3582 is  accepting ``ANY''. The  important point  in this
example is  that if  AS3582 adds  or deletes route objects, there
is no need to update the aut-num objects.   The added (or
deleted) objects  will implicitly  update AS3582's  and  AS3701's
policies, and thus affect their router configuration files.

As mentioned  above, if  the customer  is  itself a  provider,
i.e.  it  has its own  customers,  the  set of  routes  passed to
the  provider  includes its customers'  routes  as  illustrated
in  Figure  7. In  this  example, ``accept AS-NERO-PARTNERS''
means that for each  AS X in the set defined  by AS-NERO-PARTNERS
accept AS X's routes.

In this case shown in Figure 7, if AS3701 gets a new customer,
then it  can update the definition  of the AS-NERO-PARTNERS  set
to include  the new  AS. The policies specified in the aut-num
objects for AS4600 and AS3701 do  not change.


3.2 Inter-Provider Policies


In this  case, the  policies  of both  providers are  to export
only  their customer routes  to the  other provider,  and to
import only  the  customer routes of the  other provider.   This
is commonly referred  to as  peerage. Figure 8 illustrates  how
this is  expressed using RPSL  where both AS  3701 and AS AS2914
are providers.   In this  example, AS3701 advertises only  the
------------------------------
 2. AS-PATH regular expressions are POSIX compliant regular expressions, see
section 3.3.



Alaettinoglu et.  al.         Expires  September 26, 1997          [Page 10]
Internet Draft               Application of RPSL              March 26, 1997


  aut-num:     AS4600
  as-name:     NERO-TRANSIT
  descr:       Network for Engineering and Research in Oregon
  ...
  as-in:       from AS3701 100 accept <^A3701+ (AS-NERO-PARTNERS)*$>
  as-out:      to AS3701 announce ANY
  ...
  guardian:    [e-mail]
  admin-c:     DMM65
  tech-c:      DMM65
  notify:      [e-mail]
  mnt-by:      MAINT-AS4600
  changed:     [e-mail] 970316
  source:      RADB


               Figure 7:  Provider-Customer Policies in RPSL

AS paths described by the  AS-SET AS-NERO-PARTNERS (i.e.,
customer  routes). Likewise, we  filter routes  that  come from
AS2914, accepting  only  those defined by the  filter ``<^AS2914+
(AS-WNA)*$>'', i.e.,  those routes  whose AS-PATH attribute ends
with an AS in the set defined by the AS-WNA AS-SET.


  aut-num:     AS3701
  as-name:     NERO-NET
  descr:       Network for Engineering and Research in Oregon
  ...
  as-in:       from AS2914 100 accept <^AS2914+ (AS-WNA)*$>
  as-out:      to AS2914 announce AS-NERO-PARTNERS
  ...
  guardian:    [e-mail]
  admin-c:     DMM65
  tech-c:      DMM65
  notify:      [e-mail]
  mnt-by:      MAINT-AS3701
  changed:     [e-mail] 970316
  source:      RADB


                 Figure 8:  Inter-Provider Policies in RPSL



3.3 AS-PATHS


In previous  examples  of routing  policies  special expressions
have  been used to describe  the ASs accepted  from or announced
to peering  partners. Actually, these expressions do  not only
cover the  ASs themselves but  also


Alaettinoglu et.  al.         Expires  September 26, 1997          [Page 11]
Internet Draft               Application of RPSL              March 26, 1997


    +--------------------+                +--------------------+
    |            7.7.7.1 |-----+    +-----| 7.7.7.2            |
    |                    |     |    |     |                    |
    | AS1                |    ========    |                AS2 |
    |                    |    IX    |     |                    |
    |                    |          +-----| 7.7.7.3            |
    +--------------------+                +--------------------+


          Figure 9:  Including interfaces in peerings definitions

their number  and sequence. This  is achieved  by  a mechanism
known  as regular expressions.  Those familiar with the UNIX
world or with programming languages like C or perl will most
likely already understood the details  of the AS-PATHS displayed
in the examples. RPSL uses POSIX compliant regular expressions.

Regular expressions follow certain rules. Several characters
have  special meanings, e.g.  ``^'' denotes  the beginning  of a
string,  ``$'' its  end. Then it becomes obvious that the AS-PATH
<^AS3582$> accepted from AS3582  in Figure 7 has length one and
consists of AS3582 only.

Besides these positional indicators there are also operators,
e.g. the unary postfix operators ``+'' or ``*'' as seen in figure
8 which ASs are  accepted by AS2914:   <^AS2914+ (AS-WNA)*$>.
These operators  work on the  directly preceding regular
expressions, i.e. + only affects AS2914, and * only  works on
(AS-WNA). Operator ``+''  means one or  more occurrences,
operator  ``*'' means zero or more occurrences.   Now it  becomes
obvious that the  AS-PATHS accepted start with at least one
AS2914 but may as well be stuffed  allowing several occurrences
of AS2914.   Then the AS-PATH  continues with no or  any number
of any ASs out of the as-set AS-WNA. No other ASs may then
follow.

Apparently, quite complicated AS-PATHS  can be  expressed in  a
very  handy and short way. For a  complete list of  operators and
rules for  regular expressions applicable to AS-PATHS in RPSL
refer to the RPSL document [1].

3.4 Including Interfaces in Peering Definitions


In the above  examples peerings were  only given  among ASs.
However,  the peerings may be described  in much more detail  by
RPSL. Actually,  peerings are introduced among physical  routers
using real IP  addresses.  These  can be specified in the as-in
and as-out attributes.   Figure 9 shows a  simple example of two
ASs AS1 and  AS2 which  are connected to  an exchange  point
IX. While AS1 has  only one connection  to the exchange  point
via a  router interface with IP address  7.7.7.1, AS2 has  two
different connections  with IP address 7.7.7.2 and 7.7.7.3.   The
first AS  may then define its  routing policy in more detail by
specifying its boundary router.



Alaettinoglu et. al.          Expires  September 26, 1997          [Page 12]
Internet Draft               Application of RPSL              March 26, 1997

    aut-num:   AS1
    as-in:     from AS2 at 7.7.7.1 accept <^AS2$>
    ...


This is very simple  and does not  make much of a  difference
compared to  a policy where no boundary router is specified
because AS1 in this example has only one connection  to the
exchange point.    However, AS1  might want  to choose to accept
only announcements  from AS2  which come  from the  router with
IP address 7.7.7.2 and disregard router 7.7.7.3.  AS1 then
defines  the following routing policy towards AS2:


    aut-num:   AS1
    as-in:     from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2$>
    ...


So both routers  involved in  a peering may  be specified  and by
selecting certain pairs of routers other connections can be
denied.  If no routers are included in a policy clause then it
is assumed that the policy is true  for all peerings among the
ASs involved.


3.5 Describing Simple Backup Connections


The specification of  peerings among ASs  is not limited  to one
router  for each AS. In Figure 9 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 assume that AS1 wants to
use the connection to router 7.7.7.2 of AS2  during regular
operations, and router 7.7.7.3 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
    as-in:     from AS2 7.7.7.2 at 7.7.7.1 action pref=10
               from AS2 7.7.7.3 at 7.7.7.1 action pref=20
               accept <^AS2$>
    ...


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 ASs 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 as-out clause:


Alaettinoglu et. al.          Expires  September 26, 1997          [Page 13]
Internet Draft               Application of RPSL              March 26, 1997

    aut-num:   AS2
    as-out:    to AS1 7.7.7.1 at 7.7.7.2 action med=10
               to AS1 7.7.7.1 at 7.7.7.3 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 [6].


3.6 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 [5]
provides  a very nice  tool which makes  working with  aut-num
objects much easier:  the aut-num 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
ot 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 [5].


4 Router Configuration Using RtConfig


RtConfig  is  a  tool  developed  by  the  Routing  Arbiter
project  [7]) to generate vendor specific  router configurations
from the  policy data  held in the various  IRRs.   RtConfig
currently supports  Cisco,  gated and  RSd configuration formats.
RtConfig  written in C++,  C, lex,  and yacc.    It has been
publicly  available since late  1994, and is  currently being
used by several sites for  router configuration.   A few  of the
sites  currently using RtConfig include the Routing Arbiter
Project (USA), ANS (USA),  CA*Net (Canada),  IMNet (Japan),
VERIO  (USA),  Oregon-IX  (USA),  IAfrica  (South Africa).   The
next section  describes a methodology  for generating  vendor
specific router configurations using RtConfig.(3)

------------------------------
 3. Discussion of RtConfig internals is beyond the scope of this document.




Alaettinoglu et.  al.         Expires  September 26, 1997          [Page 14]
Internet Draft               Application of RPSL              March 26, 1997

4.1 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;  in particular, the
vendor specific policy configuration  will be  removed and
replaced with  RtConfig commands.  Commands  beginning with
@RtConfig  instruct RtConfig to  perform special operations.   An
example template file  is shown in Figure  10.   In this example,
commands such  as ``@RtConfig  import AS3582  198.32.162.1/32
AS3701 198.32.162.2/32''  instruct  RtConfig  to  generate
vendor  specific import policies where the router 198.32.162.1 in
AS3582 is importing  routes from router 198.32.162.2 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 [7] for additional
information).


  router    bgp 3582
  network   128.223.0.0
  !
  !       Start with access-list 100
  !
  @RtConfig set cisco`access`list`no = 100
  !
  !       NERO
  !
  neighbor 198.32.162.2 remote-as 3701
  @RtConfig set cisco`map`name = "AS3701-EXPORT"
  @RtConfig export AS3582 198.32.162.1/32 AS3701 198.32.162.2/32
  @RtConfig set cisco`map`name = "AS3701-IMPORT"
  @RtConfig import AS3582 198.32.162.1/32 AS3701 198.32.162.2/32
  !
  !       WNA/VERIO
  !
  neighbor 198.32.162.6 remote-as 2914
  @RtConfig set cisco`map`name = "AS2914-EXPORT"
  @RtConfig export AS3582 198.32.162.1/32 AS2914 198.32.162.6/32
  @RtConfig set cisco`map`name = "AS2914-IMPORT"
  @RtConfig import AS3582 198.32.162.1/32 AS2914 198.32.162.6/32
  ...


                     Figure 10:  RtConfig Template File

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,  RtConfig or command line options can be used  to
override these values).  The  result of running RtConfig on the
source file in Figure 10 is shown in Figure 11.



Alaettinoglu et. al.          Expires  September 26, 1997          [Page 15]
Internet Draft               Application of RPSL              March 26, 1997

References


 [1] C. Alaettinoglu, T.  Bates, E. Gerich, D. Karrenberg, M. Terpstra,  and
     C. Villamizer:  Routing Policy Specification Language  (RPSL), Internet
     draft, USC Information Sciences Institute, Work in Progress.

 [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] Hank  Nussbacher. The CIDR  FAQ. Tel  Aviv University  and IBM  Israel.
     http://www.ibm.net.il/~hank/cidr.html

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

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

 [7] RtConfig        as         part        of        the         RAToolSet.
     http://www.ra.net/ra/RAToolSet/RtConfig.html






Alaettinoglu et.  al.         Expires  September 26, 1997          [Page 16]
Internet Draft               Application of RPSL             March 26, 1997


  router    bgp 3582
  network   128.223.0.0
  !
  !       NERO
  !
  neighbor 198.32.162.2 remote-as 3701

  no access-list 100
  access-list 100 permit ip 128.223.0.0   0.0.0.0   255.255.0.0   0.0.0.0
  access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
  !
  !
  no route-map AS3701-EXPORT
  route-map AS3701-EXPORT permit 1
   match ip address 100
  !
  router bgp 3582
  neighbor 198.32.162.2 route-map AS3701-EXPORT out
  !
  !
  no route-map AS3701-IMPORT
  route-map AS3701-IMPORT permit 1
   set local-preference 1000
  !
  router bgp 3582
  neighbor 198.32.162.2 route-map AS3701-IMPORT in
  !
  !       WNA/VERIO
  !
  neighbor 198.32.162.6 remote-as 2914
  !
  no route-map AS2914-EXPORT
  route-map AS2914-EXPORT permit 1
   match ip address 100
  !
  router bgp 3582
  neighbor 198.32.162.6 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 \
         |6188|6971|7790|7951|8028))?$
  !
  no route-map AS2914-IMPORT
  route-map AS2914-IMPORT permit 1
   match as-path 100
   set local-preference 998
  !
  router bgp 3582
  neighbor 198.32.162.6 route-map AS2914-IMPORT in
  !
  ! other Cisco commands
  !


                         Figure 11:  Output of RtConfig


Alaettinoglu et.  al.        Expires  September 26, 1997          [Page 17]
Internet Draft               Application of RPSL             March 26, 1997