Friends, I have the distinct impression that we are lagging in our efforts to make effective use of the RIPE database for EBONE routing. The current state of affairs is - The framework is described in: ripe-60, "Policy based routing within RIPE", May 1992 - The database software has been extended to handle the objects described in ripe-60 - CERN and some others have started to use them internally makeing use of the CERN developed "nlc" tool - A draft paper on how to apply ripe-60 to EBONE routing has been circulated lately: "Use of the "RIPE policy based Routing within EBONE" by Jean-Michel Jouanigot, September 1992 What needs to be done is to agree on how the route filtering functions necessary for EBONE operations are going to be done. At the NCC we have wondered a little why there seems to be little progress if any. It seems to be that everyone is waiting until someone else reports first experiences how to use the new database objects and tells the others how to use this. Also there seems to be widespread fear about unnecessary complexity. As a consequence little progress is made. In the light of this we have decided to propose a simple first step to get two things going: - ability to filter outgoing announcements RBS->EBS with the goal of keeping EBONE routes unpolluted - update procedures for routing attributes in RIPE database The proposal below deals with those two things. Additional functionality can be added later once these two basic things work. In order to move this forward the EOT should talk about this and make constructive comments where necessary. If there is rough consensus to proceed in this way, then the NCC and the EBONE operations people can work together to get this operational within a few weeks. Please excuse the late date of sending this over. We are currently very pressed for time at the NCC and the real extent of the problem became apparent only recently. We are also unfortunately unable to attend the Montpellier meetings. E{A,O}T can be assured that we will make all reasonable efforts to make the RIPE database useful for EBONE routing purposes. Daniel First Steps to Use the RIPE Database for Policy Based Routing within EBONE -------------------------------------------------------------------------- By far the easiest way to start implementing route filtering as specified in the RIPE document ripe-60 is by using the routing privilege tag. In order to achieve this each of the connected regions of EBONE has to define routing privileges, one routing privilege for each of the different policies inside the region. Of course ideally there would be only one such policy but the world is seldom ideal. Once the routing privileges have been defined they need to be registered in the RIPE database using the routing privilege object. Having defined and registered the necessary routing privileges, the region must then make sure that all the network numbers that need to be announced to EBONE get the appropriate routing privilege tag added to the routpr-list attribute in the database. With the Network List Compiler (nlc) filter lists containing all the networks that have a certain set of routing privileges are then created. These can then be applied on the EBS side, to filter incoming routing updates from the RBS, or on the RBS side to filter outgoing updates to the EBS. The NCC offers to produce such list for any RBS operator requesting it. Of course nlc can also be run locally using local copies of the RIPE database. This model however does not specify backup policies, it just specifies primary routing. If a certain region provides a backup connection to EBONE for another region, this first region must tell the EBONE operators to accept both the list of networks with his own routing privileges, and the list of the backed-up region. AS path lengths or weights should be used to ensure that the best routes are chosen first. A method of storing this information in the RIPE database will be introduced at a later stage. Using the routing privilege in this fashion is similar to using for instance the autonomous system tag in the database for the same purpose. However, the routing privilege allows more detail inside an autonomous system. One should expect that every policy inside a region should have its own AS number, but unfortunately this is not the case in many places. Therefore, the use of the routing privilege gives the needed granularity in defining policies. This model also can easily be extended to the Global Internet Exchange by creating a filter list for the superset of all routing privileges that are announced to EBONE. Database Update Procedures for the Routing Tags ----------------------------------------------- Note These preocedures have been presented to the RIPE database working group a few weeks ago and all comments received have been incorporated. Introduction This describes a procedure for updating the routing attributes to the RIPE database as defined in ripe-60. These routing tags are essential for routing of networks that are known in the RIPE database. Therefore updates of these attributes must be: - properly authorized - guarded against typing errors - efficient for both maintainers of the attributes and the maintainers of the whole database The Principle The principle of the procedure is that the information concerning the routing related attributes is maintained separately from the database proper. Update procedures for the database itself do not change the routing related information. The routing information can only be changed by the "guardians" of specific routing privilegesd and boundary gateways. When information is retrieved from the database however the routing related information presented together with the other information. The Procedure For each of the routing privileges and boundary gateways tags, a list of all networks having this attribute is kept seperately from the database proper. These lists will be the *only* source of routing information used in the database. Normal database updates do *never* change the routing related attributes. If an update include such an attribute it causes a consistency check with the stored information but no update occurs. If a discrepancy between the values in the update request and those in the database is found, a diagnostic will be send to the originator of the request. The routing related attributes as defined in the lists are merged into the database at each normal update run. To ensure authorisation, we propose to maintain the lists on a the central NCC database server, where each of the guardians of a tag keeps track of his or her own list. The lists are maintained through individual logins for each of the guardians. The guardians can themselves decide in what manner they want to update their list. The NCC will offer interactive logins, ftp logins or any other means that might be found useful. File Format We propose to keep the file format as simple as possible. The name of the file should indicate the name of the attributes. This means that there cannot be two attributes with the same name. The format within the file we propose as the "inetnum:" entry for each of the networks, seperated by an empty line. If a guardian feels that he would want more attributes to identify a network for reasons of consistency checking, he is free to do so. A routing related attribute will only be added to a network if all attributes defined in the list match a network in the database. Advantages The update procedure as proposed above has the following advantages: - Authorisation of adding/deleting is guarenteed - No need for mailing back and forth of authorisation messages - Simple procedure for both database maintainers and guardians - Guardian keeps full control of his attribute - Could be implemented at the NCC without too much delay