2.4.10 Routing Policy System (rps)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 21-Jan-99


Curtis Villamizar <curtis@ans.net>
Cengiz Alaettinoglu <cengiz@isi.edu>

Operations and Management Area Director(s):

Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>

Operations and Management Area Advisor:

Bert Wijnen <wijnen@vnet.ibm.com>

Mailing Lists:

General Discussion:rps@isi.edu
To Subscribe: rps-request@isi.edu
Archive: ftp://ftp.isi.edu/rps

Description of Working Group:

The Routing Policy System Working Group intends to provide standardization of protocols and recommended practices neccesary to support interoperability of the Internet Routing Registry (IRR). The IRR has been in use since 1995 based initially on the RIPE-181 policy language.

The activities of the RPS Working Group shall include (1) defining a language, referred to as Routing Policy Specification Language(RPSL),for describing routing policy constraints, (2) defining a simple and robust distributed registry model for publishing routing policy constraints, and (3) providing a forum for the discussion of tools for analysing registered policy constraints, for checking global consistency, for generating router configurations, and for diagnosing operational routing problems.

Goals and Milestones:

Apr 99


Submit draft-ietf-rps-appl-rpsl to IESG for publication as an Informational RFC and withdraw draft-ietf-rps-transition.

Apr 99


Submit draft-ietf-rps-dbsec-pgp-authent to IESG for consideration as a Proposed Standard.

Apr 99


Submit draft-ietf-rps-auth to IESG for consideration as a Proposed Standard.

Aug 99


Submitdraft-ietf-rps-dist to IESG for consideration as a Proposed Standard.

Dec 99


Submit RPSL to IESG for consideration as a Draft Standard.


Request For Comments:







Routing Policy Specification Language (RPSL)

Current Meeting Report

RPS WG Minutes
Minutes taken by Cengiz Alaettinoglu

Changes to draft-ietf-rps-auth
Curtis Villamizar

Curtis first gave an overview of rps-auth and then went over the changes to the draft.

as-block class is introduced to add hierarchy to the aut-num objects. IANA owns the whole as range, and assigns blocks to registries they further assign them to their customers. The chain ends in aut-num objects. When an as-block object is created, the authorization is sought in an as-block object that includes the range most tightly. When an aut-num is created, the authorization is sought in an as-block object that includes the range most tightly.

inetnum chain is similar. reclaim and no-reclaim attribute is added to inetnum class to allow address lending/ownership. The default is no-reclaim, that is address ownership. reclaim lets you delete routes/inetnums that are more specific of the inetnum even if you are not a maintainer for those objects. The rps-auth does not favor lending over ownership or vice versa. The decision is upto the parties involved.

The maintainer objects are chained together using the referral-by attribute. It also allows an automated way of creating maintainer objects. Any maintainer can create another one by including itself in the referral-by and signing the transaction. referral-by also provides an accounting trail when maintainers become unresposive.

When authorization is sought for a route object, the aut-num of the origin attribute and either the most specific route object that is less specific than this if it exists, or a most tightly covering inetnum is used (if the most specific less specific route object is not found). Once the object is found, the maintainers in either mnt-routes, mnt-lower or mnt-by are checked. For objects (other than route), mnt-lower and mnt-by is checked. That is the semantics is an or of the maintainers.

Flat names, such as nic handles, are scoped within the object's registry. When nick handle co19 is used in an object in ripe database, it is scoped to the nick handles in ripe, i.e. nick handles are not globally unique. To refer to a nick handle in another registry, one needs to prepend the registry name with :: to the nick handle, as in ripe::co19.

Repository class and delegated attribute provides traversal rules for hierarchical objects. They are now moved to the draft-ietf-rps-dist document.

Authorization rule for objects with hierarchical names (e.g. as-set, route-set) is added. The authorization is sought from the object named by the portion of the object's name to the left of the right most colon. For example, for object X:Y:Z, it is sought from X:Y.

There is a related document draft-ietf-rps-dbsec-pgp-authent. It will advance together with rps-auth.

auth-override is changed so that it is only placable if the maintainer did not do any updates in the last 60 days. It is still only active after 60 days.

We still need wording for the security considerations section.

The working grouped is explicitly provided consensus on:
- dont use mnt-routes to provide authorization to inetnum objects
- any maintainer in mnt-routes, mnt-lower and mnt-by are authorized for route objects. any maintainer in mnt-lower and mnt-by for other objects.
- to go to the last call after ietf on rps-auth and rps-dbsec-pgp

Changes to draft-ietf-rps-dist
Curtis Villamizar

Curtis first provided overview of the rps-dist document and highlighted the changes.

Distributed IRR consists of rpsl as the external data representation, rps-auth & rps-dbsec-pgp for authorization and authentication, and rps-dist for transfer format and protocols.

rps-dist adds to rpsl the repository class and delegated and integrity attributes. Repository objects helps you find other repositories. The delegated attribute is used to move subsets of the data to other registries. The integrity attribute tells whether an object is legacy, authorized, on unauthorized. For example, an authorized object can only be updated by its maintainer, but a legacy object can be updated by an authorized maintainer even if that maintainer is not listed in the object's mnt-by.

There is little distinction between a repository and a mirror. They run the same code and protocols. However, the mirror does not originate/own any data, it only stores data. There is also a "lightweight" mirror. They are not required to store the entire data set, hence they can not forward transactions. A light weight mirror can be a router.

There are 3 ways to distribute transactions: a snapshot which is analogous to ftp today, a transaction sequence request which is a poll, and flooding request which is give me everything and keep sendign indefinitely.

The data format summaries are only an issue for the implementors, not to the users. A lot of examples are added. In particular complete meta-objects used in an hypotethical transaction is included.

The refresh attribute of the repository object is replaced by the hearth-beat-rate. Each repository sends hearth-beat objects to its flooding peers (which forward these to their flooding peers) with this rate to ensure that they are not down or behind a network partition.

The multicast data distribution and fragmentation and reassembly is removed from the document. The sequence-begin object is renamed to transaction-begin object. A transfer-encoding attribute is added to the transaction-begin object to allow gzipped data transfers.

Curtis suggested that (upon request from RIPE and ARIN) the people and role objects should not be distributed. The main reason is the spammers. Instead queries should be referred to the appropriate repositories. Also for attributes with email values, a nic handle can be used to overcome privacy issue of emails. For legacy objects, the emails can be stripped out before forwarding.

Harald did not liked the fact that the standard specified which classes are not distributed. WG reached a consensus on allowing selected classes not to be distributed, but leaving the decision of which classes are not distributed to each registry. However, the policy objects have to be distributed. There was also a per object field, settable by the user, to allow redistribution or not. It was objected by the WG.

RPSL Transition Report
David Kessens

David said the phase II of the transition is done. Every registry is ready to move to phase III where the rpsl is the only data representation. However, a flag date for phase III is not set and every registry will decide on the date on their own pace.

David also wrote an RPSL to RIPE181 converter to ease moving to phase III. He said this tool can only convert simple objects.

IRR Coordination issues
Abha Ahuja

Abha is maintaining a web page http://www.merit.edu/radb/list.html of routing registries. The page contains for each registry where to get their data, ftp sites, whois servers, mirrors and such. She is also planning to make the data of each registry available for ftp from their server. She also maintains a mailing list irr@merit.edu for routing registry operators. Send email to ahuja@merit.edu to join.

RPSL Implementation in RAToolSet
Cengiz Alaettinoglu
this section of the notes are taken by Curtis Villamizar

RPSL is 100% implemented in RaToolSet

There are a lot of new RaToolSet featues and more to be added.
RatoolSet 3.* Ripe-181 only
>=4 RPSL only

review usage of the RtConfig toolset

review new features
- full community handling
- filter set, peering set, router set

support new cisco prefix lists

structures policy is now supported (RPSL refine and except)

file cache (Rtconfig -f filename) useful for testing

new options:
- -cisco_dont_do_maps
- access_list <filter>
- aspath_access_list <filter>

switching from v3 to v4 RaToolSet:
read the README and README.v4 and Changes and man pages
command lines and defaults differ

IRRd transition to RPSL
Jerry Winters

Merit retired the old perl based server code this February. The transition was flawless in that hardly anyone noticed. The resaon was mainly performance. They are also considering round robin dns for load balancing their server. The load on their server is increasing exponentially.

Merit's plan for phase III is to have RPSL supported in IRRd and use it. They are currently working on this. The irrd query interface is already fully RPSL capable. There are also two new commands to expand as-sets and route-sets.

As for rps auth, they have the old pgp scheme they had in place. They have not yet converted to rps-dbsec-pgp.

IRRd also allows TCP connections for object update. This is useful for tools like aoe/roe/irrj.

IRRd has pipelined modules. These modules dont share data structures, and perform small task such as
- convert ripe181 to rpsl
- rpsl/ripe181 syntax checking
- pgp authentication.

Hence, he expects supporting rps-auth to be easy. Cengiz suggested to use rpslcheck for the rpsl syntax checking.

As for rps-dist, it is not supported yet. But they will eventually implement it. Their first priority is to convert to RPSL and then support rps-auth which are both more important than implementing rps-dist.

IRRd has some other cool features: It can handle very large objects better, it tells the line number of the error and put an error pointer (i.e. <?>) where the error is seen, interactive user interface to reconfigure IRRd without killing and restarting the server, access lists for queries, updates and mirrors, filter specifications for what classes to import and export to and from other registries, to get statistics.

IRRj is a GUI java client that can do database updates.

Performance of IRRd is impressive. Their ~30M router configuration of the mae-east router went under 3 minutes from over 4 hours. The file is generated using RtConfig.

A gamma version of IRRd is freely available at www.irrd.net.

Closing Remarks

Curtis suggested a new work item for putting public keys to the route objects for secure BGP. He and Charlie will write a separate new draft and make it ready for the summer IETF. Bert, the AD present, approved the work item.


None received.