CURRENT MEETING REPORT

Reported by Howard Berkowitz, PSC International

Minutes of the Routing Policy System Working Group (rps)

IRR Status Update

RIPE, the RA, and MCI presented status reports. Snapshots of MCI's and RIPE's database sizes showed:

RIPE's general policy has three elements:

The RA Project is continuing to clean up the RADB and make it consistent. One of the major activities is deleting duplicate or bogus PRDB AS and route objects. Hundreds of AS and thousands of route objects have been removed. The server is generally being enhanced.

Tony Bates said AS macros are "the basis for almost everything we do" at MCI.

Routing Policy Specification Language

Various aspects of the Routing Policy Specification Language (RPSL) were discussed.

Aggregation

In the current language, aggregation cannot be defined. A proposal was made to extend the route object to included aggregation. The proposed "aggregate-by" attribute can generate routes from route matching, atomically from route matching, and always atomically. An "inject-at" statement would indicate whether aggregates are to be injected at specific routers or everywhere.

A "suppress-components" statement was also discussed, which has the semantics of not injecting matching routes at a specific router. An example of its use would be for suppressing more specific routes if multihoming. It was suggested that an "allow" rather than "suppress" format might be more useful.

Filtering on Full AS/Third Party

There was extensive discussion of mechanisms to split route advertisements among specific routers rather than an AS-wide basis. Sue Hare described the problem of wanting to send half the traffic on one router, and half the traffic on another. She suggested that router-level refinement of AS-level policy should be described in the inet-rtr objects as opposed to aut-num objects. Tony Bates said this was not the intent of the inet-rtr object.

For the case:

AS1-------+

| |

AS4------>AS2

(RS)

Cengiz proposed adding a "via" option to the as-in and as-out statements, as:

Where AS4 is the route server's AS. The route server might have more routes than AS1 has. What is difference between accept from AS4 (the RS) and accept from AS1 via AS4? It was suggested this might be a local preference.

This allows specification of the source of the route advertisement. Allows taking from RS rather than drectly peering. Route server does not insert himself into path where peering normally would do so.

Sue cited a case where half the policies are in the RS and half in the originating [transit] AS BGP speaker. This raised a more basic question: is a route server transparent?

Filtering down to router is more specific, but AS filtering provides a higher level of abstraction. Sue prefers to support an AS filtering need because that has been seen with real customers while router solution has not been seen.

The discussion did not reach a complete conclusion. Several emails were sent to the group between the two RPS Working Group meetings: Jerry Scharf said, There was a discussion that happened after the meeting that made things much clearer to me, and might help others as well. We have mixed two things together. One is what routes are seen in the receiving AS, which is the routing policy. The second is whether the route server will send those routes along. The second one can not be cleanly expressed by policy, since even to the receiving AS this can not be seen in any table (only the BGP session byte counts would be different.)

Cengiz responded with the model:

AS2 AS1

| |

-|---|-----|-

|

AS4

While

aut-num: AS2

as-in: from AS1 via AS4 accept AS1

can be written as

as-in: from AS4 accept AS1 AND <^AS4 AS1> (assuming we make RS's AS visible in this fashion), the following can not:

aut-num: AS1

as-out: to AS2 via AS4 announce AS1

(as-out: to AS4 announce AS1

does not tell who the route server can pass AS1's routes).

Anyway, I will look into alternate ways of doing this. Perhaps a routeserver specific solution is the best.

RPSL Dictionary

+= operator confusing, implies numeric addition which is not necessarily the case.

What is the problem it solves (Mike O'Dell)? (Cengiz) Peer doesn't need to update his parse table if I add an attribute.

This is a new syntax notation, of which there are many. How does this convey semantics? Assume an ISP doesn't upgrade and someone else upgrades the tools. The tools propagate, and the original ISP receives an object it doesn't understand. What does it do with that? (Cengiz) it approximates.

Cengiz suggests this is to extend parse tables so they won't break. Tony Li suggested this can be handled by exception routines of parsers.

Should this be an "applet?" Is there a value to download interpretable code?

DPA was used as an example. Cengiz suggests use of the dictionary shortens time for initial deployment. Eventually, tools need to change to understand semantics.

RPSL Specification

It was emphasized that the document remains in active development and discussion, and comments are welcome. It was asked if a formal applicability statement is needed.

Cengiz reviewed design goals and features of RPSL. It is generally backwards-compatible with RIPE-181++, but there are a few known incompatibilities:

interas in/out

line continuation

AS-IN keywords are optional for RIPE-181 compatibility. Action specification is optional.

Peering specificatins are more general, and offer options for using dns names instead of ip addresses. There was a discussion on when the names were binded. Options were when the object is registered, when the object is configured on a router. The binding can be done through DNS, or thru inet-rtr objects.

The syntax of prefix notation was discussed, and a consensus was reached that dotted decimal prefixes should be filled out with zeroes to the 32-bit string (192.8.0.0/16 vs. 192.8/16).

There was much discussion, without consensus, on the syntax of address prefix sets. More-specific prefixes (192.8.0.0/16*) and more-specific-inclusive (192.8.0.0/16+) were acceptable. The major controversy dealt with the notation for length expressions and range-of-length expressions. An intention was mentioned that any NLRI filter can be followed by one of these suffixes. Cengiz will develop clarifications of these notations.

DATABASE AND TOOLS

PRIDE Tools

David Kessens described some problems with updating, perl version 5, and general scaling issues with the increasing number of registries. AS0 also presented problems.

Near-real-time data base mirroring is not quite perfect, but generally working. Traceroute is benefitted by this. 2 mirrors are operational in Europe; there has been 3 months uptime with 1 day problem. Serial number needs to be refined; a suggestion was made to use the DNS serial number arithmetic I-D.

Other recent enhancements include password security for overrides. A fast connect to whois/web is used internally, but security issues limit its use outside the registry. The Berkeley DB now works; IP address indexing no longer a problem.

Under development are new hierarchical authorization methods. An alpha version is ready. Several objects have parents that are authoritative: inetnum, domain, route.

Objects are usually protected by maintainer, but objects in the hierarchy can have a maintainer that protects objects below itself (e.g., a local registry maintainer). A hack is needed to have multiple maintainers. Objects usually protected by own maintainer. Granularity for add/delete will be added in future; suggestions welcome.

RIPE now can alloate block to lower-level registry with a mnt-lower attribute.

Lookup of any purpose in database--registries will be registered in DNS RIPE.registries.int CNAME whois.ripe.net

Every registry has unique suffix for NIC handle

IRR Visualization and Geographic Attributes

George Eddy showed several IRR graphic displays. Features included display of AS membership of traceroute hops, blinking of a specific AS to make it stand out in a dense graph, and several color options to which AS have been expanded, and which have not, as well as unregistered policies.

"Group stubs" feature graphic display shows only 1 link. information available from clicking. Aliases for AS number to name -- TCL variable. Simple location display works now. Geographic display uses world map or more specific map; graphic display mode is schematic.

Techniques for including geographic information were discussed, with emphasis on whether to use a "direct" or "indirect" reference to geographic information. The consensus was to have indirect references to appropriate geographic data bases, rather than encoding latitude-longitude or political definitions in the object. An experimental geographic RR has been proposed for DNS and may be relevant [RFC1876].

An example of the complexity of direct locations cited the existence of two exchange points in Amsterdam, with more to come. These will have the same city code but different coordinates.

Other experimental work was mentioned, including geographic information at ftp://sh.wide.ad.jp/WIDE/papers/wg/softpage/map.ton.2

RAToolset

All RAtools rely on the RAdb server. The current tool version is 3.2.2; prcheck, a syntax checker, is new. The RTConfig cisco support now works. This software is at http://www.isi.edu/~cengiz/software.

RtConfig now supports cisco, gated, and RSd, and has been in production since 1995. It was asked if it supports EBGP only. Tony Bates said he would very much like an incremental approach to configuration, and cited the example of a negate and add under the context of a router BGP statement.

Configuring Cisco Routers from an IRR

Alan Barnett discussed his experience. Two RGnet routers are now configured using RtConfig tool; there have been some problems.

AS-macros inside regular expressions cause syntax errors to the database parser. RtConfig may generate long lines that the cisco routers do not like, apparently due to Cisco line length restrictions. This may be a Cisco bug. RTconfig may need to be able to split over multiple lines to deal with any plausible router software.

It is difficult to filter martian routes and routes with long prefixes. Cengiz will put martian macro into code if Alan provides it. There is no support to deny non-customers, 1597 space, IP spoofing. There is no support for packet filtering. It was questioned if this is a significant limitation, assuming RPSL's scope does not include traffic policies.

AS path prepending for load balancing is not supported.

Aggregation now by hand -- suppress-map needs to done by hand.

There is a need for a private database for testing & private information (not complete policy distribution).

Alan said overal the experience have been positive but not as easy as one would like it to be.

RADB Server

Gerald Winters spoke on the RADB server at Merit, which will soon replace the RIPE whois server. A formal announcement will be made. It is a superset of RIPE whois.

Incremental update support is needed; the server explicitly needs to be told to be updated. A short term fix is cron job demanding indexing, to be followed with builtin code.

Performance upgrades and PGP-authenticated queries will be added.

Action Plan