NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Cengiz Alaettinoglu <cengiz@isi.edu>
Daniel Karrenberg <dfk@ripe.net>
Operations and Management Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uu.net>
Deirdre Kostick <kostick@qsun.att.com>
General Discussion:rps@isi.edu
To Subscribe: rps-request@isi.edu
Archive: ftp://ftp.isi.edu/rps
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 analyzing 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:
· Representing Tunnels in RPSL
· Routing Policy Specification Language (RPSL)
· A strategy for the transition from RIPE-181 to RPSL
· Application of Routing Policy Specification Language (RPSL) on the Internet
Minutes of the Routing Policy System (RPS) Working Group
Reported by: Ramesh GovindanCengiz Alaettinoglu started the meeting by describing changes to the RPSL specification. The first change involves adding a new exception specification to the as-in statement. This doesn't change the expressivity of the language, but makes it convenient to express exceptions, and makes it less error-prone. Exceptions may be arbitrarily nested. A second change is in support for tunnels. For this, we need to modify the ifaddr statement to add an identifier for a tunnel. To the tunnel object, we added a way to specify the tunnel encapsulation mechanism, and a way to specify the tunnel protocol. Changes to the community attribute include allowing a list of communities to be specified with the "contains" method. Also changed the next-hop attribute to allow assignment to "self." Cengiz asked whether the document could be forwarded for IESG consideration. No one present dissented.
Dave Meyer’s talk described the Internet-Draft "Application of RPSL on the Internet." This document explains how RPSL might be used to specify policy objects: the document describes examples of common objects, some canonical policy examples, and the use of tools. The document also discusses a preferred naming convention for AS sets or AS macros and other high-level objects. Dave presented several examples described in the I-D. There was confusion about the use of <> in one of the examples: Randy Bush and Alan Barrett explained the difference between the use of <^AS3582$> and AS3582 in the policy filter. Cengiz suggested including both examples in the draft. Randy suggested explaining in greater detail the semantics of regular expressions used in policy filters, specifically in the provider-provider policy description. Some discussion in the RtConfig description about Cisco's AS path length limitation: Tony Bates indicated that the 255 character limit had been fixed. Dave also suggested adding to the draft some text about how to manage an aut-num object. Cengiz said that the recommendations specified in the applications draft would be implemented in aoe. One question was whether roe worked on the RIPE database: RIPE doesn't have an updated whois server, but will soon have according to Chris Fletcher. In the meantime, Cengiz suggested the use of the RA whois server, which mirrors RIPE data and can update RIPE registry.
David Kessens talked about the transition from RIPE to RPSL. A modification to the RIPE database for RPSL is well underway. The transition plan involves allowing RIPE-181 syntax for updates as long as possible, as well as having tools recognize both syntaxes. The transition plan has four stages, each stage taking approximately two months. Allow RPSL use now, but initially have RIPE-181 as default. Stage One tests server software: in addition, tutorials at Nanog and
RIPE to encourage use. Stage Two integrates RPSL capability in tools. In Stage Three, run two databases in parallel, with the old format server on the old port and the RPSL-capable server on a new port. In addition, at this time, old data will be converted to RPSL format. In Stage Four, RIPE and RA will switch their servers to RPSL. Tony Bates asked whether two months per stage is realistic, particularly because some providers have their own tools and internal extensions. Tony suggested having hard timelines, otherwise in his experience from transitioning from Ripe-81 to Ripe-181, things never move on. Randy pointed out that other providers will also have to update their tools before transition happens. Tony also said that, to give providers incentives to switch, the document should be forwarded onto the standards track.
RPSL implementation in RAToolSet. As the last talk, Cengiz presented a tools update. Specifically, some of the tools have been made RPSL-capable. These changes are now in alpha-test. Changes include: more specific route operators, aspath prepending, community attributes (lacks operator methods). Also, as a transition mechanism, if a policy object has rpsl-in/out, tools will use that as opposed to as-in/out (which may be in RIPE format). Before tools can be used, need database support for syntax checking.
2. RAToolSet Update: RPSL in RAToolSet