2.4.12 Routing Policy System (rps)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98


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 will (1) define a language, referred to as Routing Policy Specification Language (RPSL), for describing routing policy constraints; (2) define a simple and robust distributed registry model for publishing routing policy constraints; and (3) define a set of tools for analysing registered policy constraints, for checking global consistency, for generating router configurations, and for diagnosing operational routing problems. It is expected that RPSL will enter the standards track.

The RPSL will be routing protocol independent as well as router configuration format independent to support various routing protocols such as BGP, IDRP, SDRP, and various router technologies. The RPSL will be backward compatible with RIPE-181 whenever possible; the registry model will be based on the RIPE database.

The working group will focus on inter-domain routing protocols, but will also instigate, review, or (if appropriate) produce additional RFCs to support other protocols such as multicasting and resource reservation.

Goals and Milestones:

Jul 95


Submit initial draft specification of RPSL as an Internet-Draft.

Jul 95


Submit draft specification of tools and the database model as an Internet-Draft.

Sep 95


Submit revised Internet-Draft.

Dec 95


Submit document on RPSL and Experiences to IESG to be considered for publication as an RFC.

Jan 96


Submit RPSL specification to IESG for consideration as a Proposed Standard.


Request For Comments:







Routing Policy Specification Language (RPSL)

Current Meeting Report

RPS Work Group Minutes - December 10, 1998

Minutes were taken be Curtis Villamizar except the portion of the meeting where the RPS Charter was discussed. Minutes in this part of the meeting were taken by Cengiz Alaettinoglu.

Agenda Bashing (Cengiz Alaettinoglu)
RPSL transition (David Kessens)
ARIN (?)
RIPE (?)
C&W (?)
RA (Merit, Craig Labovitz)
ANS (Curtis Villamizar)
ISI (Cengiz Alaettinoglu)
RPSL Changes in New Draft (Cengiz Alaettinoglu)
Feedback on the rps-auth draft (Cengiz Alaettinoglu)
IRR Secure Gateway (Ramesh Govindan)
Discussion of Work Group Charter (Curtis Villamizar)

Agenda Bashing (Cengiz Alaettinoglu)

Cengiz presented the meeting agenda. It was suggested that the discussion of the work group charter be deferred to the end of the meeting to allow extended discussion. This suggestion was accepted.

RPSL transition (David Kessens)

David highlighted the three phases outlined in the RPSL transition draft. David then gave a brief summary of the status of the software available. The software is:

BIRD (new development)
RIPE registry software with RPSL extensions
RIPE-181 to RPSL converter

A few user trainings on RPSL have occurred. One was at NANOG, one at RIPE, one is planned for APRICOT.

Phase II is now complete. We have software, it has been tested by numerous parties, user trainings have occurred. Some providers are into phase III already.

A meeting was held on Monday with developers and those known to be running the registries or known to be actively working toward running registries. Present were ANS, Cable and Wireless, the RA (Merit), Qwest, ARIN, APNIC, RIPE, Connect. CANET-III and Bell Canada were present by proxy (they described to David their status prior to the meeting).

Brief statements of status were given at the RPS meeting by:

ARIN (?)

- Looking at RIPE with RPSL extensions. Also looking at IRRd but this seems less likely. The RIPE code based will be modified to use an Oracle backend. A request was made that they present performance findings at the next IETF. They hope to be online in early 1999, maybe January.

RIPE (Joao Luis Silva Damas)

- Using the RIPE perl code. They are rewriting the code from scratch in C. The new code will support RPSL.

C&W (?)

- Cable & Wireless is the former InternetMCI. They are running older RIPE code with lots of private modification. They plan to be ready by the dates agreed to at the meeting.

RA (Merit, Craig Labovitz)

- Running RPSL in IRRd in a test database for 6 months now. Migrating the RADB to ARIN is under discussion.

ANS (Curtis Villamizar)

- RPSL capable configuration code had been tested by last IETF but not deployed. Hoping to get real time mirroring deployed in the same cutover but could transition now.

ISI (Cengiz Alaettinoglu)

- RaToolSet 4.3.0 is out. BIRD is still under development.

It was agreed at Monday's meeting that by February 15 all of the registries would have RPSL data available. At the next IETF we will confirm readiness to shut off RIPE-181 after the IETF meeting in those providers that are ready to shut it off.

RPSL Changes in New Draft (Cengiz Alaettinoglu)

All of the changes agreed to in Chicago and Los Angeles meetings are in the current draft. Two additional changes were made. These are:

- draft-ietf-rps-rpsl-extending-00 was merged in.
- A leading "+" is allowed as an additional way to indicate line continuation. This is in support of the ability to store objects with blank lines, in particular PGP keys.

There were two requests for additional changes:

- Add a formal grammar (requested at the last IETF meeting)

- Add a list of changes from the previous version. A list had been sent to the mailing list but did not appear in the draft.

Because there were changes, the RPSL draft must be recycled as a Proposed Standard. After the two changes above are made a work group last call will be repeated.

Feedback on the rps-auth draft (Cengiz Alaettinoglu)

BIRD now implements all of rps-auth except: reclaim, no-reclaim, auth-override. The following comments on the draft have come from this implementation:

- There is no mnt-lower in the draft. RIPE had implemented this and a need for this is seen. mnt-routes applies to routes only.

- The syntax for mnt-routes is not explicitly stated.

- It was suggested that the repository and delegated objects might be candidates for moving to rps-dist since a central implementation of rps-auth would not need them. The counter argument is that rps-dist contains no extension to the RPSL language, just contains the encapsulation needed for exchange between repositories.

There were a number of more minor comments:

- We don't really need a referal-in. This can be deduced by the inverse query on referal-by.

- Deletion of a maintainer is not allowed if the maintainer is referred to in a referral-by. There was some discussion about this feature. It was decided that it should remain as is.

- Route authorization could fall within the hole attribute in the route object. It was decided that hole is a comment and so this should carry no implications.

- If there is no aut-num, should the as-block be used for authorization of a route addition? Currently the answer is "no". It was decided not to change this.

- The auth-override is effective within 60 days. This should be a default, changeable on a per registry basis and reflected in the repository object. If the maintainer has made any changes in the last 60 days (or whatever the time period), then the auth-override should not be placeable.

- The default for reclaim/no-reclaim is currently implied to be no-reclaim but should be explicitly stated and should be reclaim.

- We don't have a no-delete to guard the lower in mnt-lower from deleting the entry. Consensus was we don't need one.

- The rules for as-set and route-set addition are defined in RPSL and should be repeated in rps-auth.

IRR Secure Gateway (Ramesh Govindan)

There is a need to transition from the current set of routing registries to a set of registries capable of rps-auth and rps-dist.

One method of transition might be to create a gateway between the non-rps-auth/dist registries and the rps-auth/dist capable registries.

There was some discussion but no conclusion as to whether there was better ways to handle the transition to rps-auth. The gateway provides an easy way to deal with the issue of non-rps-dist and rps-dist capable registries.

Discussion of Work Group Charter (Curtis Villamizar)

The body in the new charter did not significantly change, particularly the focus of the work remained the same. The milestones are brought up to date to reflect the reality. New charter has three changes to the old one, new wording of the first paragraph, reducing scope for tool development, and changing the phrase "resource reservation" to "inter domain quality of service". It was decided to keep the first two changes, and drop the last paragraph altogether. It was noted by the group and the AD that this did not stop the working group from supporting QoS if and when it become important for inter domain routing coordination.

The new RPSL internet draft will be recycled as proposed standard. No more changes are expected (allowed) unless operationally absolutely necessary. After 6 months, the WG will ask for draft status.

Do we need one of the following documents: rps framework and rps-dist transition plan? Again, no decision was reached.

During the discussions, audience provided valuable feedback, it was agreed that the RPS WG work was important for the operations of the Internet. When asked, a surprisingly high number in the audience have already read the documents and committed to providing feedback on them.

It was discussed once the document specification work is over if there was a need for a working group for deployment discussions. The answer (thru clear show of hands) was yes. It was later asked if it should be the RPS WG with a revised (deployment focused) charter or a new WG. The consensus was to keep the RPS WG, but to finish with the documents as soon as possible and focus on deployment. It was suggested that a new WG would be disruptive. With the exception of rps-dist, the WG committed to finishing document work by Minneapolis IETF.

Curtis Villamizar will revise the charter as discussed and send it to the WG and issue a WG last call that will end on January 7th. Cengiz Alaettinoglu will add a section to RPSL highlighting the changes from RFC 2280 and another providing formal grammar rules, and ask for a WG last call to move it to proposed standard in December 1998. Cengiz Alaettinoglu and Curtis Villamizar will incorporate rps-auth feedback that was discussed and ask for a WG last call for a proposed standard in January 1999.