Here are the draft minutes of the last Routing WG. Comments welcome, -- Jean-Michel ------------------------------------------------------------- RIPE Routing-WG Draft Minutes Amsterdam, Tuesday May 17th 6 hours Minutes: Jean-Michel Jouanigot, Gilles Farrache (scribe) 0. Previous minutes, agenda. The previous minutes and the agenda were approved. Gilles Farrache voluntered (?) as a scribe. 1. CIDR deployment status CIDR development is progressing well. All the organisations that participated in this effort should be thanked and the networks that did not yet convert to CIDR should do it as soon as possible. Tony Bates presented a few graphs on the evolution of the number of routes and paths in the Internet. The slides (and other useful data) are available from ftp.ripe.net:/cidr. Computations are made on an AS basis to estimate the routing table reduction if these ASes convert to CIDR. The reader is encouraged to study these data. We can observe a quite significant decrease of the number of routes (20400 down to 18400) and paths (53000 down to 50000), but this is probably not going to last very long. Regular messages are sent by the Ripe NCC and list the first 10 Autonomous systems that would really save a significant amount of routes if they convert to CIDR. If your AS is listed in there, you should definitely do something! With the recent development of CIDR in the Internet, the current model for policy based routing has to be reviewed, since aggregates are not taken into account. Two proposals have been made: one from Tony Bates, Marten Terpstra and Daniel Karrenberg (Ripe NCC) and another one from Laurent Joncheray and Elise Guerich (Merit). Both proposals were presented first (see below), and then a general discussion took place. 2. Ripe-81 ++ and related documents Marten Terpstra presented a proposal for representing classless addresses in the database. For more details, please read the draft document 'ripe-clarep' available from ftp.ripe.net. Examples: classful address: 193.48.80.0 classful range : 193.48.80.0 - 193.48.85.0 prefix/length : 193.48.80.0/24 193.48.80.0/20 classless range : 191.1.1.0 > 192.1.1.255 does not need to be aligned on a bit boundary. Tony Bates then presented the enhanced version of Ripe-81 called Ripe-81++. This proposal introduces new concepts: - the allocation registry and the routing registry are now separate. The current 'inetnum' object is split into two new objects: a new 'route' object and the current inetnum object in which all routing and obsolete information have been removed. - In the route object, the aut-sys tag is replaced by an 'origin' tag which indicates the AS number which injects this route in the Internet. The route is obviously classless, with a prefix/length representation. - There is no major modification on the routing policy description except that AS-MACROS and COMMUNITIES can now be used, and an 'as-reject' tag has been added. Transition issues: - The database software should be modified (classless indexing), and the various tools should understand both the old and the new structure. - The new objects should be supported by the end of the summer, and all the routing information moved to the new 'route' object by the end of fall. Open issues: The PRIDE tools have to be modified, and the exchange of routing information with other routing databases should be possible. For more information, please read ripe-81++, available from ftp.ripe.net. 3. Extensions proposed by Merit. Laurent Joncheray presented the work currently being done at Merit. The RIPE database software was used and modified to support classless addresses, but: - It should be possible to distribute the database (by design) - New extensions are needed to implement all the policies. ALC is a new routing server developed by Merit. It makes the tools database syntax independant (ASCII protocol between client and server, the server computes the answers), and allows several ALC servers to exchange information. An ALC server is already running at Merit, and gets information from three databases (Ripe, Prdb and NSFnet db). It is proposed to run such a server at the Ripe NCC and connect the two servers; a natural extension would then be to add more ALC servers to the system. The current Ripe-81 syntax has been extended: - keyworks have been added (from, accept, ...) - list of networks are allowed - proposes a solution to represent serveral connections between two ASes (using router addresses) - possibility to use a database selector - optional metric in as-out - static routing support - as-default extension (default route generation) - new 'as-exclude' tag - new 'as-transit' tag Some questions were raised concerning the distribution of the database and how some sort of security can be implemented. This point is for further study. 4. Discussions, conclusions A long discussion took place to compare the two proposals, and try to merge them. These minutes won't reflect each and every point discussed, but will just report on the conclusions reached. The Reader is asked to consult Ripe-81++ and Merit's proposal for details. Ripe-81++ will integrate the following extensions: A. Network lists are accepted wherever a community can be used with the following syntax: { 36.0.0.0/8, 191.1.0.0/16 } B. The 'default' tag will now allow an optional field explaining how the default route is generated. The Merit 'as-default' tag extension is accepted, but will be called 'default'. C. The need for a way to express 'local' policies when two ASes are connected thru several links is agreed. There's still no agreement on the final syntax, except that this information should not be in the 'as-in', 'as-out' tags, but in two new tags named 'interas-in' and 'interas-out', which are optional. If the 'interas-in' or 'interas-out' tags are present, then there should be a mechanism to generate the corresponding 'as-in' and 'as-out' tags (which only contain a subset of the information) to guarantee the integrity of the 'route' object. This should be done (on request, using a special keyword) by the software when registering the object. D. The Merit syntax introduces keywords like accept, from, ... It is agreed that this should be accepted when registering the objects, and that these keyworks should be present when a query is performed "in verbose mode". Queries in "non verbose mode" is still possible. All keywords are in lowercase and a list of allowed keyworks will be provided (action on Elise Gerich). E. The Merit syntax also proposes a way to "compress" the information like: as-in: from AS690:1, AS701:2 accept AS237 This new syntax is not accepted. F. Network numbers representation: It is agreed that the prefix/length syntax is the only representation accepted. Network numbers should contain 3 dots: 35.0.0.0/8 G. The classless range notation for the 'inetnum' object is not to be discussed in this group but in the database group. The 'route' object only accepts what is agreed on point F. H. Optional as-out metric: this information has to be evaluated in the same way by the various neighbors, and is the only information of the 'route' object the owner of the object cannot really control. The proposal is rejected. I. Static route support: Everybody agreed on the principle: static routing should be represented in the database. A metric should be associated with a static route, and this metric should be relative to the 'as-in' metric. J. Ripe-81++ component tag in the route object: This tag is optional, and a better definition of the 'componenet' tag is needed, as well as a review of the definition of a 'HOLE'. In case of proxy-aggregate, Ripe-81++ should indicate that the listing of the components is mandatory. In case an aggregate is performed with as-set, and that all the networks aggegated are announced by the same AS, then this AS should appear as origin in the 'route' object. There's still a pending issue concerning the community list usage in the component tag: this needs to be better defined and how will this be guarded ? K. The key in the Ripe database used to be the network number. It will become 'route/origin'. Several route objects with the same 'route' fields but different 'origin' fields are accepted. L. Eventhough host routes could perfectly be represented in the new database, it is strongly discouraged (ripe-81++ page 56). M. Line splitting: the notation is accepted as-in: AS1234 100 ( AS-EBONE as-in: AS1234 100 AS1234 ) AND NOT AS2345 N. as-reject and as-exclude: It is decided to rename as-reject in ripe-81++ into as-exclude (proposed from Merit). The keyword 'exclude' will be a reserved keyword. O. 'as-transit' is included in Ripe-81++, but for experimental purposes. P. The database selector (Merit's proposal) needs to be better specified. CONCLUSION: There is a general consensus on most of the extensions, and it is proposed to include all of these in the new version of the Ripe-81++ draft. This draft will be sent to the Ripe list for comments within two weeks, a final version being released in six weeks (June 28th). 3. Closing, AOB The action on Jean-Michel Jouanigot to coordinate the migration from ripe-60 to ripe-81 is almost complete. Only three 'bdry-gw' are still present in the Ripe database: DESY, ACONET and INFN. The action is to be changed into 3 separate actions on these sites: Action on Cristina Vistoli \ to convert from Action on Ewald Jenisch | ripe-60 to ripe-81 Action on Michael Ernst (or Hans Frese) / before July 1st. [ At the time of writing, ACONET bdry-gw seems to have been removed ] [end]