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
