NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 27-May-99
Curtis Villamizar <email@example.com>
Cengiz Alaettinoglu <firstname.lastname@example.org>
Operations and Management Area Director(s):
Randy Bush <email@example.com>
Bert Wijnen <firstname.lastname@example.org>
Operations and Management Area Advisor:
Bert Wijnen <email@example.com>
To Subscribe: firstname.lastname@example.org
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:
Submit draft-ietf-rps-appl-rpsl to IESG for publication as an Informational RFC and withdraw draft-ietf-rps-transition.
Submit draft-ietf-rps-dbsec-pgp-authent to IESG for consideration as a Proposed Standard.
Submit draft-ietf-rps-auth to IESG for consideration as a Proposed Standard.
Submitdraft-ietf-rps-dist to IESG for consideration as a Proposed Standard.
Submit RPSL to IESG for consideration as a Draft Standard.
Request For Comments:
Routing Policy Specification Language (RPSL)
RPS WG Minutes
Taken by Susan Harris & Curtis Villamizar
Cengiz: Update on draft-ietf-rps-dist
Cengiz' presentation focused on changes made to the draft since the last IETF. These are mainly fairly minor syntax changes, as follows:
- Modifications to transaction submission encapsulation, with a submission defined as a collection of RPSL objects. It's now possible for submitters to add a timestamp meta-object, which can be used to guard against replay attacks. This applies to local submissions, i.e., submissions to a respository by a user or process. A set of submission processing rules determined how these are handled by the respository.
- Modifications to transaction redistribution, which itself has two phases: preparing the redistributed text with the appropriate identification and authentication information, and preparing an on-the-wire representation of the transmitted text. New transaction labels contain information about the originating repository, the sequence number, repository timestamp, and, optionally, the transaction's authorization status. Transaction labels are never modified by intermediate repositories. Before transmitting the redistributed text, the originating registry adds a (new) transaction-begin meta-object specifying the length of the redistributed text and encoding method.
New transaction processing rules outline the steps the repository must take before registering the object.
Useful new capabilities are available for requesting an exchange of objects between two repositories. A request can now specify something like "I already have objects in sequence up to number xx - send me any additional records as they're submitted to you." In this process, known as flooding, the connection stays open so new objects can be transmitted. New heartbeat messages containing the highest sequence number and timestamp are used to resynchronize the two repositories after a restart and to recognize partitioned registries. In one mode of operation a sequence range (from xxx to yyy) is requested.
Cengiz presented a proposal for an authorization hierarchy rooted at ICANN.
The public key of the hierachy root is distrubuted with the software.
The root of the authorization hierarchy contains:
- a 0/0 intenum
- an as-block with 0-65,535
- ICANN needs to register and sign these.
- ICANN does not need to run a repository.
To create other registories the following objects are needed:
- a repository object
- repository key certificate(s)
- repository maintainer object(s)
- These need to be signed by ICANN.
Randy Bush pointed out that the IAB has an official relationship with IANA for operational issues such as this where ICANN is more of a policy making body. After a bit of dicsussion there was consensus to change ICANN to IANA.
Joao presented a proposal to specify a common query language.
In one of his slides Joao presented a table of current implementations. There were 4 implementations in the table with 4 query formats.
Essentially a few questions were asked by the presentation:
- Is a common query language needed?
- Does anyone have any ideas as to what it should look like?
- Should it support the IRR needs only?
- Should it be separate from whois?
- Should there be a common subset with extensions for different uses?
The following comments were made.
- IRRd wants to be compatible with RIPE.
- The RIPE query language doesn't adequately support queries needed for router configs.
The final questions were:
- Should these query formats be compatible?
- Should they be be standardized?
Randy Bush commented that this should not be done in this group. Curtis and DAvid Kessens suggested that RIPE should be a good candidate. Consensus seemed to be "yes" for both questions but a RIPE WG would be a better place to do the standardization than IETF.
Joao presented the RIPE database re-implementation.
Performance is not what it should be in the current implementation. There are about 280,000 objects and a high query load.
Code maintenance is also an issue. The code has been evolving and is now difficult to maintain and extend.
A block diagram was presented showing how the components of the current server fit together.
A block diagram was presented showing the components of the new server. The new implementation can be distributed over multiple machines.
The new server is split by functionality, with a (commercial) RDBMS at bottom. A lot of functional block are currently being implemented and will be tested in the end of July. A test server should be available in August.
For more info there is a mailing list under majordomo. The information on this is at http://www.ripe.net/db.
There are plans to implement the core part of rps-auth ASAP. The non-core part of rps-auth may be implemented later. There are no plans for rps-dist yet and no decision to go forward with rps-dist. RIPE needs proof that there is some gain to doing rps-dist.
Craig Labvitz presented the status of IRRd and Merit transition to RPSL. These were Gerald Winters' slides.
There are two RIPE-181 machines, and one RPSL machine.
Merit allows RPSL queries only today. Merit will start allowing RPSL submissions RSN.
On July 1st there were 35,307 connections, 262,049 queries using RIPE-181. In four months there were 80,234 connections, 80,679 queries.
Craig asked if anyone minded if the default submission format was switched to RPSL. There were no objections.
Code is available for IRRd. It is fast, etc. Development of rps-auth is underway. Development of rps-dist is on the back burner.
There seem to be about 40 sites that are doing regular mass queries that may or may not be configuring routers.
Cengiz commented that he sees a lot more usage of RaToolSet and bug reports on RaToolSet since MERIT went production on RPSL IRRd as opposed to the older non-supported server.
Cengiz gave a presentation on the status of BIRD.
There is an alpha implementation available now. The production release should be available at end of summer. The URL is ftp://ftp.isi.edu/ra/BIRD.
There are 2 parts to the software architecture. The registrar handles registration. The server handles queries.
Berkeley DB was used. Reasons include the following. It is recoverable. It supports a shared cache between processes implemented using mmap. It offers superior performance to alternatives including RDBMS. The latter conclusion was based on tests run against postgress and GDBM.
Some key features of the server are, non-blocking, non-forking, cache, good indices (supports fast lookup, no computation).
Some key features of the query language are the following. an attempt was made to be like the RIPE server. There is functionality missing from the RIPE query format that is needed to support tools. BIRD adds 4 queries (that begin with -bird is launched from whois).
Key feature of the register include the following. It supports all of RPSL. The core rps-auth functionality is done. The non-core will be done later. All of rps-dist is done except snapshot. BIRD also supports ftp transfer and ripe real time mirror.
Performance is excellent except cold start which takes 4-5 hours. Cold start in this context means starting from initial ftp of repositories and only has to be done once ever. There is no reindexing in this architecture.
Some user tools are missing. Tools for the registrar are email, web-cgi. Both need to be written. Tools for the server are RaToolSet and a web/cgi interface. RaToolSet works. The web/cgi needs to be written.
The configuration supports general options, repositry configs, language extension options.
Configuration is in RPSL format but is not stored in the database.
The local repository configuration includes whether the repository is public or private and if public whether specific classes of objects are private.
The remote repository configuration lists the remote repositories. Discovery can be enabled. Discovery means an repository mirrored by a peer is mirrored.
The legacy repository configuration includes whether the legacy repository can do ftp or real time mirror or both. For example, you can mirror every 30 minutes and ftp once a day from a repository. It automatically converts RIPE-181 to RPSL.
The set of classes accepted is configurable. The classes are extensible using the RPSL dictionary capability.
BIRD implements rps-auth core now. It does rps-dist replictation. It will do rps-dist snapshot soon.
Cengiz presented the work group document status and futures.
RPSL has been PS. It could be advanced to Draft status. The applications doc is at -06. It has passed the IESG review as an informational document and is thought to be in the rfc-editor hands.
The were minor changes to rpsl-auth. There were spelling errors and grammar errors. There are now definitions of non-core and core functionality.
The rpsl-dist document still needs at least one major revision.
The rps-auth draft did not go into the internet drafts directory for some reason. Curtis will resubmit as soon as IETF is over. Most important is rps-auth -04 version.
Distributed Routing Policy System
RIPE DB re-implementation
BIRD: Design, Features & Status
RPS ICANN Issues