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
[email protected]
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.
