RFC relevance of announce

As per Relevance of the word announce, we have this rfc below:

Network Working Group D.
Request for Comments: 2650 Cisco
Category: Informational J.
America On-
C.
RIPE
M.

C.
USC/
August 1999

Using RPSL in

Status of this

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

Copyright

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

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

1

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

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

Meyer, et al. Informational [Page 1]

RFC 2650 Using RPSL in Practice August 1999

The IRR is a repository of routing policies. Currently, the
repository is a set of five repositories maintained at the
sites: the CA*Net registry in Canada, the ANS, CW and
registries in the United States of America, and the RIPE registry
Europe. The five repositories are run independently. However,
site exchanges its data with the others regularly (at least once
day and as often as every ten minutes). CW, CA*Net and ANS
private registries which contain the routing policies of the
and the customer networks of CW, CA*Net, and ANS respectively.
and RIPE are both public registries, and any ISP can publish
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
the registries, as this practice leads almost invariably
inconsistencies in the data. The user trying to interpret the
is left in a confusing (at best) situation. CW, ANS and CA*
customers are generally required to register their policies in
provider's registry. Others may register policies either at the
or RADB registry, as preferred

RPSL is based on RIPE-181 [2, 3], a language used to register
policies and configurations in the IRR. Operational use of RIPE-181
has shown that it is sometimes difficult (or impossible) to express
routing policy which is used in practice. RPSL has been developed
address these shortcomings and to provide a language which can
further extended as the need arises. RPSL obsoletes RIPE-181.

RPSL constructs are expressed in one or more database "objects"
are registered in one of the registries described above.
database object contains some routing policy information and
necessary administrative data. For example, an address prefix
in the inter-domain mesh is specified in a route object, and
peering policies of an AS are specified in an aut-num object.
database objects are related to each other by reference.
example, a route object must refer to the aut-num object for the
in which it is originated. Implicitly, these relationships
sets of objects, which can be used to specify policies effecting
members. For example, we can specify a policy for all routes of
ISP, by referring to the AS number in which the routes are
to be originated

When objects are registered in the IRR, they become available
others to query using a whois service. Figure 1 illustrates the
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
route object. The syntax and semantics of the route object

Meyer, et al. Informational [Page 2]

RFC 2650 Using RPSL in Practice August 1999

described in Appendix A.3. Registered policies can also be
with others for consistency and they can be used to
operational routing problems in the Internet

% whois -h whois.ra.net 128.223.0.0/16
route: 128.223.0.0/16
descr:
descr: University of
descr: Computing
descr: Eugene, OR 97403-1212
descr:
origin: AS3582
mnt-by: MAINT-AS3582
changed: meyer@ns.uoregon.edu 19960222
source:

Figure 1: whois command and a route object

The RAToolSet [6] is a suite of tools which can be used to
the routing registry data. It includes tools to configure
(RtConfig), tools to analyze paths on the Internet (prpath
prtraceroute), and tools to compare, validate and register
objects (roe, aoe and prcheck).

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

2 Specifying Policy in

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

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

Meyer, et al. Informational [Page 3]

RFC 2650 Using RPSL in Practice August 1999

2.1 Common Peering

The peering policies of an AS are registered in an aut-num
which looks something like that in Figure 2. We will focus on
semantics of the import and export attributes in which
policies are expressed. We will also describe some of the other
attributes in the aut-num object, but the reader should refer
RFC-2622 or to RIPE-157 for the definitive descriptions

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

Figure 2: Autonomous System

Now consider Figure 3 (AS4 and AS5 in the figure will be
later). The peering policies expressed in the AS2 aut-num object
Figure 2 are typical for a small service provider
connectivity for a customer AS3 and using AS1 for transit. That is
AS2 only accepts announcements from AS3 which

o are originated in AS3;

o have paths composed of only AS3's (^ in <^AS3+$> means that AS3
the first member of the path, + means that AS3 occurs one or
times in the path, and $ means that no other AS can be present
the path after AS3) (1).

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

AS1--------AS2--------AS
| |
| |
AS4--------AS

Figure 3: Some Neighboring ASes

Meyer, et al. Informational [Page 4]

RFC 2650 Using RPSL in Practice August 1999

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

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

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

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

2.2 ISP Customer - Transit Provider

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

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

Meyer, et al. Informational [Page 5]

RFC 2650 Using RPSL in Practice August 1999

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

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

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

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

as-set: AS2:AS-
members: AS3 AS
changed: orange@ripe.
source:

Figure 5: The as-set

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

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

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

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

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

Meyer, et al. Informational [Page 6]

RFC 2650 Using RPSL in Practice August 1999

AS2, and then 0 or more occurrences of any AS2 customer (e.g.
member of the as-set AS2:AS-CUSTOMERS).

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

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

import: from AS3 accept { 7.7.0.0/16^16-19 }

which states that route announcements for this address block will
accepted from AS3 if they are of length upto /19. This of
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
changing customer base, this mechanism will not scale well

route-set: AS2:RS-ROUTES:AS
members: 7.7.0.0/16^16-19
changed: orange@ripe.
source:

Figure 7: The route-set

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

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

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

Meyer, et al. Informational [Page 7]

RFC 2650 Using RPSL in Practice August 1999

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

Hence

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

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

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

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

2.3 Including Interfaces in Peering

In the above examples peerings were only given among ASes. However
the peerings may be described in much more detail by RPSL,
peerings can be specified between physical routers using IP
in the import and export attributes. Figure 10 shows a
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
interface with IP address 7.7.7.1, AS2 has two different
with IP address 7.7.7.2 and 7.7.7.3. The first AS may then
its routing policy in more detail by specifying its boundary router

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

Figure 10: Including interfaces in peerings

Meyer, et al. Informational [Page 8]

RFC 2650 Using RPSL in Practice August 1999

aut-num: AS
import: from AS2 at 7.7.7.1 accept <^AS2+$>

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

aut-num: AS
import: from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2+$>

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

2.4 Describing Simple Backup

The specification of peerings among ASes is not limited to one
for each AS. In figure 10 one of the two connections of AS2 to
exchange point IX might be used as backup in case the
connection fails. Let us assume that AS1 wants to use the
to router 7.7.7.2 of AS2 during regular operations, and
7.7.7.3 as backup. In a router configuration this may be done
setting a local preference. The equivalent in RPSL is
corresponding action definition in the peering description.
action definitions are inserted directly before the accept keyword

aut-num: AS
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+$>

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

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

Meyer, et al. Informational [Page 9]

RFC 2650 Using RPSL in Practice August 1999

aut-num: AS
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+$>

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

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

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

2.5 Multi-Home Routing Policies using the community

RFC 1998 [9] describes the use of the BGP community attribute
provide support for load balancing and backup connections of multi
homed autonomous systems. In this section, we use
refinement of an example to illustrate how those policies might
specified using RPSL

The basic premise of RFC 1998 is to use the BGP community
to allow a customer to configure the BGP "LOCAL_PREF" on a provider'
routers. This will allow the customer to influence the provider'
route selection, normally by lowering the BGP "LOCAL_PREF"
indicate backup arrangements

In this example, we illustrate how AS1 (the provider) might
their policy so that a customer (AS4) connected to two of AS1'
direct customers (AS2 and AS3) might signal to AS1 which
is to be preferred

AS1's base policy is to only accept routes from customers that
originated by the customer, or by the customer's customers.
leads to a policy such as

Meyer, et al. Informational [Page 10]

RFC 2650 Using RPSL in Practice August 1999

aut-num: AS
import: from AS
accept (AS2 OR AS4) AND <^AS2+ AS4*$>
import: from AS
accept (AS3 OR AS4) AND <^AS3+ AS4*$>
import: from AS
accept AS5 AND <^AS5+$>

Note that AS4 is a customer of AS2 and AS3, and AS5 does not have
own customers

Now suppose we want to add some policy to describe that if a
tags a route with community 1:1 then AS1 will act on this to
the BGP "LOCAL_PREF" by 10.

aut-num: AS
import: from AS
action pref=10;
accept (AS2 OR AS4) AND <^AS2+ AS4*$>
AND community.contains(1:1)
import: from AS
action pref=0;
accept (AS2 OR AS4) AND <^AS2+ AS4*$>
import: from AS
action pref=10;
accept (AS3 OR AS4) AND <^AS3+ AS4*$>
AND community.contains(1:1)
import: from AS
action pref=0;
accept (AS3 OR AS4) AND <^AS3+ AS4*$>
import: from AS
action pref=10;
accept AS5 AND <^AS5+$> AND community.contains(1:1)
import: from AS
action pref=0;
accept AS5 AND <^AS5+$>

We can see here that basically we are adding identical statements
each peering to the policy. This is the ideal candidate for RPSL'
refine statement. This will make the policy more concise and
some of the potential for errors as more peering statements are
in the future

Meyer, et al. Informational [Page 11]

RFC 2650 Using RPSL in Practice August 1999

aut-num: AS
import: {
from AS-
action pref=10;
accept community.contains(1:1);
from AS-
action pref=0;
accept ANY
} refine {
from AS2 accept (AS2 OR AS4) AND <^AS2+ AS4*$>;
from AS3 accept (AS3 OR AS4) AND <^AS3+ AS4*$>;
from AS5 accept AS5 AND <^AS5+$>;
}

Now, we can clearly see that any route that has been accepted from
customer that contains the community 1:1 will have it's
preference value reduced by 10.

The refinement has cleaned up some of the policy but we still have
large number of individual policies representing the same
provider policy "from the customer, accept customer routes".
can be simplified by using AS sets

First, we will collect together all of AS1's customers into a
AS set, AS1:AS-CUSTOMERS. We use a hierarchical set name that
with AS1 to avoid possible set name clashes in IRR with other ASes

as-set: AS1:AS-
members: AS2, AS3, AS

We also define one set for each customer which lists the AS
of any of their customers

as-set: AS1:AS-CUSTOMERS:AS
members: AS

as-set: AS1:AS-CUSTOMERS:AS
members: AS

as-set: AS1:AS-CUSTOMERS:AS
members: # AS5 has no customers yet, so keep blank for

We can now use the keyword PeerAS with these AS sets to simplify
policy further

Meyer, et al. Informational [Page 12]

RFC 2650 Using RPSL in Practice August 1999

aut-num: AS
import: {
from AS-
action pref=10;
accept community.contains(1:1);
from AS-
action pref=0;
accept ANY
} refine {
from AS1:AS-
accept (PeerAS OR AS1:AS-CUSTOMER:PeerAS
AND <^PeerAS+ AS1:AS-CUSTOMER:PeerAS*$>
}

The use of PeerAS with AS1:AS-CUSTOMERS is basically equivalent
looping over the members of AS1:AS-CUSTOMERS, expanding the policy
replacing PeerAS with a member from the set AS1:AS-CUSTOMERS

To illustrate how this policy might be utilised by AS4, we
the following policy fragment

aut-num: AS
export: to AS
action community.append(1:1);
announce AS
export: to AS
announce AS

Here, AS4 is signalling AS1 to prefer the routes from AS3.

3

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

3.1 The aut-num Object

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

The aut-num object editor has a graphical user interface to view
manipulate aut-num objects registered at any IRR. New aut-num
may be generated using templates and submitted to the registries

Meyer, et al. Informational [Page 13]

RFC 2650 Using RPSL in Practice August 1999

Moreover, the routing policy from the databases may be compared
real life peerings. Therefore, aoe is highly recommended as
interface to the IRR for aut-num objects. Further information on
is available together with the RAToolSet [6].

3.2 Router Configuration Using

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

3.3 Using

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

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

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

Meyer, et al. Informational [Page 14]

RFC 2650 Using RPSL in Practice August 1999

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

Figure 11: RtConfig Template

Meyer, et al. Informational [Page 15]

RFC 2650 Using RPSL in Practice August 1999

A RPSL Database

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

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
routing policies and configuration public, these objects should
registered in exactly one of the IRR registries

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

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

ANS auto-dbm@ans.
CANET auto-dbm@canet.
CW auto-rr@cw.
RADB auto-dbm@ra.
RIPE auto-dbm@ripe.

Figure 12: Email addresses to register policy objects in IRR

Meyer, et al. Informational [Page 16]

RFC 2650 Using RPSL in Practice August 1999

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

Each of the registries can provide additional information and
for users. For the public registries this support is available
the email addresses listed in Figure 13.

RADB db-admin@ra.
RIPE ripe-dbm@ripe.

Figure 13: Support email addresses

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

A.1 The Maintainer

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

The example shows two authentication mechanisms: CRYPT-PW and MAIL
FROM. CRYPT-PW takes as its argument a password that is
with Unix crypt (3) routine. When sending updates, the
adds the field password: password> to the beginning
any requests that are to be authenticated. MAIL-FROM takes
argument that is a regular expression which covers a set of
addresses. Only users with any of these mail addresses
authorized to work with objects secured by the
maintainer (3).

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

Meyer, et al. Informational [Page 17]

RFC 2650 Using RPSL in Practice August 1999

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

Figure 14: Maintainer

A.2 The Autonomous System

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

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

The most important attributes of the aut-num object are import
export. The import clause of an aut-num specifies import policies
while the export clause specifies export policies. The
clauses allow a very detailed description of the routing policy
the AS specified. The details are given in section 2.

With these clauses, an aut-num object shows its relationship to
autonomous systems by describing its peerings. In addition, it
defines a routing entity comprising a group of IP networks which
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
keyword ANY. AS3582 imports only internal routes from AS4222, AS5650,
and AS1798. The import policy for for AS2914 is slightly
complex. Since AS2914 provides transit to various other ASes, AS3582
accepts routes with ASPATHs that begin with AS2194 followed
members of AS-WNA, which is an as set (see section A.4.1 below
describing those customers that transit AS2914.

Meyer, et al. Informational [Page 18]

RFC 2650 Using RPSL in Practice August 1999

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

aut-num: AS3582
as-name:
descr: University of Oregon, Eugene
import: from AS3701 accept
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.
mnt-by: MAINT-AS3582
changed: meyer@antc.uoregon.edu 970316
source:

Figure 15: Autonomous System

The aut-num object forms the basis of a scalable and

route: 128.223.0.0/16
origin: AS3582
descr:
descr: University of
descr: Computing
descr: Eugene, OR 97403-1212
descr:
mnt-by: MAINT-AS3582
changed: meyer@ns.uoregon.edu 960222
source:

Figure 16: Example of a route

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
changing its aut-num object

Meyer, et al. Informational [Page 19]

RFC 2650 Using RPSL in Practice August 1999

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

A.3 The Route

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

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

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

While you may easily query single route objects using the
program, and submit objects via mail to the registry robots,
becomes kind of awkward for larger sets. The RAToolSet [6]
several tools to make handling of route objects easier. If you
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
evaluation tool. As an example, the

peval -h whois.ra.net AS3582

will give you all route objects from AS3582 registered with RADB

Meyer, et al. Informational [Page 20]

RFC 2650 Using RPSL in Practice August 1999

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

A.4 Set

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

A.4.1 AS-SET

Autonomous system set objects (as-set) are used to group
system objects into named sets. An as-set has an RPSL name
starts with "AS-". In the example in Figure 17, an as-set
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
indirectly by referencing as set names in the aut-num objects

AS-SETs are particularly useful when specifying policies for
such as customers, providers, or for transit. You are encouraged
register sets for these groups because it is most likely that
will treat them alike, i.e. you will have a very similar
policy for all your customers which have an autonomous system
their own. You may as well discover that this is also true for
providers you are peering with, and it is most convenient to have
ASes combined in one as-set for which you offer transit.
example, if a transit provider specifies its import policy using
customer's as-set (i.e., its import clause for the customer
the customer's as-set), then that customer can modify the set of
that its transit provider accepts from it. Again, this can
accomplished without requiring the customer or the transit
to modify its aut-num object

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

Figure 17: as-set

Meyer, et al. Informational [Page 21]

RFC 2650 Using RPSL in Practice August 1999

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

A.4.2 ROUTE-SET

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

Figure 18 presents some example route-set objects. The set rs-
contains two address prefixes, namely 128.223.0.0/16
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-
illustrate the use of range operators. 0.0.0.0/0^32 are the
32 more specifics of 0.0.0.0/0, i.e. the host routes; 224.0.0.0/3^+
are the more specifics of 224.0.0.0/3, i.e. the routes falling
the multicast address space. For more complete list of
operators please refer to RFC-2622.

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

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

route-set: rs-
remarks: routes not accepted from any
members: 0.0.0.0/0, # default
0.0.0.0/0^32, # host
224.0.0.0/3^+, # multicast
127.0.0.0/8^9-32, . . .

Figure 18: route-set

Meyer, et al. Informational [Page 22]

RFC 2650 Using RPSL in Practice August 1999

B Output of RtConfig: An

In Figure 19, you see the result of running RtConfig on the
file in Figure 11.

router bgp 3582
network 128.223.0.0
!
!
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-
route-map AS3701-EXPORT permit 1
match ip address 100
!
router bgp 3582
neighbor 198.32.162.2 route-map AS3701-EXPORT
!
no route-map AS3701-
route-map AS3701-IMPORT permit 1
set local-preference 1000
!
router bgp 3582
neighbor 198.32.162.2 route-map AS3701-IMPORT
!
! WNA/
neighbor 198.32.162.6 remote-as 2914
!
no route-map AS2914-
route-map AS2914-EXPORT permit 1
match ip address 100
!
router bgp 3582
neighbor 198.32.162.6 route-map AS2914-EXPORT
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-
route-map AS2914-IMPORT permit 1
match as-path 100
set local-preference 998

Meyer, et al. Informational [Page 23]

RFC 2650 Using RPSL in Practice August 1999

!
router bgp 3582
neighbor 198.32.162.6 route-map AS2914-IMPORT

Figure 19: Output of

Security

This document is a tutorial to RPSL, it does not define protocols
standards that need to be secured

(1) AS-PATH regular expressions are POSIX compliant
expressions

(2) Discussion of RtConfig internals is beyond the scope of
document

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

[1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer
D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
Specification Language (RPSL)", RFC 2622, June 1999.

[2] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P. and M
Terpstra, "Representation of IP Routing Policies in the
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
a Routing Registry, Technical Report ripe-181, RIPE, RIPE NCC
Amsterdam, Netherlands, October 1994.

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

[5] Hank Nussbacher. The CIDR FAQ. Tel Aviv University and
Israel. http://www.ibm.net.il/~hank/cidr.

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

Meyer, et al. Informational [Page 24]

RFC 2650 Using RPSL in Practice August 1999

[7] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
1654, July 1994.

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

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

Authors'

David
Cisco

EMail: dmm@cisco.

Joachim
America On-

EMail: SchmitzJo@aol.

Carol
RIPE

EMail: orange@spiritone.

Mark
connect.com.au pty

EMail: mrp@connect.com.

Cengiz
USC/Information Sciences

EMail: cengiz@isi.

Meyer, et al. Informational [Page 25]

RFC 2650 Using RPSL in Practice August 1999

Full Copyright

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

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Meyer, et al. Informational [Page 26]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX