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