As per Relevance of the word following, we have this rfc below:
Network Working Group C.
Request for Comments: 2280 USC/Information Sciences
Category: Standards Track T.
Cisco
E.
At Home
D.
D.
University of
M.
Bay
C.
January 1998
Routing Policy Specification Language (RPSL
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
Table of
1 Introduction 2
2 RPSL Names, Reserved Words, and Representation 3
3 Contact Information 6
3.1 mntner Class . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 person Class . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 role Class . . . . . . . . . . . . . . . . . . . . . . . . 9
4 route Class 10
5 Set Classes 12
5.1 route-set Class . . . . . . . . . . . . . . . . . . . . . . 12
5.2 as-set Class . . . . . . . . . . . . . . . . . . . . . . . 14
5.3 Predefined Set Objects . . . . . . . . . . . . . . . . . . 15
5.4 Hierarchical Set Names . . . . . . . . . . . . . . . . . . 15
6 aut-num Class 16
6.1 import Attribute: Import Policy Specification . . . . . . 16
6.1.1 Peering Specification . . . . . . . . . . . . . . . . . 17
6.1.2 Action Specification . . . . . . . . . . . . . . . . . 19
Alaettinoglu, et. al. Standards Track [Page 1]
RFC 2280 RPSL January 1998
6.1.3 Filter Specification . . . . . . . . . . . . . . . . . 20
6.1.4 Example Policy Expressions . . . . . . . . . . . . . . 24
6.2 export Attribute: Export Policy Specification . . . . . . 24
6.3 Other Routing Protocols, Multi-Protocol
Protocols, and Injecting Routes Between Protocols . . . . . 25
6.4 Ambiguity Resolution . . . . . . . . . . . . . . . . . . . 26
6.5 default Attribute: Default Policy Specification . . . . . 28
6.6 Structured Policy Specification . . . . . . . . . . . . . . 29
7 dictionary Class 33
7.1 Initial RPSL Dictionary and Example Policy
and Filters . . . . . . . . . . . . . . . . . . . . . . . . . 36
8 Advanced route Class 41
8.1 Specifying Aggregate Routes . . . . . . . . . . . . . . . . 41
8.1.1 Interaction with policies in aut-num class . . . . . . 45
8.1.2 Ambiguity resolution with overlapping aggregates . . . 46
8.2 Specifying Static Routes . . . . . . . . . . . . . . . . . 47
9 inet-rtr Class 48
10 Security Considerations 49
11 Acknowledgements 50
A Routing Registry Sites 51
B Authors' Addresses 52
C Full Copyright Statement 53
1
This memo is the reference document for the Routing
Specification Language (RPSL). RPSL allows a network operator to
able to specify routing policies at various levels in the
hierarchy; for example at the Autonomous System (AS) level. At
same time, policies can be specified with sufficient detail in
so that low level router configurations can be generated from them
RPSL is extensible; new routing protocols and new protocol
can be introduced at any time
RPSL is a replacement for the current Internet policy
language known as RIPE-181 [4] or RFC-1786 [5]. RIPE-81 [6] was
first language deployed in the Internet for specifying
policies. It was later replaced by RIPE-181 [4].
operational use of RIPE-181 it has become apparent that
policies cannot be specified and a need for an enhanced and
generalized language is needed. RPSL addresses RIPE-181'
limitations
Alaettinoglu, et. al. Standards Track [Page 2]
RFC 2280 RPSL January 1998
RPSL was designed so that a view of the global routing policy can
contained in a single cooperatively maintained distributed
to improve the integrity of Internet's routing. RPSL is not
to be a router configuration language. RPSL is designed so
router configurations can be generated from the description of
policy for one autonomous system (aut-num class) combined with
description of a router (inet-rtr class), mainly providing router ID
autonomous system number of the router, interfaces and peers of
router, and combined with a global database mappings from AS sets
ASes (as-set class), and from origin ASes and route sets to
prefixes (route and route-set classes). The accurate population
the RPSL database can help contribute toward such goals as
configurations that protect against accidental (or malicious
distribution of inaccurate routing information, verification
Internet's routing, and aggregation boundaries beyond a single AS
RPSL is object oriented; that is, objects contain pieces of
and administrative information. These objects are registered in
Internet Routing Registry (IRR) by the authorized organizations.
registration process is beyond the scope of this document.
refer to [1, 15, 2] for more details on the IRR
In the following sections, we present the classes that are used
define various policy and administrative objects. The "mntner"
defines entities authorized to add, delete and modify a set
objects. The "person" and "role" classes describes technical
administrative contact personnel. Autonomous systems (ASes)
specified using the "aut-num" class. Routes are specified using
"route" class. Sets of ASes and routes can be defined using
"as-set" and "route-set" classes. The "dictionary" class
the extensibility to the language. The "inet-rtr" class is used
specify routers. Many of these classes were originally defined
earlier documents [4, 11, 14, 10, 3] and have all been enhanced
This document is self-contained. However, the reader is
to read RIPE-181 [5] and the associated documents [11, 14, 10, 3]
they provide significant background as to the motivation
underlying principles behind RIPE-181 and consequently, RPSL. For
tutorial on RPSL, the reader should read the RPSL
document [2].
2 RPSL Names, Reserved Words, and
Each class has a set of attributes which store a piece of
about the objects of the class. Attributes can be mandatory
optional: A mandatory attribute has to be defined for all objects
Alaettinoglu, et. al. Standards Track [Page 3]
RFC 2280 RPSL January 1998
the class; optional attributes can be skipped. Attributes can
be single or multiple valued. Each object is uniquely identified
a set of attributes, referred to as the class "key".
The value of an attribute has a type. The following types are
widely used. Note that RPSL is case insensitive and only
characters from the ASCII character set can be used
Many objects in RPSL have a name. An
is made up of letters, digits, the character underscore "_",
the character hyphen "-"; the first character of a name must be
letter, and the last character of a name must be a letter or
digit. The following words are reserved by RPSL, and they
not be used as names
any as-any rs-any
and or
atomic from to at action accept announce except
networks into inbound
Names starting with certain prefixes are reserved for
object types. Names starting with "as-" are reserved for as
names. Names starting with "rs-" are reserved for route
names
An AS number x is represented as the string "ASx".
is, the AS 226 is represented as AS226.
An IPv4 address is represented as a sequence of
integers in the range from 0 to 255 separated by the
dot ".". For example, 128.9.128.5 represents a valid IPv
address. In the rest of this document, we may refer to IPv
addresses as IP addresses
An address prefix is represented as an IPv
address followed by the character slash "/" followed by
integer in the range from 0 to 32. The following are
address prefixes: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0;
the following address prefixes are invalid: 0/0, 128.9/16 since 0
or 128.9 are not strings containing four integers
An address prefix range is an
prefix followed by one of the following range operators
Alaettinoglu, et. al. Standards Track [Page 4]
RFC 2280 RPSL January 1998
^- is the exclusive more specifics operator; it
for the more specifics of the address prefix excluding
address prefix itself. For example, 128.9.0.0/16^-
all the more specifics of 128.9.0.0/16
128.9.0.0/16.
^+ is the inclusive more specifics operator; it
for the more specifics of the address prefix including
address prefix itself. For example, 5.0.0.0/8^+ contains
the more specifics of 5.0.0.0/8 including 5.0.0.0/8.
^n where n is an integer, stands for all the length n
of the address prefix. For example, 30.0.0.0/8^16
all the more specifics of 30.0.0.0/8 which are of length 16
such as 30.9.0.0/16.
^n-m where n and m are integers, stands for all the length n
length m specifics of the address prefix. For example
30.0.0.0/8^24-32 contains all the more specifics
30.0.0.0/8 which are of length 24 to 32 such as 30.9.9.96/28.
Range operators can also be applied to address prefix sets.
this case, they distribute over the members of the set.
example, for a route-set (defined later) rs-foo, rs-foo^+
contains all the inclusive more specifics of all the prefixes
rs-foo
A date is represented as an eight digit integer of
form YYYYMMDD where YYYY represents the year, MM represents
month of the year (01 through 12), and DD represents the day
the month (01 through 31). For example, June 24, 1996
represented as 19960624.
is as described in RFC-822[8].
is as described in RFC-1034[16].
is a uniquely assigned identifier[13] used by routing
address allocation, and other registries to unambiguously
to contact information. person and role classes map NIC
to actual person names, and contact information
is a sequence of ASCII characters
is a name of an object of type X. That is
is a name of a mntner object
Alaettinoglu, et. al. Standards Track [Page 5]
RFC 2280 RPSL January 1998
<registry-name>is a name of an IRR registry. The
registries are listed in Appendix A
A value of an attribute may also be a list of one of these types.
list is represented by separating the list members by commas ",".
For example, "AS1, AS2, AS3, AS4" is a list of AS numbers. Note
being list valued and being multiple valued are orthogonal.
multiple valued attribute has more than one value, each of which
or may not be a list. On the other hand a single valued
may have a list value
An RPSL object is textually represented as a list of attribute-
pairs. Each attribute-value pair is written on a separate line.
attribute name starts at column 0, followed by character ":"
followed by the value of the attribute. The object's
ends when a blank line is encountered. An attribute's value can
split over multiple lines, by starting the continuation lines with
white-space (" " or tab) character. The order of attribute-
pairs is significant
An object's description may contain comments. A comment can
anywhere in an object's definition, it starts at the first "#"
character on a line and ends at the first end-of-line character
White space characters can be used to improve readability
3 Contact
The mntner, person and role classes, admin-c, tech-c, mnt-by
changed, and source attributes of all classes describe
information. The mntner class also specifies what entities
create, delete and update other objects. These classes do
specify routing policies and each registry may have different
additional requirements on them. Here we present the
denominator for completeness which is the RIPE
implementation[15]. Please consult your routing registry for
latest specification of these classes and attributes
3.1 mntner
The mntner class defines entities that can create, delete and
RPSL objects. A provider, before he/she can create RPSL objects
first needs to create a mntner object. The attributes of the
class are shown in Figure 1. The mntner class was first described
[11].
The mntner attribute is mandatory and is the class key attribute
Its value is an RPSL name. The auth attribute specifies the
that will be
Alaettinoglu, et. al. Standards Track [Page 6]
RFC 2280 RPSL January 1998
Attribute Value
mntner mandatory, single-valued, class
descr mandatory, single-
auth see description in text mandatory, multi-
upd-to mandatory, multi-
mnt-nfy optional, multi-
tech-c mandatory, multi-
admin-c mandatory, multi-
remarks optional, multi-
notify optional, multi-
mnt-by list of mandatory, multi-
changed mandatory, multi-
source <registry-name> mandatory, single-
to identify and authenticate update requests from this maintainer
It has the following syntax
auth:
E.g
auth:
auth: CRYPT-PW
auth: MAIL-FROM .*@ripe\.
The 's currently defined are: NONE, MAIL-FROM, PGP
CRYPT-PW. The is additional information required by
particular scheme: in the case of MAIL-FROM, it is a
expression matching valid email addresses; in the case of CRYPT-PW
it is a password in UNIX crypt format; and in the case of PGP, it
a PGP public key. If multiple auth attributes are specified,
update request satisfying any one of them is authenticated to be
the maintainer
The upd-to attribute is an email address. On an unauthorized
attempt of an object maintained by this maintainer, an email
will be sent to this address. The mnt-nfy attribute is an
address. A notification message will be forwarded to this
address whenever an object maintained by this maintainer is added
changed or deleted
The descr attribute is a short, free-form textual description of
object. The tech-c attribute is a technical contact NIC handle
This is someone to be contacted for technical problems such
misconfiguration. The admin-c attribute is an administrative
NIC handle. The remarks attribute is a free text explanation
clarification. The notify attribute is an email address to
notifications of changes to this object should be sent. The mnt-
attribute is a list of mntner object names. The authorization
Alaettinoglu, et. al. Standards Track [Page 7]
RFC 2280 RPSL January 1998
changes to this object is governed by any of the maintainer
referenced. The changed attribute documents who last changed
object, and when this change was made. Its syntax has the
form
changed:
E.g
changed: johndoe@terabit-labs.nn 19900401
The identifies the person who made the last change
is the date of the change. The source attribute
the registry where the object is registered. Figure 2 shows
example mntner object. In the example, UNIX crypt format
authentication is used
mntner: RIPE-NCC-
descr: RIPE-NCC
admin-c: DK58
tech-c: OPS4-
upd-to: ops@ripe.
mnt-nfy: ops-fyi@ripe.
auth: CRYPT-PW lz1A7/
mnt-by: RIPE-NCC-
changed: ripe-dbm@ripe.net 19970820
source:
Figure 2: An example mntner object
The descr, tech-c, admin-c, remarks, notify, mnt-by, changed
source attributes are attributes of all RPSL classes. Their syntax
semantics, and mandatory, optional, multi-valued, or single-
status are the same for for all RPSL classes. We do not
discuss them in other sections
3.2 person
A person class is used to describe information about people.
though it does not describe routing policy, we still describe it
briefly since many policy objects make reference to person objects
The person class was first described in [14].
The attributes of the person class are shown in Figure 3. The
attribute is the full name of the person. The phone and the fax-
attributes have the following syntax
Alaettinoglu, et. al. Standards Track [Page 8]
RFC 2280 RPSL January 1998
Attribute Value
person mandatory, single-
nic-hdl mandatory, single-valued, class
address mandatory, multi-
phone see description in text mandatory, multi-
fax-no same as phone optional, multi-
e-mail mandatory, multi-
Figure 3: person Class
phone: + <subscriber> [ext. <extension>]
E.g.:
phone: +31 20 12334676
phone: +44 123 987654 ext. 4711
Figure 4 shows an example person object
person: Daniel
address: RIPE Network Coordination Centre (NCC
address: Singel 258
address: NL-1016 AB
address:
phone: +31 20 535 4444
fax-no: +31 20 535 4445
e-mail: Daniel.Karrenberg@ripe.
nic-hdl: DK58
changed: Daniel.Karrenberg@ripe.net 19970616
source:
Figure 4: An example person object
3.3 role
The role class is similar to the person object. However, instead
describing a human being, it describes a role performed by one
more human beings. Examples include help desks, network
centers, system administrators, etc. Role object is
useful since often a person performing a role may change, however
role itself remains
The attributes of the role class are shown in Figure 5. The nic-
attributes of the person and role classes share the same name space
Alaettinoglu, et. al. Standards Track [Page 9]
RFC 2280 RPSL January 1998
Attribute Value
role mandatory, single-
nic-hdl mandatory, single-valued, class
trouble optional, multi-
address mandatory, multi-
phone see description in text mandatory, multi-
fax-no same as phone optional, multi-
e-mail mandatory, multi-
Figure 5: role Class
NIC handle of a role object cannot be used in an admin-c field.
trouble attribute of role object may contain additional
information to be used when a problem arises in any object
references this role object. Figure 6 shows an example role object
role: RIPE NCC
address: Singel 258
address: 1016 AB
address: The
phone: +31 20 535 4444
fax-no: +31 20 545 4445
e-mail: ops@ripe.
admin-c: CO19-
tech-c: RW488-
tech-c: JLSD1-
nic-hdl: OPS4-
notify: ops@ripe.
changed: roderik@ripe.net 19970926
source:
Figure 6: An example role object
4 route
Each interAS route (also referred to as an interdomain route
originated by an AS is specified using a route object.
attributes of the route class are shown in Figure 7. The
attribute is the address prefix of the route and the origin
is the AS number of the AS that originates the route into the
routing system. The route and origin attribute pair is the
key
Figure 8 shows examples of four route objects (we do not
contact
Alaettinoglu, et. al. Standards Track [Page 10]
RFC 2280 RPSL January 1998
Attribute Value
route mandatory, single-valued
class
origin mandatory, single-valued
class
withdrawn optional, single-
member-of list of optional, single-
see Section 5
inject see Section 8 optional, multi-
components see Section 8 optional, single-
aggr-bndry see Section 8 optional, single-
aggr-mtd see Section 8 optional, single-
export-comps see Section 8 optional, single-
holes see Section 8 optional, single-
Figure 7: route Class
attributes such as admin-c, tech-c for brevity). Note that the
two route objects have the same address prefix, namely 128.8.0.0/16.
However, they are different route objects since they are
by different ASes (i.e. they have different keys).
route: 128.9.0.0/16
origin: AS226
route: 128.99.0.0/16
origin: AS226
route: 128.8.0.0/16
origin: AS
route: 128.8.0.0/16
origin: AS
withdrawn: 19960624
Figure 8: Route
The withdrawn attribute, if present, signifies that the originator
no longer originates this address prefix in the Internet. Its
is a date indicating the date of withdrawal. In Figure 8, the
route object is withdrawn (i.e. no longer originated by AS2) on
24, 1996.
Alaettinoglu, et. al. Standards Track [Page 11]
RFC 2280 RPSL January 1998
5 Set
To specify policies, it is often useful to define sets of objects
For this purpose we define two classes: route-set and as-set.
classes define a named set. The members of these sets can
specified by either explicitly listing them in the set object'
definition, or implicitly by having route and aut-num objects
to the set names, or a combination of both methods
5.1 route-set
The attributes of the route-set class are shown in Figure 9.
route-set attribute defines the name of the set. It is an RPSL
that starts with "rs-". The members attribute lists the members
the set. The members attribute is a list of address prefixes
other route-set names. Note that, the route-set class is a set
route prefixes, not of RPSL route objects
Attribute Value
route-set mandatory, single-valued
class
members list of prefixes> or optional, single-
mbrs-by-ref list of optional, single-
Figure 9: route-set Class
Figure 10 presents some example route-set objects. The set rs-
contains two address prefixes, namely 128.9.0.0/16 and 128.9.0.0/16.
The set rs-bar contains the members of the set rs-foo and the
prefix 128.7.0.0/16. The set rs-empty contains no members
route-set: rs-
members: 128.9.0.0/16, 128.9.0.0/24
route-set: rs-
members: 128.7.0.0/16, rs-
route-set: rs-
Figure 10: route-set
An address prefix or a route-set name in a members attribute can
optionally followed by a range operator. For example, the
Alaettinoglu, et. al. Standards Track [Page 12]
RFC 2280 RPSL January 1998
route-set: rs-
members: 5.0.0.0/8^+, 30.0.0.0/8^24-32, rs-foo^+
contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8,
the more specifics of 30.0.0.0/8 which are of length 24 to 32 such
30.9.9.96/28, and all the more specifics of address prefixes in
set rs-foo
The mbrs-by-ref attribute is a list of maintainer names or
keyword ANY. If this attribute is used, the route set also
address prefixes whose route objects are registered by one of
maintainers and whose member-of attribute refers to the name of
route set. If the value of a mbrs-by-ref attribute is ANY, any
object referring to the route set name is a member. If the mbrs-by
ref attribute is missing, only the address prefixes listed in
members attribute are members of the set
route-set: rs-
mbrs-by-ref: MNTR-ME, MNTR-
route-set: rs-
members: 128.7.0.0/16
mbrs-by-ref: MNTR-
route: 128.9.0.0/16
origin: AS
member-of: rs-
mnt-by: MNTR-
route: 128.8.0.0/16
origin: AS
member-of: rs-foo, rs-
mnt-by: MNTR-
Figure 11: route-set objects
Figure 11 presents example route-set objects that use the mbrs-by-
attribute. The set rs-foo contains two address prefixes,
128.8.0.0/16 and 128.9.0.0/16 since the route objects
128.8.0.0/16 and 128.9.0.0/16 refer to the set name rs-foo in
member-of attribute. The set rs-bar contains the address
128.7.0.0/16 and 128.8.0.0/16. The route 128.7.0.0/16 is
listed in the members attribute of rs-bar, and the route object
128.8.0.0/16 refer to the set name rs-bar in its member-of attribute
Note that, if an address prefix is listed in a members attribute of
route set, it is a member of that route set. The route
Alaettinoglu, et. al. Standards Track [Page 13]
RFC 2280 RPSL January 1998
corresponding to this address prefix does not need to contain
member-of attribute referring to this set name. The member-
attribute of the route class is an additional mechanism
specifying the members indirectly
5.2 as-set
The attributes of the as-set class are shown in Figure 12. The as
set attribute defines the name of the set. It is an RPSL name
starts with "as-". The members attribute lists the members of
set. The members attribute is a list of AS numbers, or other as-
names
Attribute Value
as-set mandatory, single-valued
class
members list of or optional, single-
mbrs-by-ref list of optional, single-
Figure 12: as-set Class
Figure 13 presents two as-set objects. The set as-foo contains
ASes, namely AS1 and AS2. The set as-bar contains the members of
set as-foo and AS3, that is it contains AS1, AS2, AS3.
as-set: as-foo as-set: as-
members: AS1, AS2 members: AS3, as-
Figure 13: as-set objects
The mbrs-by-ref attribute is a list of maintainer names or
keyword ANY. If this attribute is used, the AS set also
ASes whose aut-num objects are registered by one of these
and whose member-of attribute refers to the name of this AS set.
the value of a mbrs-by-ref attribute is ANY, any AS object
to the AS set is a member of the set. If the mbrs-by-ref
is missing, only the ASes listed in the members attribute are
of the set
Figure 14 presents an example as-set object that uses the mbrs-by-
attribute. The set as-foo contains AS1, AS2 and AS3. AS4 is not
member of the set as-foo even though the aut-num object
as-foo. This is because MNTR-OTHER is not listed in the as-foo'
mbrs-by-ref attribute
Alaettinoglu, et. al. Standards Track [Page 14]
RFC 2280 RPSL January 1998
as-set: as-
members: AS1, AS
mbrs-by-ref: MNTR-
aut-num: AS3 aut-num: AS
member-of: as-foo member-of: as-
mnt-by: MNTR-ME mnt-by: MNTR-
Figure 14: as-set objects
5.3 Predefined Set
In a context that expects a route set (e.g. members attribute of
route-set class), an AS number ASx defines the set of routes that
originated by ASx; and an as-set AS-X defines the set of routes
are originated by the ASes in AS-X. A route p is said to
originated by ASx if there is a route object for p with ASx as
value of the origin attribute. For example, in Figure 15, the
set rs-special contains 128.9.0.0/16, routes of AS1 and AS2,
routes of the ASes in AS set AS-FOO
route-set: rs-
members: 128.9.0.0/16, AS1, AS2, AS-
Figure 15: Use of AS numbers and AS sets in route sets
The set rs-any contains all routes registered in IRR. The set as-
contains all ASes registered in IRR
5.4 Hierarchical Set
Set names can be hierarchical. A hierarchical set name is a
of set names and AS numbers separated by colons ":". For example
the following names are valid: AS1:AS-CUSTOMERS, AS1:RS-EXCEPTIONS
AS1:RS-EXPORT:AS2, RS-EXCEPTIONS:RS-BOGUS. All components of
hierarchical set name which are not AS numbers should start
"as-" or "rs-" for as sets and route sets respectively
A set object with name X1:...:Xn-1:Xn can only be created by
maintainer of the object with name X1:...:Xn-1. That is, only
maintainer of AS1 can create a set with name AS1:AS-FOO; and only
maintainer of AS1:AS-FOO can create a set with name AS1:AS-FOO:AS
BAR
Alaettinoglu, et. al. Standards Track [Page 15]
RFC 2280 RPSL January 1998
The purpose of an hierarchical set name is to partition the set
space so that the controllers of the set name X1 controls the
set name space under X1, i.e. X1:...:Xn-1. This is important
anyone can create a set named AS-MCI-CUSTOMERS but only the
created AS3561 can create AS3561:AS-CUSTOMERS. In the former, it
not clear if the set AS-MCI-CUSTOMERS has any relationship with MCI
In the latter, we can guarantee that AS3561:AS-CUSTOMERS and AS3561
are created by the same entity
6 aut-num
ASes are specified using the aut-num class. The attributes of
aut-num class are shown in Figure 16. The value of the aut-
attribute is the AS number of the AS described by this object.
as-name attribute is a symbolic name (in RPSL name syntax) of the AS
The import, export and default routing policies of the AS
specified using import, export and default attributes respectively
Attribute Value
aut-num mandatory, single-valued, class
as-name mandatory, single-
member-of list of optional, single-
import see Section 6.1 optional, multi
export see Section 6.2 optional, multi
default see Section 6.5 optional, multi
Figure 16: aut-num Class
6.1 import Attribute: Import Policy
Figure 17 shows a typical interconnection of ASes that we will
using in our examples throughout this section. In this
topology, there are three ASes, AS1, AS2, and AS3; two
points, EX1 and EX2; and six routers. Routers connected to the
exchange point peer with each other, i.e. open a connection
exchanging routing information. Each router would export a subset
the routes it has to its peer routers. Peer routers would import
subset of these routes. A router while importing routes would
some route attributes. For example, AS1 can assign higher
values to the routes it imports from AS2 so that it prefers AS2
AS3. While exporting routes, a router may also set some
attributes in order to affect route selection by its peers.
example, AS2 may set the MULTI-EXIT-DISCRIMINATOR BGP attribute
that AS1 prefers to use the router 9.9.9.2. Most interAS
are specified by specifying what route subsets can be imported
exported, and how the various BGP route attributes are set and used
Alaettinoglu, et. al. Standards Track [Page 16]
RFC 2280 RPSL January 1998
---------------------- ----------------------
| 7.7.7.1 |-------| |-------| 7.7.7.2 |
| | ======== | |
| AS1 | EX1 |-------| 7.7.7.3 AS2 |
| | | |
| 9.9.9.1 |------ ------| 9.9.9.2 |
---------------------- | | ----------------------
===========
| EX
---------------------- |
| 9.9.9.3 |---------
| |
| AS3 |
----------------------
Figure 17: Example topology consisting of three ASes, AS1, AS2,
AS3; two exchange points, EX1 and EX2; and six routers
In RPSL, an import policy is divided into import policy expressions
Each import policy expression is specified using an import attribute
The import attribute has the following syntax (we will extend
syntax later in Sections 6.3 and 6.6):
import: from [action ]
. . .
from [action ]
accept
The action specification is optional. The semantics of an
attribute is as follows: the set of routes that are matched
are imported from all the peers in ;
importing routes at , is executed
E.g
aut-num: AS
import: from AS2 action pref = 1; accept { 128.9.0.0/16 }
This example states that the route 128.9.0.0/16 is accepted from AS
with preference 1. In the next few subsections, we will describe
peerings, actions and filters are specified
6.1.1 Peering
Our example above used an AS number to specify peerings.
peerings can be specified at different granularities. The syntax
a peering specification has two forms. The first one is as follows
Alaettinoglu, et. al. Standards Track [Page 17]
RFC 2280 RPSL January 1998
[] [at ]
where and are IP addresses of routers
is an AS number. must be the AS number
. Both and are optional
If both and are specified, this
specification identifies only the peering between these two routers
If only is specified, this peering
identifies all the peerings between and any of
peer routers in . If only is specified,
peering specification identifies all the peerings between any
in the local AS and . If neither
is specified, this peering specification identifies
the peerings between any router in the local AS and any router
.
We next give examples. Consider the topology of Figure 17
7.7.7.1, 7.7.7.2 and 7.7.7.3 peer with each other; 9.9.9.1, 9.9.9.2
and 9.9.9.3 peer with each other. In the following example 7.7.7.1
imports 128.9.0.0/16 from 7.7.7.2.
(1) aut-num: AS
import: from AS2 7.7.7.2 at 7.7.7.1 accept { 128.9.0.0/16 }
In the following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2
and 7.7.7.3.
(2) aut-num: AS
import: from AS2 at 7.7.7.1 accept { 128.9.0.0/16 }
In the following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2
and 7.7.7.3, and 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2.
(3) aut-num: AS
import: from AS2 accept { 128.9.0.0/16 }
The second form of specification has the following syntax
expression> [at expression>]
where expression> is an expression over AS numbers and sets
operators AND, OR, and NOT, and expression> is an
over router IP addresses and DNS names using operators AND, OR,
NOT. The DNS name can only be used if there is an inet-rtr object
that name that binds the name to IP addresses. This form
all the peerings between any local router in expression>
Alaettinoglu, et. al. Standards Track [Page 18]
RFC 2280 RPSL January 1998
any of their peer routers in the ASes in expression>.
expression> is not specified, it defaults to all routers
the local AS
In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2
and 9.9.9.3.
(4) as-set: AS-
members: AS2, AS
aut-num: AS
import: from AS-FOO at 9.9.9.1 accept { 128.9.0.0/16 }
In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2
and 9.9.9.3, and 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2
7.7.7.3.
(5) aut-num: AS
import: from AS-FOO accept { 128.9.0.0/16 }
In the following example AS1 imports 128.9.0.0/16 from AS3 at
9.9.9.1
(6) aut-num: AS
import: from AS-FOO and not AS
at not 7.7.7.1
accept { 128.9.0.0/16 }
This is because "AS-FOO and not AS2" equals AS3 and "not 7.7.7.1"
equals 9.9.9.1.
6.1.2 Action
Policy actions in RPSL either set or modify route attributes, such
assigning a preference to a route, adding a BGP community to the
community path attribute, or setting the MULTI-EXIT-
attribute. Policy actions can also instruct routers to
special operations, such as route flap damping
The routing policy attributes whose values can be modified in
actions are specified in the RPSL dictionary. Please refer
Section 7 for a list of these attributes. Each action in RPSL
terminated by the character ';'. It is possible to form
policy actions by listing them one after the other. In a
policy action, the actions are executed left to right. For example
Alaettinoglu, et. al. Standards Track [Page 19]
RFC 2280 RPSL January 1998
aut-num: AS
import: from AS
action pref = 10; med = 0; community.append(10250, {3561,10});
accept { 128.9.0.0/16 }
sets pref to 10, med to 0, and then appends 10250 and {3561,10}
the community path attribute
6.1.3 Filter
A policy filter is a logical expression which when applied to a
of routes returns a subset of these routes. We say that the
filter matches the subset returned. The policy filter can
routes using any path attribute, such as the destination
prefix (or NLRI), AS-path, or community attributes
The policy filters can be composite by using the operators AND, OR
and NOT. The following policy filters can be used to select a
of routes
ANY The filter-keyword ANY matches all routes
Address-Prefix Set This is an explicit list of address
enclosed in braces '{' and '}'. The policy filter matches the set
routes whose destination address-prefix is in the set. For example
{ 0.0.0.0/0 }
{ 128.9.0.0/16, 128.8.0.0/16, 128.7.128.0/17, 5.0.0.0/8 }
{ }
An address prefix can be optionally followed by a range
(i.e. '^-', '^+', '^n', or '^n-m'). For example, the
{ 5.0.0.0/8^+, 128.9.0.0/16^-, 30.0.0.0/8^16, 30.0.0.0/8^24-32 }
contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8,
the more specifics of 128.9.0.0/16 excluding 128.9.0.0/16, all
more specifics of 30.0.0.0/8 which are of length 16 such
30.9.0.0/16, and all the more specifics of 30.0.0.0/8 which are
length 24 to 32 such as 30.9.9.96/28.
Route Set Name A route set name matches the set of routes that
members of the set. A route set name may be a name of a route-
object, an AS number, or a name of an as-set object (AS numbers
as-set names implicitly define route sets; please see Section 5.3).
For example
Alaettinoglu, et. al. Standards Track [Page 20]
RFC 2280 RPSL January 1998
aut-num: AS
import: from AS2 action pref = 1; accept AS
import: from AS2 action pref = 1; accept AS-
import: from AS2 action pref = 1; accept RS-
The keyword PeerAS can be used instead of the AS number of the
AS. PeerAS is particularly useful when the peering is
using an AS expression. For example
as-set: AS-
members: AS2, AS
aut-num: AS
import: from AS-FOO action pref = 1; accept
is same as
aut-num: AS
import: from AS2 action pref = 1; accept AS
import: from AS3 action pref = 1; accept AS
A route set name can also be followed by one of the operators '^-',
'^+', '^n' or '^n-m'. These operators are distributive over
route sets. For example, { 5.0.0.0/8, 6.0.0.0/8 }^+ equals {
5.0.0.0/8^+, 6.0.0.0/8^+ }, and AS1^- equals all the exclusive
specifics of routes originated by AS1.
AS Path Regular Expressions An AS-path regular expression can be
as a policy filter by enclosing the expression in `<' and `>'.
AS-path policy filter matches the set of routes which traverses
sequence of ASes matched by the AS-path regular expression. A
can check this using the AS_PATH attribute in the Border
Protocol [18], or the RD_PATH attribute in the Inter-Domain
Protocol[17].
AS-path Regular Expressions are POSIX compliant regular
over the alphabet of AS numbers. The regular expression
are as follows
ASN where ASN is an AS number. ASN matches the AS-
that is of length 1 and contains the corresponding
number (e.g. AS-path regular expression AS1 matches
AS-path "1").
The keyword PeerAS can be used instead of the AS
of the peer AS
Alaettinoglu, et. al. Standards Track [Page 21]
RFC 2280 RPSL January 1998
AS-set where AS-set is an AS set name. AS-set matches the AS-
that is matched by one of the ASes in the AS-set
. matches the AS-paths matched by any AS number
[...] is an AS number set. It matches the AS-paths matched
the AS numbers listed between the brackets. The
numbers in the set are separated by white
characters. If a `-' is used between two AS numbers
this set, all AS numbers between the two AS numbers
included in the set. If an as-set name is listed,
AS numbers in the as-set are included
[^...] is a complemented AS number set. It matches any AS-
which is not matched by the AS numbers in the set
^ Matches the empty string at the beginning of an AS-path
$ Matches the empty string at the end of an AS-path
We next list the regular expression operators in the decreasing
of evaluation. These operators are left associative, i.e.
left to right
Unary postfix operators * + ? {m} {m,n} {m,}
For a regular expression A, A* matches zero or
occurrences of A; A+ matches one or more occurrences
A; A? matches zero or one occurrence of A; A{m}
m occurrence of A; A{m,n} matches m to n occurrence
A; A{m,} matches m or more occurrence of A. For example
[AS1 AS2]{2} matches AS1 AS1, AS1 AS2, AS2 AS1, and AS
AS2.
Unary postfix operators ~* ~+ ~{m} ~{m,n} ~{m,}
These operators have similar functionality as
corresponding operators listed above, but
occurrences of the regular expression has to match
same pattern. For example, [AS1 AS2]~{2} matches AS
AS1 and AS2 AS2, but it does not match AS1 AS2 and AS
AS1.
Binary catenation
This is an implicit operator and exists between
regular expressions A and B when no other
operator is specified. The resulting expression A
matches an AS-path if A matches some prefix of the AS
path and B matches the rest of the AS-path
Alaettinoglu, et. al. Standards Track [Page 22]
RFC 2280 RPSL January 1998
Binary alternative (or) operator |
For a regular expressions A and B, A | B matches
AS-path that is matched by A or B
Parenthesis can be used to override the default order of evaluation
White spaces can be used to increase readability
The following are examples of AS-path filters
<^AS1>
<^AS1 AS2 AS3$>
<^AS1 .* AS2$>.
The first example matches any route whose AS-path contains AS3,
second matches routes whose AS-path starts with AS1, the
matches routes whose AS-path ends with AS2, the fourth matches
whose AS-path is exactly "1 2 3", and the fifth matches routes
AS-path starts with AS1 and ends in AS2 with any number of AS
in between
Composite Policy Filters The following operators (in decreasing
of evaluation) can be used to form composite policy filters
NOT Given a policy filter x, NOT x matches the set of routes that
not matched by x. That is it is the negation of policy filter x
AND Given two policy filters x and y, x AND y matches
intersection of the routes that are matched by x and that
matched by y
OR Given two policy filters x and y, x OR y matches the union
the routes that are matched by x and that are matched by y
Note that an OR operator can be implicit, that is `x y' is
to `x OR y'.
E.g
NOT {128.9.0.0/16, 128.8.0.0/16}
AS226 AS227 OR AS228
AS226 AND NOT {128.9.0.0/16}
AS226 AND {0.0.0.0/0^0-18}
Alaettinoglu, et. al. Standards Track [Page 23]
RFC 2280 RPSL January 1998
The first example matches any route except 128.9.0.0/16
128.8.0.0/16. The second example matches the routes of AS226, AS227
and AS228. The third example matches the routes of AS226
128.9.0.0/16. The fourth example matches the routes of AS226
length are not longer than 18.
Routing Policy Attributes Policy filters can also use the values
other attributes for comparison. The attributes whose values can
used in policy filters are specified in the RPSL dictionary.
refer to Section 7 for details. An example using the the
community attribute is shown below
aut-num: AS
export: to AS2 announce AS1 AND NOT community.contains(NO_EXPORT
Filters using the routing policy attributes defined in the
are evaluated before evaluating the operators AND, OR and NOT
6.1.4 Example Policy
aut-num: AS
import: from AS2 action pref = 1;
from AS3 action pref = 2;
accept AS
The above example states that AS4's routes are accepted from AS2
preference 1, and from AS3 with preference 2 (routes with
integer preference values are preferred over routes with
integer preference values).
aut-num: AS
import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1;
from AS2 action pref = 2;
accept AS
The above example states that AS4's routes are accepted from AS2
peering 7.7.7.1-7.7.7.2 with preference 1, and on any other
with AS2 with preference 2.
6.2 export Attribute: Export Policy
Similarly, an export policy expression is specified using an
attribute. The export attribute has the following syntax
export: to [action ]
. . .
to [action ]
announce
Alaettinoglu, et. al. Standards Track [Page 24]
RFC 2280 RPSL January 1998
The action specification is optional. The semantics of an
attribute is as follows: the set of routes that are matched
are exported to all the peers specified in ;
exporting routes at , is executed
E.g
aut-num: AS
export: to AS2 action med = 5; community .= 70;
announce AS
In this example, AS4's routes are announced to AS2 with the
attribute's value set to 5 and community 70 added to the
list
Example
aut-num: AS
export: to AS-FOO announce
In this example, AS1 announces all of its routes to the ASes in
set AS-FOO
6.3 Other Routing Protocols, Multi-Protocol Routing Protocols,
Injecting Routes Between
The more complete syntax of the import and export attributes are
follows
import: [protocol <protocol-1>] [into <protocol-2>]
from [action ]
. . .
from [action ]
accept
export: [protocol <protocol-1>] [into <protocol-2>]
to [action ]
. . .
to [action ]
announce
Where the optional protocol specifications can be used for
policies for other routing protocols, or for injecting routes of
protocol into another protocol, or for multi-protocol
policies. The valid protocol names are defined in the dictionary
The <protocol-1> is the name of the protocol whose routes are
exchanged. The <protocol-2> is the name of the protocol which
receiving these routes. Both <protocol-1> and <protocol-2>
to the Internet Exterior Gateway Protocol, currently BGP
Alaettinoglu, et. al. Standards Track [Page 25]
RFC 2280 RPSL January 1998
In the following example, all interAS routes are injected into RIP
aut-num: AS
import: from AS2 accept AS
export: protocol BGP4 into
to AS1 announce
In the following example, AS1 accepts AS2's routes including any
specifics of AS2's routes, but does not inject these extra
specific routes into OSPF
aut-num: AS
import: from AS2 accept AS2^+
export: protocol BGP4 into
to AS1 announce AS
In the following example, AS1 injects its static routes (routes
are members of the set AS1:RS-STATIC-ROUTES) to the interAS
protocol and appends AS1 twice to their AS paths
aut-num: AS
import: protocol STATIC into BGP
from AS1 action aspath.prepend(AS1, AS1);
accept AS1:RS-STATIC-
In the following example, AS1 imports different set of unicast
for multicast reverse path forwarding from AS2:
aut-num: AS
import: from AS2 accept AS
import: protocol
from AS2 accept AS2:RS-RPF-
6.4 Ambiguity
It is possible that the same peering can be covered by more that
peering specification in a policy expression. For example
aut-num: AS
import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 2;
from AS2 7.7.7.2 at 7.7.7.1 action pref = 1;
accept AS
This is not an error, though definitely not desirable. To break
ambiguity, the action corresponding to the first
specification is used. That is the routes are accepted
preference 2. We call this rule as the specification-order rule
Alaettinoglu, et. al. Standards Track [Page 26]
RFC 2280 RPSL January 1998
Consider the example
aut-num: AS
import: from AS2 action pref = 2;
from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5;
accept AS
where both peering specifications cover the peering 7.7.7.1-7.7.7.2,
though the second one covers it more specifically. The
order rule still applies, and only the action "pref = 2" is executed
In fact, the second peering-action pair has no use since the
peering-action pair always covers it. If the intended policy was
accept these routes with preference 1 on this particular peering
with preference 2 in all other peerings, the user should
specified
aut-num: AS
import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5;
from AS2 action pref = 2;
accept AS
It is also possible that more than one policy expression can
the same set of routes for the same peering. For example
aut-num: AS
import: from AS2 action pref = 2; accept AS
import: from AS2 action pref = 1; accept AS
In this case, the specification-order rule is still used. That is
AS4's routes are accepted from AS2 with preference 2. If the
were overlapping but not exactly the same
aut-num: AS
import: from AS2 action pref = 2; accept AS
import: from AS2 action pref = 1; accept AS4 OR AS
the AS4's routes are accepted from AS2 with preference 2 and
AS5's routes are also accepted, but with preference 1.
We next give the general specification order rule for the benefit
the RPSL implementors. Consider two policy expressions
aut-num: AS
import: from peerings-1 action action-1 accept filter-1
import: from peerings-2 action action-2 accept filter-2
The above policy expressions are equivalent to the following
expressions where there is no ambiguity
Alaettinoglu, et. al. Standards Track [Page 27]
RFC 2280 RPSL January 1998
aut-num: AS
import: from peerings-1 action action-1 accept filter-1
import: from peerings-3 action action-2 accept filter-2 AND NOT filter-1
import: from peerings-4 action action-2 accept filter-2
where peerings-3 are those that are covered by both peerings-1
peerings-2, and peerings-4 are those that are covered by peerings-2
but not by peerings-1 ("filter-2 AND NOT filter-1" matches the
that are matched by filter-2 but not by filter-1).
Example
aut-num: AS
import: from AS2 7.7.7.2 at 7.7.7.1
action pref = 2;
accept {128.9.0.0/16}
import: from AS
action pref = 1;
accept {128.9.0.0/16, 75.0.0.0/8}
Lets consider two peerings with AS2, 7.7.7.1-7.7.7.2 and 9.9.9.1-
9.9.9.2. Both policy expressions cover 7.7.7.1-7.7.7.2. On
peering, the route 128.9.0.0/16 is accepted with preference 2,
the route 75.0.0.0/8 is accepted with preference 1. The
9.9.9.1-9.9.9.2 is only covered by the second policy expressions
Hence, both the route 128.9.0.0/16 and the route 75.0.0.0/8
accepted with preference 1 on peering 9.9.9.1-9.9.9.2.
Note that the same ambiguity resolution rules also apply to
and default policy expressions
6.5 default Attribute: Default Policy
Default routing policies are specified using the default attribute
The default attribute has the following syntax
default: to [action ] [networks ]
The and specifications are optional. The
are as follows: The specification indicates the AS (and
router if present) is being defaulted to; the specification
if present, indicates various attributes of defaulting, for example
relative preference if multiple defaults are specified; and
specifications, if present, is a policy filter. A
chooses a default router from the routes in its routing table
matches this .
In the following example, AS1 defaults to AS2 for routing
Alaettinoglu, et. al. Standards Track [Page 28]
RFC 2280 RPSL January 1998
aut-num: AS
default: to AS
In the following example, router 7.7.7.1 in AS1 defaults to
7.7.7.2 in AS2.
aut-num: AS
default: to AS2 7.7.7.2 at 7.7.7.1
In the following example, AS1 defaults to AS2 and AS3, but
AS2 over AS3.
aut-num: AS
default: to AS2 action pref = 1;
default: to AS3 action pref = 2;
In the following example, AS1 defaults to AS2 and uses 128.9.0.0/16
as the default network
aut-num: AS
default: to AS2 networks { 128.9.0.0/16 }
6.6 Structured Policy
The import and export policies can be structured. We only
structured policies to advanced RPSL users. Please feel free to
this section
The syntax for a structured policy specification is the following
::= from [action ]
. . .
from [action ]
accept ;
::= |
LEFT-
. . .
RIGHT-
expression> ::= |
EXCEPT expression> |
REFINE expression
import: [protocol <protocol1>] [into <protocol2>]
expression
Alaettinoglu, et. al. Standards Track [Page 29]
RFC 2280 RPSL January 1998
Please note the semicolon at the end of an . If
policy specification is not structured (as in all the examples
other sections), this semicolon is optional. The syntax
semantics for an is already defined in Section 6.1.
An is either a sequence of 's
within matching braces (i.e. `{' and `}') or just a single
factor>. The semantics of an is the union of
factor>'s using the specification order rule. An expression
is either a single or an followed by
of the keywords "except" and "refine", followed by another
expression>. Note that our definition allows nested expressions
Hence there can be exceptions to exceptions, refinements
refinements, or even refinements to exceptions, and so on
The semantics for the except operator is as follows: The result of
except operation is another . The resulting policy
contains the policies of the right hand side but their filters
modified to only include the routes also matched by the left
side. The policies of the left hand side are included afterwards
their filters are modified to exclude the routes matched by the
hand side. Please note that the filters are modified during
process but the actions are copied verbatim. When there are
levels of nesting, the operations (both except and refine)
performed right to left
Consider the following example
import: from AS1 action pref = 1; accept as-foo
except {
from AS2 action pref = 2; accept AS226;
except {
from AS3 action pref = 3; accept {128.9.0.0/16};
}
}
where the route 128.9.0.0/16 is originated by AS226, and AS226 is
member of the as set as-foo. In this example, the route 128.9.0.0/16
is accepted from AS3, any other route (not 128.9.0.0/16)
by AS226 is accepted from AS2, and any other ASes' routes in as-
is accepted from AS1.
We can come to the same conclusion using the algebra defined above
Consider the inner exception specification
Alaettinoglu, et. al. Standards Track [Page 30]
RFC 2280 RPSL January 1998
from AS2 action pref = 2; accept AS226;
except {
from AS3 action pref = 3; accept {128.9.0.0/16};
}
is equivalent
{
from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16};
from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};
}
Hence, the original expression is equivalent to
import: from AS1 action pref = 1; accept as-foo
except {
from AS3 action pref = 3;
accept AS226 AND {128.9.0.0/16};
from AS2 action pref = 2;
accept AS226 AND NOT {128.9.0.0/16};
}
which is equivalent
import: {
from AS3 action pref = 3;
accept as-foo AND AS226 AND {128.9.0.0/16};
from AS2 action pref = 2;
accept as-foo AND AS226 AND NOT {128.9.0.0/16};
from AS1 action pref = 1;
accept as-foo AND
(AS226 AND NOT {128.9.0.0/16}
AS226 AND {128.9.0.0/16});
}
Since AS226 is in as-foo and 128.9.0.0/16 is in AS226, it simplifies to
import: {
from AS3 action pref = 3; accept {128.9.0.0/16};
from AS2 action pref = 2;
accept AS226 AND NOT {128.9.0.0/16};
from AS1 action pref = 1; accept as-foo AND NOT AS226;
}
In the case of the refine operator, the resulting set is
by taking the cartasian product of the two sides as follows: for
policy l in the left hand side and for each policy r in the
hand side, the peerings of the resulting policy are the
Alaettinoglu, et. al. Standards Track [Page 31]
RFC 2280 RPSL January 1998
common to both r and l; the filter of the resulting policy is
intersection of l's filter and r's filter; and action of
resulting policy is l's action followed by r's action. If there
no common peerings, or if the intersection of filters is empty,
resulting policy is not generated
Consider the following example
import: { from AS-ANY action pref = 1;
accept community.contains({3560,10});
from AS-ANY action pref = 2;
accept community.contains({3560,20});
} refine {
from AS1 accept AS1;
from AS2 accept AS2;
from AS3 accept AS3;
}
Here, any route with community {3560,10} is assigned a preference
1 and any route with community {3560,20} is assigned a preference
2 regardless of whom they are imported from. However, only AS1'
routes are imported from AS1, and only AS2's routes are imported
AS2, and only AS3's routes are imported form AS3, and no routes
imported from any other AS. We can reach the same conclusion
the above algebra. That is, our example is equivalent to
import: {
from AS1 action pref = 1;
accept community.contains({3560,10}) AND AS1;
from AS1 action pref = 2;
accept community.contains({3560,20}) AND AS1;
from AS2 action pref = 1;
accept community.contains({3560,10}) AND AS2;
from AS2 action pref = 2;
accept community.contains({3560,20}) AND AS2;
from AS3 action pref = 1;
accept community.contains({3560,10}) AND AS3;
from AS3 action pref = 2;
accept community.contains({3560,20}) AND AS3;
}
Note that the common peerings between "from AS1" and "from AS-ANY
are those peerings in "from AS1". Even though we do not
define "common peerings", it is straight forward to deduce
definition from the definitions of peerings (please see
6.1.1).
Consider the following example
Alaettinoglu, et. al. Standards Track [Page 32]
RFC 2280 RPSL January 1998
import: {
from AS-ANY action med = 0; accept {0.0.0.0/0^0-18};
} refine {
from AS1 at 7.7.7.1 action pref = 1; accept AS1;
from AS1 action pref = 2; accept AS1;
}
where only routes of length 0 to 18 are accepted and med's value
set to 0 to disable med's effect for all peerings; In addition,
AS1 only AS1's routes are imported, and AS1's routes imported
7.7.7.1 are preferred over other peerings. This is equivalent to
import: {
from AS1 at 7.7.7.1 action med=0; pref=1;
accept {0.0.0.0/0^0-18} AND AS1;
from AS1 action med=0; pref=2; accept {0.0.0.0/0^0-18} AND AS1;
The above syntax and semantics also apply equally to
export policies with "from" replaced with "to" and "accept"
replaced with "announce".
7 dictionary
The dictionary class provides extensibility to RPSL.
objects define routing policy attributes, types, and
protocols. Routing policy attributes, henceforth called rp
attributes, may correspond to actual protocol attributes, such as
BGP path attributes (e.g. community, dpa, and AS-path), or they
correspond to router features (e.g. BGP route flap damping). As
protocols, new protocol attributes, or new router features
introduced, the dictionary object is updated to include
rp-attribute and protocol definitions
An rp-attribute is an abstract class; that is a data
is not available. Instead, they are accessed through access methods
For example, the rp-attribute for the BGP AS-path attribute is
aspath; and it has an access method called prepend which stuffs
AS numbers to the AS-path attributes. Access methods can
arguments. Arguments are strongly typed. For example, the
prepend above takes AS numbers as argument
Once an rp-attribute is defined in the dictionary, it can be used
describe policy filters and actions. Policy analysis tools
required to fetch the dictionary object and recognize newly
rp-attributes, types, and protocols. The analysis tools
approximate policy analyses on rp-attributes that they do
Alaettinoglu, et. al. Standards Track [Page 33]
RFC 2280 RPSL January 1998
understand: a filter method may always match, and an action
may always perform no-operation. Analysis tools may even
code to perform appropriate operations using mechanisms outside
scope of RPSL
We next describe the syntax and semantics of the dictionary class
This description is not essential for understanding
objects (but it is essential for creating one). Please feel free
skip to the RPSL Initial Dictionary subsection (Section 7.1).
The attributes of the dictionary class are shown in Figure 18.
dictionary attribute is the name of the dictionary object,
the RPSL naming rules. There can be many dictionary objects,
there is always one well-known dictionary object "RPSL". All
use this dictionary by default
The rp-attribute attribute has the following syntax
Attribute Value
dictionary mandatory, single-valued
class
rp-attribute see description in text optional, multi
typedef see description in text optional, multi
protocol see description in text optional, multi
Figure 18: dictionary Class
rp-attribute:
(, ..., [, "..."])
...
(, ..., [, "..."])
where is the name of the rp-attribute; and is
name of an access method for the rp-attribute, taking Ni
where the j-th argument is of type . A method name
either an RPSL name or one of the operators defined in Figure 19.
The operator methods with the exception of operator() and operator[]
can take only one argument
Alaettinoglu, et. al. Standards Track [Page 34]
RFC 2280 RPSL January 1998
operator= operator==
operator<<= operator
operator>>= operator
operator+= operator>=
operator-= operator<=
operator*= operator!=
operator/= operator()
operator.= operator[]
Figure 19:
An rp-attribute can have many methods defined for it. Some of
methods may even have the same name, in which case their
are of different types. If the argument list is followed by "...",
the method takes a variable number of arguments. In this case,
actual arguments after the Nth argument are of type .
Arguments are strongly typed. A type of an argument can be one