You're viewing an archived page. It is no longer being updated.
RIPE Meeting: |
30 |
Working Group: |
Routing |
Status: |
FINAL |
Revision Number: |
1 |
Please mail comments/suggestions on:
Chair: |
Joachim Schmitz (JS395-RIPE) |
Scribe: |
Ambrose Maggee (AMRM1-RIPE) |
Attenders: |
96 |
The working group agreed upon the minutes of the previous meeting, and accepted the draft agenda earlier circulated on the mailing list.
Joachim Schmitz then told that Carol Orange has left the RIPE NCC and has returned to the US. She has been closely working together with the Routing WG. He thanked her for her continuous support, her valuable ideas, and her numerous contributions. Part of her work has been taken over by Joao Luis Silva Damas of the RIPE NCC who has already proven his interest in our work.
Review of actions RIPE 29
RPSL is the Routing Policy Structured Language developed by the IETF RPS WG. The definition of RPSL is Proposed Internet Standard now (RFC2280). It allows detailed description of routing policies.
It is on the way of being implemented at the routing registries. Some of it was presented in the Database WG session. According to a recent announcement by JLS Damas, an implementation has also been installed at RIPE. David Kessens later on gave a presentation about progress on the transition to RPSL.
Approximately one year ago, the issue of database security led to the RIPE Database Security Task Force being founded. In the IETF RPS WG this topic has been taken up for the IRR. A draft is already available from them. David Kessens summarized the most important items later in this session.
There is not only the IETF with the focus on "E"ngineering but also the IRTF focusing on "R"esearch. A routing research group has recently been founded. They are just in the beginning and welcome input. Those who are interested may want to look at their web resources.
A presentation was given later on during the session by Randy Bush, one of the authors of the corresponding draft.
The server software development is finished. The RIPE database software based on RPSL is ready for phase 2.
Phase 2:
RADB and RIPE have moved to phase 2. The RPSL database can be tested at
RIPE |
queries: |
whois -h rpslii.ripe.net (usual port) |
|
submissions: |
mailto:[email protected] |
ISI/RADB |
queries: |
whois -h whois1.avalon.rs.net |
|
submissions: |
mailto:[email protected] |
The RAToolSet is developed to be compliant with RPSL needs. There are already some service providers who make use of RPSL (Telstra and Connect in Australia, several major ISPs in the US are also eager to start with RPSL).
Due to questions from the audience the current state of phase 2 was then described in more detail: Phase 2 is experimental. Two sets of the database coexist now, one in the old RIPE-181 style, the other in RPSL style. Currently, only autnum objects are different.
Queries to the standard whois host display the RIPE-181 style; queries to the RPSL host display RPSL style. If only RIPE-181 objects are present, queries to the RPSL host will result in display of the RIPE-181 object tranformed to RPSL style.
Similarly, updates to the corresponding hosts only affect the related style. An RPSL update will not affect the RIPE-181 object and vice versa.
In phase 3 all RIPE-181 objects will be transformed to RPSL objects. A meeting was held where all registries participated to coordinate the transition to phase 3. There is no schedule yet for several reasons:
Originally, the focus was on routing stability. Lately, more attention was on latency and losses. Most recently, issues related to visualization of the measured data are worked on.
Then, Craig showed several graphs and results from earlier routing stability investigations. The most prominent ones were related to BGP updates (up to 60 million per day). The vast majority of the updates consisted of withdrawals, most of them being repeated and obsolete. It turned out that they resulted from implementation decisions of BGP by the vendors which had to be considered bugs.
Besides these reasons problems in BGP result from
- BGP/IGB misconfiguration - CSU/DSU oscillation (interaction of CSU/DSU with router interface which is not configured down) - SEP ("someone elses problem" i.e. blaming others) - self-synchronisation Due to corrected software the number of BGP updates has dropped by one order of magnitude. In addition, announcements and withdrawals are now approximately the same. Most announcements today result from oscillations in attributes. In addition there are still duplicates. It turns out that most of them are related related to MED and AS-path changes.
These were investigated more closely for MICHnet which is a small network which is considered stable. It propagates only approximately 100 routes to the outside Internet. Surprisingly, there were still roughly 1000 BGP updates per day to the outside world. Looking for the reasons they did not only find those mentioned in the list above but were also able to identify a pattern related to certain periodic OSPF updates inside the network. Having those explained they are now investigating for causes of the remaining "noise"
The IPMA tools used for the investigations described above are now leaving the alpha phase. They are now starting to work together with other ISPs. For further investigations and tests they need help from other ISPs, and kindly ask for support. References are
information: http://www.merit.edu/ipma
mailto: [email protected]
The presentation was very interesting and Joachim Schmitz strongly recommended that the IPMA tools and analysis should be used to improve overall network stability. Several questions were triggered by the presentation.
Randy Bush wanted to know whether it was common for ISPs to redistribute IGP to BGP. Craig replied that he is unaware of how common this is on the Internet. However, they found it with one of the small ISPs which is connected to their backbone. Actually, the more recent versions of the Cisco manuals contain a warning about it.
Yakov Rekhter asked on the impact of different internal routing protocols. However, only OSPF was analyzed in detail.
With most of the BGP instabilities resolved it makes now sense to also look at IGP instabilities.
The BGP updates were measured at route servers. Probably not all updates are propagated beyond one peering AS because they are only important for the direct peering. Some could be captured by multihop sessions. It seems that most updates really result from pure usage and load. Nonetheless, maintenance windows with operator interference are visible.
The draft is subject to additional reviews. Nonetheless, deployment of the model is under consideration. The authors claim that changes to the database and operational procedures are simple. They also estimate that their proposal is sufficient to provide authorisation and authentication to secure the IRR.
David Kessens urged the WG to supply comments on this document because implementation is planned soon.
The most important question was related to PGP as secure mechanism. To use it for RPS Security commercial copies are needed, leading to the question of license costs. Actually, this is not a problem in the RIPE community due to the distribution license acquired by the RIPE NCC. Moreover, licences would only be needed for updates; read access to registry data does not require a PGP license. In addition, Open PGP is currently under development at IETF. It must also be noted that the proposal is not limited to PGP and does not exclude other means of authorization/authentication. PGP is just the method which currently is readily available.
While the IRR is an "ideal" solution, the authors see several drawbacks which they propose to solve by a pragmatic solution. The approach is based upon encoding address space allocation in DNS by expanding the RR definition accordingly. The data included is prefix/length and AS for each route. BGP speakers could then look up received prefixes on nameservers. The possible results are
An issue was the amount of DNS queries. It turns out that these can easily be several millions. Depending on the load on a nameserver reading this information may take in the order of magnitude of an hour. During this time most routes are still unauthenticated which is also the case if DNS was down. However, this is the situation today. Additional authentication improves the overall situation.
Concerns regarding router performance are considered to be unimportant because the CPU power needed is negligible. Estimates also do not see a problem if a "routing bomb" with e.g. 200,000 routes is sent to the router. It just eats through the entries in its idle time.
For presentation of classless IP routes the Jan de Groot / Eidnes DNS hack can be used.
As Randy Bush pointed out there are still some open issues, e.g. usage of DNSSEC, or which namespace to use. Therefore, input to the proposal is welcome. The proposal is available at PSG and as Internet draft.
- Routing Working Group Meeting -
Agenda for RIPE-30, May 1998, Stockholm
Ambrose Magee, Joachim Schmitz
8 September 1998