Editor's note: These minutes have not been edited. Slides (in the order of presentation): ftp://ftp.isi.edu/rps/agenda.ps.gz ftp://ftp.isi.edu/rps/aggregation.ps.gz ftp://ftp.isi.edu/rps/3rd-party.ps.gz ftp://ftp.isi.edu/rps/dictionary.ps.gz ftp://ftp.isi.edu/rps/rpsl.ps.gz ftp://ftp.isi.edu/rps/david-ripe.ps.gz ftp://ftp.isi.edu/rps/location-proposal.ps.gz ftp://ftp.isi.edu/rps/vis-screens.tar.gz ftp://ftp.isi.edu/rps/ratoolset.ps.gz ftp://ftp.isi.edu/rps/alan-barrett.gz ftp://ftp.isi.edu/rps/radbserver.ps.gz The minutes: RPS WG Minutes by Howard Berkowitz IRR Status Update ----------------- RIPE, the RA, and MCI presented status reports. Snapshots of MCI's and RIPE's database sizes showed: RIPE MCI (provided by mail between sessions) ---- --- AS 686 230 Macros 41 66 Routes 12890 23142 Maintainers 520 197 Communities 7 N/A Domains 25520 N/A Networks 44369 N/A Inet-rtr 89 N/A Persons 58122 N/A RIPE's general policy has three elements: new AS must register encourage people to register policy during training courses for registries go after people to get them to register policies 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: as-in: from AS1 via AS4 5 accept AS1 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 WG 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 Goals Extensibility for protocol attributes, router features, and completely new attributes Survivability -- new objects can register without software update Can be thought of as autoconfiguration for tools. RPSL attributes can correspond to protocol attrbutes (dpa, community, etc.), router variables (local-pref, cost) special functions (route dampening). an RPSL attribute is an abstract class...no assumption about internal representation. It does have a method, the realization of which can be implementation specific. An example was shown for MED. Method-name can have any number of arguments. Non-optional comment describes the semantics. Methods can be names or operators. += 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 ----------- Keep working on RPSL Tools (Randy Bush noted there has been significant progress, and tools are especially needed by small ISPs). Distributed Registry Architecture