Internet Draft David Meyer
Expires January 29, 1998 University of Oregon
draft-ietf-rps-appl-rpsl-01.txt Joachim Schmitz
DFN-NOC
Cengiz Alaettinoglu
USC/ISI
July 29, 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-01.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 specifying routing
policies using RPSL, registering these policies in the Internet Routing
Registry (IRR), and analysing 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 is new to RPSL and to IRR. Readers are referred to the RPSL
reference document [3] 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
Internet Draft Application of RPSL July 29, 1997
sites: CA*Net registry in Canada, ANS, MCI and RADB registries in the
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, you may 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 [4, 5]. 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 [4, 5].
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 aut-num object of the
ISP. These relations form sets of objects, we can then use these sets to
specify policies collectively to all their members. For example, we can
specify policy against all routes of an ISP, by refering to the AS number of
the ISP. 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. Figure 1 illustrates the use of the whois
command to obtain the route object for 128.223.0.0/16. The output of the
whois command is the ASCII representation of the route object. We will
describe the details of the route object 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 [1] 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.
Meyer et. al. Expires January 29, 1998 [Page 2]
Internet Draft Application of RPSL July 29, 1997
% 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: meyer@ns.uoregon.edu 19960222
source: RADB
Figure 1: whois command and a route object.
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 electronic mail to a registry robot. The
email addresses for existing registries are listed in Figure 2. 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.
Meyer et. al. Expires January 29, 1998 [Page 3]
Internet Draft Application of RPSL July 29, 1997
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 2: Registry email addresses to register policy objects in IRR.
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 objects in the
IRR. Registering a mntner object is the first step in creating policies
for an AS. An example is shown in Figure 3. 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 3, 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
------------------------------
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.
Meyer et. al. Expires January 29, 1998 [Page 4]
Internet Draft Application of RPSL July 29, 1997
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 3: Maintainer Object
IRR for its AS. Figure 4 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 3.
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
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.
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 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; that is,
announce internal routes of AS3582. These routes are those in route objects
where the origin attribute is AS3582.
The aut-num object forms the basis of a scalable and maintainable router
Meyer et. al. Expires January 29, 1998 [Page 5]
Internet Draft Application of RPSL July 29, 1997
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 4: Autonomous System Object
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.
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 is given in Figure 5.
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.
Meyer et. al. Expires January 29, 1998 [Page 6]
Internet Draft Application of RPSL July 29, 1997
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: meyer@ns.uoregon.edu 960222
source: RADB
Figure 5: Example of a route object
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 [8] 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 [1] 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 (please see Figure 6). 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
Meyer et. al. Expires January 29, 1998 [Page 7]
Internet Draft Application of RPSL July 29, 1997
interface to the IRR for route objects. Further information on peval and
roe is available together with the RAToolSet [1].
Figure 6: route object editor (roe).
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
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 7, an as-set called AS-NERO-PARTNERS and
containing AS3701, AS4201, AS3582, AS4222, AS1798 is defined. The as-set
Meyer et. al. Expires January 29, 1998 [Page 8]
Internet Draft Application of RPSL July 29, 1997
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
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 7: 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-SETs.
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 8 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.
Meyer et. al. Expires January 29, 1998 [Page 9]
Internet Draft Application of RPSL July 29, 1997
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: AS3582:RS-MARTIANS
remarks: routes not accepted from any peer
members: 0.0.0.0/0, # default route
0.0.0.0/0^32, # host routes
224.0.0.0/3^4-32, # multicast routes
127.0.0.0/8^9-32, . . .
Figure 8: 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 9 illustrates one way of expressing these policies using RPSL where
AS3701 is the provider and AS3582 is the customer. Refer to Figure 4 for
AS3582's aut-num.
In this example, ``announce ANY'' means export any route that AS3701 has
in its routing table, 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 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
------------------------------
2. AS-PATH regular expressions are POSIX compliant regular expressions,
see section 3.3.
Meyer et. al. Expires January 29, 1998 [Page 10]
Internet Draft Application of RPSL July 29, 1997
aut-num: AS3701
as-name: NERO-NET
descr: Network for Engineering and Research in Oregon
...
import: from AS3582 accept <^AS3582$>
export: to AS3582 announce ANY
...
admin-c: DMM65
tech-c: DMM65
notify: noc@nero.net
mnt-by: MAINT-AS3701
changed: meyer@antc.uoregon.edu 970316
source: RADB
Figure 9: Provider-Customer Policies in RPSL
its own customers, the set of routes passed to the provider includes its
customers' routes as illustrated in Figure 10. In this example, ``accept
AS3582:AS-PARTNERS'' means that for each AS X in the set defined by
AS3582:AS-PARTNERS accept AS X's routes.
aut-num: AS4600
as-name: NERO-TRANSIT
descr: Network for Engineering and Research in Oregon
...
import: from AS3701 accept <^A3701+ (AS3582:AS-PARTNERS)*$>
export: to AS3701 announce ANY
...
admin-c: DMM65
tech-c: DMM65
notify: noc@nero.net
mnt-by: MAINT-AS4600
changed: meyer@antc.uoregon.edu 970316
source: RADB
Figure 10: Provider-Customer Policies in RPSL
In this case shown in Figure 10, if AS3701 gets a new customer, then it can
update the definition of the AS3582:AS-PARTNERS set to include the new AS.
The policies specified in the aut-num objects for AS4600 and AS3701 do not
change.
Meyer et. al. Expires January 29, 1998 [Page 11]
Internet Draft Application of RPSL July 29, 1997
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 11 illustrates how this is expressed using RPSL where both AS3701
and AS2914 are providers. In this example, AS3701 advertises only the AS
paths described by the AS-SET AS3582:AS-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
...
import: from AS2914 accept <^AS2914+ (AS-WNA)*$>
export: to AS2914 announce AS3582:AS-PARTNERS
...
admin-c: DMM65
tech-c: DMM65
notify: noc@nero.net
mnt-by: MAINT-AS3701
changed: meyer@antc.uoregon.edu 970316
source: RADB
Figure 11: Inter-Provider Policies in RPSL
3.3 AS Path Based Policies
Our routing policy examples have used AS path expressions in them to
describe the routes accepted from or announced to peering partners. these
expressions do not only cover the ASes themselves but also the interdomain
topology between them. 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 over AS numbers. In this section, we briefly describe their
use.
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 10 has length one and consists of AS3582 only.
Besides these positional indicators there are also operators, e.g. the
Meyer et. al. Expires January 29, 1998 [Page 12]
Internet Draft Application of RPSL July 29, 1997
+--------------------+ +--------------------+
| 7.7.7.1 |-----+ +-----| 7.7.7.2 |
| | | | | |
| AS1 | ======== | AS2 |
| | IX | | |
| | +-----| 7.7.7.3 |
+--------------------+ +--------------------+
Figure 12: Including interfaces in peerings definitions
unary postfix operators ``+'' or ``*'' as seen in figure 11 which ASes 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 ASes out of the as-set AS-WNA. No other ASes
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, please refer to the RPSL
document [3].
3.4 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. Actually, peerings
are introduced among physical routers using real IP addresses. These can be
specified in the import and export attributes. Figure 12 shows a simple
example of two ASes 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.
aut-num: AS1
import: 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
Meyer et. al. Expires January 29, 1998 [Page 13]
Internet Draft Application of RPSL July 29, 1997
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
import: 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 ASes involved.
3.5 Describing Simple Backup Connections
The specification of peerings among ASes is not limited to one router for
each AS. In figure 12 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
import: 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 assumed 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 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$>
Meyer et. al. Expires January 29, 1998 [Page 14]
Internet Draft Application of RPSL July 29, 1997
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 [9]. 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;
announce <^AS2$>
Hence, both routers will set the med to the IGP metric at that router,
causing some routes to be prefferred at one of the routers and other routes
at the other router.
3.6 Multi-Home Routing Policies using the community Attribute
RFC 1998 [7] describes the use of the BGP community attribute [6] to handle
the load balancing and backup connection of multi-homed autonomous systems.
In this section, we simply illustrates 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 13.
3.7 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 [1] provides a very nice tool which makes working with aut-num
objects much easier: the aut-num object editor aoe (please see Figure 14).
Meyer et. al. Expires January 29, 1998 [Page 15]
Internet Draft Application of RPSL July 29, 1997
as-set: AS3561:AS-PEERS
members: AS2, AS3, . . .
aut-num: AS3561
import: from AS3561:AS-PEERS
action pref = 30;
accept community.contains({3561,70})
import: from AS3561:AS-PEERS
action pref = 20;
accept community.contains({3561,80})
import: from AS3561:AS-PEERS
action pref = 10;
accept community.contains({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 13: Policy example using the community rp-attribute.
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 [1].
4 Router Configuration Using RtConfig
RtConfig is a tool developed by the Routing Arbiter project [2] 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), Connect (Australia). The next section describes a methodology for
Meyer et. al. Expires January 29, 1998 [Page 16]
Internet Draft Application of RPSL July 29, 1997
Figure 14: Autonomous System object editor (aoe).
generating vendor specific router configurations using RtConfig.(3)
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. 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
------------------------------
3. Discussion of RtConfig internals is beyond the scope of this document.
Meyer et. al. Expires January 29, 1998 [Page 17]
Internet Draft Application of RPSL July 29, 1997
operations. An example source file is shown in Figure 15. 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 [2] 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 15: 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 15 is shown in Figure 16.
References
[1] C. Alaettinouglu. RAToolSet Routing Policy Analysis Tool Set.
Marina del Rey, CA 90292, March 1996. Available from
http://www.isi.edu/ra/RAToolSet.
[2] C. Alaettinouglu. RtConfig Manual. Marina del Rey, CA 90292, March 1996.
Available from http://www.isi.edu/ra/RAToolSet.
Meyer et. al. Expires January 29, 1998 [Page 18]
Internet Draft Application of RPSL July 29, 1997
[3] C. Alaettinouglu, T. Bates, E. Gerich, D. Karrenberg, M. Terpstra, and
C. Villamizer. Routing Policy Specification Language (RPSL). Internet
Draft draft-ietf-rps-rpsl-00.txt, Network Information Center, March
1996. Revised, June 1996.
[4] T. Bates, E. Gerich, L. Joncheray, 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.
[5] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg,
M. Terpstra, and J. Yu. Representation of IP Routing Policies in
a Routing Registry. Technical Report RFC-1786, Network Information
Center, March 1995.
[6] R. Chandra, P. Traina, and T. Li. BGP Communities Attribute. Request
for Comment RFC-1997, Network Information Center, August 1996.
[7] E. Chen and T. Bates. An Application of the BGP Community Attribute in
Multi-Home Routing. Request for Comment RFC-1998, Network Information
Center, August 1996.
[8] H. Nussbacher. The CIDR FAQ. Available from
http://www.ibm.net.il/ hank/cidr.html.
[9] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). Request for
Comment RFC-1771, Network Information Center, March 1995.
Meyer et. al. Expires January 29, 1998 [Page 19]
Internet Draft Application of RPSL July 29, 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
!
Me!yothereciscorcommandset. al. Expires January 29, 1998 [Page 20]
Figure 16: Output of RtConfig
