You're viewing an archived page. It is no longer being updated.
RIPE Meeting: |
29 |
Working Group: |
Routing |
Status: |
Final |
Revision Number: |
2 |
Chair: |
Joachim Schmitz (JS395-RIPE) |
Scribe: |
Joao Luis Silva Damas (JLSD1-RIPE) |
Attenders: |
46 |
The working group agreed upon the minutes of the previous meeting, and accepted the draft agenda earlier circulated on the mailing list.
Review of actions RIPE 28
Input has been gathered from the community, and a report on bugs in the Cisco IOS has been added (regarding improper counting of flaps and early onset of damping). The final draft of the paper was circulated on the mailing list shortly before this RIPE meeting, with a last call for comments. If there are no further additions from the community this final draft will be published as a RIPE document after the meeting (now available as RIPE-178 from the RIPE ftp/web servers).
Most of RIPE considerations on route flap damping have been taken into account and put in the internet draft currently being written by Curtis Villamizar, Ravi Chandra, and Ramesh Govindan. However, the scope of their draft goes beyond the RIPE document. Their paper is available from http://engr.ans.net/route-damp/
RPSL Update and Report from IETF 40 (Carol Orange)
Unfortunately, there is a delay in implementation of RPSL due to unforeseable circumstances. Nonetheless, implementation will continue, just as other work around RPSL does:
The main issues seem to be data integrity, prevention of accidental or malicious misconfiguration and prevention of improper use of adress space. In order to base the BGP filtering scheme on the data in the routing registry, the data must be properly tied to the IP assignment data maintained by the IP registries. In the RPS WG of the IETF where this was discussed, it was noted that this will be more diffucult in the ARIN and APNIC regions where the routing and IP registries are separate.
With these requirementes the need arises for communication between IP registries and routing registries. The European internet community has an advantage here.
This calls for a definition of the IRR: A proposal is: "The IRR is a place that reflects what is announced in the Internet and what is permitted to be announced."
With AS numbers the path of authority is clear.
IANA -> Regional registries -> ISPs
This works in Europe but not elsewhere. Actually, it is possible to look for free AS numbers, just use them and register them in the IRR. The authority of AS numbers is not checked by the other routing registries. There have been several occasions when this lead to routing problems.
The distribution of IP numbers works similarly. There seems to be agreement in that nonallocated IP numbers should not be routed. However, there is not yet an accpeted mechanism for providing this.
One solution could be to delegate authority for a block of IP numbers in the routing registry at the time of IP allocation by creating an object for the full block that can then be subdivided by the ISP. However, this would tie IP allocation to routing entries.
Joachim Schmitz noted that people should be aware that this imposes restrictions on what can be registered and is a big change from current practice. Comments on this paradigm shift are welcome.
One goal is to compare policies stored on IRRs versus real BGP information in real time. Several tools have been developed for looking at announcements
The next question arises as to how easy it would be to do this clean up. First it must be known which information should be stored on the IRR. However, this depends on the definition of the IRR. Several have been proposed:
The question is: What to do with these objects?
As a first step a definition for the IRR is required. Any further action can then be based upon this definition. However, to come to this definition consensus must be found that cleaning is needed, and we must define what can be done. The IRR will probably need some power over object removal to clean up data. Yet, the IRR can not decide on its own - community approval is needed.
The presentation triggered some discussion. Miguel Angel Sanz asked whether any coordination or contact exists between the different Routing Registries regarding this topic. Gerald Winters replied that RIPE, RADB, and ANS are coordinating, but MCI and CANET are not. Carol Orange added that closer coordination has started recently and is being promoted. There have been discussiones about the authorization scheme. However, we need to take into account that different registries serve different purposes: RIPE and RADB are publicly available but MCI runs a RR for their own purposes.
There were remarks regarding the fact that the importance of the correctness of data in IRRs depends on them being used for router configuration and for that to happen better tools are needed. Joachim Schmitz replied that large ISPs currently tend do so and request their peers to do so as well.
There were questions regarding the licensing of RADB code and Gated code. Gerald Winters and Jake Kuhon from Merit replied that the funding scheme for Merit is changing right now. Work on Gated has been resumed at Merit. The details on licensing will depend on the final scheme for Merit. Information will be available from Merit soon.
Richard Almeida made remarks on the differences in registering procedures between Europe and the US and a general comment on the situation being better in Europe.
Questions about followup on aggregation work from previous meeting met the reply there has been no progress recently.
- Routing Working Group Meeting -
Agenda for RIPE-29, January 1998, Amsterdam
Joao Luis Silva Damas, Joachim Schmitz
7-May-1998