Routing Policy System BOF (RPS) Reported by Howard Berkowitz/PSC International and Cengiz Alaettinoglu/ISI Agenda No significant changes were made to the initial agenda, which included: o RPS Group Logistics o Review of RIPE-181 -- Daniel Karrenberg o Review of RPSL -- Cengiz Alaettinoglu o Registry discussion -- Daniel Karrenberg o Tools discussion -- D. Karrenberg and C. Alaettinoglu o AS690 policies -- Curtis Villamizar Charter It was agreed that the RPS group's charter would include the Routing Policy Specification Language (RPSL), the associated Distributed Registry Model, and identification of and requirements for tools. History Early work in routing policy selection began with the NSF-centric PRDB model. RIPE introduced RIPE-60, later refined it into RIPE-81, and most recently RIPE-181. RIPE-181 still has limitations that the more general RPSL work will address. RIPE-181 will be the starting point for the RPS group's work. One major area is the use of regular expressions in routing policies. RIPE-181 Tutorial Slides are available in ftp://ftp.ripe.net/pride/docs. Policy registry relies on several key principles: o Describe a policy locally o Register it in an appropriate policy registry o Propagate it, but only as far as the peer AS Remaining issues include: o How is the global policy derived from local exchanges? o How is the global graph built? Benefits of enhancing the model include improvements in the routing registry. Registered routes may be propagated concisely, as in a single grouping from an originator, macros for other groups of ASs, and other groupings such as routing communities. Group membership relations will be authoritative. Aggregation (e.g., CIDR) information is available. Another useful feature of a registry is to document withdrawn routes. For example, some customers may have withdrawn addresses or routes, or a route is to be installed or is not yet operational. Such ``future'' but operationally significant information can be announced. Holes in the routing structure can also be documented. Proxy aggregation that avoids route flapping can also be documented. To recapitulate major potential benefits, the sets of all routes in the Internet can become available. Policy can be specified with regard to groupings, and the grouping information will be authoritative. Currently available grouping information is non-authoritative. The existing RIPE RIPE-181 registry provides a registry for Europe, based on a modified Whois model. It contains route and autonomous system objects. Route objects give the identifier, policy(ies), and maintenance information for a route, and describe community membership information appropriate to the route. An AS object also specifies policies, formulated as accept/reject rules, preferences on acceptances, and relative costs. It can specify transit policies. Policies can be described for multiple connections between ASs, with granularity to the link level. How to Register in RIPE Registry This procedure is RIPE specific, but other registries have adopted or are considering it. The update procedure: o E-mail to auto-dbm@ripe.net o Objects checked and incorporated o Objects can generate warnings (correct and accept) and errors (reject) o Delay is effectively set by e-mail system o Ack sent back to sender by e-mail At present, there are 250,000 updates per year, including the Whois server. RFC 1786 is an Informational RFC, which describes RIPE-181. RPSL Goals RPSL should express preference policies on input and express access restriction policies on output and should support other policies (e.g., multicast). Level of Detail RPSL's level of detail should not be excessive, but needs to be adequate. Remember that it is not intended as a configuration language, but tools can be developed to generate vendor-specific configurations from RPSL specifications. The general model is to be able to say ``if some decision D on policy depends on some attribute or mechanism X, RPSL should abstractly model X.'' In developing the appropriate level of complexity, it was observed that most domains have simple policies, and RPSL specifications for such domains in turn should be simple. Domains with complex policies, however, need the ability to model those complicated interactions. Protocol Independence RPSL should have a way of expressing policies for other protocols such as RSVP and multicasting. In the routing protocols context, it may be used for multiple routing protocols (e.g., BGP, IDRP). Vendor Independence RPSL is not intended as a configuration language, although vendor-specific configurations can be generated from RPSL specifications using appropriate tools. Tools Some tools exist that work with pre-RPSL specification languages. Other tools need to be defined. Representative tool requirements include: o Configuration language generator o Analysis and diagnosis - prpath - prtraceroute - peval - aggchk RPSL, however, must not be restricted by the needs of a specific tool. Extensibility RPSL should be extensible. Potential extensibility requirements include new policy mechanisms (e.g., colors), as well as new protocols. RIPE-181 Compatibility A RIPE-181 notation to RPSL converter is needed. This leads to the question: ``why not simply use RIPE-181?'' It was observed that RIPE-181 is not extensible and has inadequate functionality. Discussion of RPSL Technical Details Implementation experience with the override and complement operators were requested. Overrides were described as easiest to implement. It was asked if the current procedures provide a standard facility for unknown conflicts to be brought to the person who introduced them? In response, no standard tool exists but a problem list is produced. In RIPE-181, the * * case (as-in) is superset of local policies (interas-in). It would be an error to say a general policy is to accept AS1 and AS2, but to allow AS3 in a more specific rule. It was commented that it is much easier to read and hand-edit overrides/complements rather than RIPE-181. RPSL specifies policies for specific peering on a particular interface. It was noted that there is a need for a mechanism to separate multicast and unicast policies. It was also commented that a triplet of an AS number and two router addresses may not be adequate to identify a BGP peering. RIPE-181 now allows filtering on address prefix (implemented by matching against NLRI), AS number (NLRI), communities (NLRI or BGP communities), and AS macros (NLRI). As extensions for RPSL, the AS path was mentioned as useful for an export policy. Desirable extensions mentioned in discussion include AS path regular expressions, next hop address, color, confederation (RD_PATH), and indeed arbitrary attributes. In addition to filters, policy actions need to be specified. These include setting preference, multi-exit discrimination, exclude lists, and AS path length based preference. A dictionary object was proposed. Discussion on this observed that any tool needs to know the relationship between the rpsl attribute (e.g. MED) and protocol attribute (MED and LOCAL-PREF). Semantics must be clear; semantics are not implicit in the language but are known by tools. RPSL macros, both global and local, do not replace the community objects. Community objects need to include maintainer and routes. Scope of macros were discussed. There was concern for local vs. global macro forms. A comment was made suggesting no nesting at all. ``$foo'' would be treated as a local definition, and as an error if undefined, even if there is a global definition for it. A notation for sets of address ranges is needed. Beyond the CIDR ``10.0.0.0/16'' format, there is also a need to ``match a prefix and more specifics'' of the form ``10.0.0.0/16+''. There is also a need to express ``10.0.0.0/16+ and not 10.0.0.0/16''. The latter notation may be needed while aggregating to suppress more specific routes. Support is needed for IDRP confederations. Support needs also exist for describing physical topologies. The existing database specifies peerings, but some tools need additional physical information. It was commented that inet-router objects are a means to code physical topology. It was also commented that ANS captures the physical topology, typically the link metrics, in the comments in the aut-num objects. It is commented that the ability to record internal topological information is useful not for policy formulation but for debugging. It was observed this is not an alternative way to encode gated language. This is a way of expressing possibilities. Do not constrain language because some routers cannot implement a particular policy. This is a metalanguage. Distributed Registry Model for the Internet Routing Registry At present, there is crude but working model in which every object has source attributes (e.g., MCI, RIPE, etc.). An object may be registered with multiple sites. Registries keep local copies of other registries' databases. In discussion, it was questioned how information is selected in multiple places. In one approach, the server has an order of preference, a sequence from which humans can make inferences. There was no consensus if an object should be registered in one or more than one place. A scope rule is presented to alter and precisely define how the information is selected. Synchronization mechanisms are needed, although not with the complexity of DNS. Synchronization would be as of a point in time. FTP copies are adequate and do not scale. A history mechanism was suggested, with FTPable difference files. People are working on history mechanisms. Atomicity is an issue when more than one database is involved. Multiple updates may be needed. The existing IRR is a set of registries with flat organization (RIPE, RADB, MCI, CA*Net). This organization does not scale. A hierarchical model for IRR may be more appropriate. It was observed that it might be useful to separate language from where we store it. Both are within the scope of the working group. Logistics may be a future item. Predefined macros are introduced for retrieving all of the routes from registry(ies). $ROUTES is a predefined macro which expands to the set of routes in this database, $ASNS is a predefined macro which expands to the set of ASs in this database. How do registries coordinate adding new attributes? It was commented that the working group should come up with a document for this. There was a concern for RPSL to have source address based policies. Mechanisms to add source based and application type of service based policy constraints are to be added. Tools PRIDE has some tools and is doing research, including: o prtraceroute: Inputs: real network traceroute, routing registry. Returns AS path. Allows policies to be checked. Looks like traceroute version with additional information on AS. Prints out UTC time and the from host. Column indicates whether hop is internal or external, and if it matches policy/preferences. o prpath: Lists all possible paths between two ASs. Use of this tool showed many more paths existed than ``experts'' thought. Shows unknown backdoors. Finds and checks backup paths. o prcheck: Checks routing policies for internal consistency and consistency with peer domains' policies. Merit has some tools, including: o aggis: Classless to classful; classful to classless converter. o aggchk: Lists potential aggregates. o Report generators o MRT (Multi-Threaded Routing Tool): See http://www.ra.net/mrt/mrt/html. RA has tools, collectively called RAToolSet, which includes: o radbserver: Extended Whois server with optimized queries. o peval (policy evaluator): Inputs: a policy expression. Outputs: a policy expression with possible expansions and evaluations. o RtConfig: Gated config file generator from RIPE-181. CANet has ported this to support Cisco formats. o Future RAToolSet framework was also presented. Discussion of Tools and RPSL More intelligence and protocol knowledge is needed in the tools to handle rpsl attributes. Events are easier. Tools already know some semantics. It was agreed the RPS Working Group may specify, but will not develop, tools. AS690 Policies In MEDs, or cold potato routing, AS690 typically takes the longest path through an internal network before going to the destinations. MCI is providing lots of routes that will simplify this. There is a need to review the inherited PRDB, and answer the question concerning why there are multiple routes ending in same CIDR block. The NSFNET backbone server goes away on 1 May. PRDB needs to be replaced. NACR's were a way to store policies. Typically what primary AS did you want to hear from, secondary, tertiary, etc. Now this is being replaced with RIPE-181. New policies are of the form: as-in: from BorderAS cost accept ASx AND NOT {} interas-in from AS rtr1 * accept {prefix} Wildcard syntax makes more readable to mean any router that peers with our rtr1. It is suggested to include a syntax which allows the following: interas-in: from AS1 {lrtr1 rrtr1 pref1, lrtr2 rrtr2 pref2, ... } accept routing policy expression Working Group Plan A consensus was reached to form a working group and continue this activity as an IETF one. A consensus was also reached to add everyone in attendance to the mailing list. Deciding the action items and asking for volunteers to do the work are deferred to the mailing list.