January 1999 - routing-wg - mailman.ripe.net

The Cidr Report
by Tony Bates 29 Jan '99

29 Jan '99

This is an auto-generated mail on Fri Jan 29 12:00:00 PST 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 29Jan99 0) General Status Table History ------------- Date Prefixes 220199 55393 230199 55423 240199 55417 250199 55453 260199 55539 270199 55623 280199 55634 290199 55694 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4470 Number of ASes announcing only one prefix: 2208 (1180 cidr, 1028 classful) Largest number of cidr routes: 350 announced by AS3561 Largest number of classful routes: 1028 announced by AS701 1) Gains by aggregating at the origin AS level --- 29Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 387 140 247 63.8% BCnet Backbone AS701 1028 870 158 15.4% Alternet AS2493 323 174 149 46.1% iSTAR Internet, Inc. AS174 645 533 112 17.4% Performance Systems International AS11305 116 8 108 93.1% UNKNOWN AS3749 149 67 82 55.0% TECNET AS4755 156 75 81 51.9% Videsh Sanchar Nigam Ltd. India AS1267 111 30 81 73.0% IUNET-AS AS4293 211 140 71 33.6% IMCI AS549 218 152 66 30.3% ONet Backbone AS4200 160 98 62 38.8% AGIS (Apex Global Information Ser AS7046 269 208 61 22.7% UUNET-CUSTOMER AS1221 396 336 60 15.2% AARNET-AS AS4740 378 320 58 15.3% Ozemail Pty Ltd (ASN-OZEMAIL) AS1239 527 473 54 10.2% SprintLink Backbone AS72 89 37 52 58.4% Schlumberger Information Network AS7657 141 90 51 36.2% The Internet Group Limited AS7545 109 58 51 46.8% TPG Internet Pty Ltd AS7496 77 28 49 63.6% Power Up AS577 221 172 49 22.2% Bell Canada Backbone AS10928 99 50 49 49.5% UNKNOWN AS719 452 408 44 9.7% LANLINK autonomous system AS3221 84 42 42 50.0% EENet Autonomous System AS852 173 135 38 22.0% AGT Advance Communication AS3561 723 685 38 5.3% MCI AS803 72 36 36 50.0% SaskNet Backbone AS6897 64 28 36 56.2% Global-One Spain AS7122 110 76 34 30.9% MTS ADVANCED Network Policy AS2764 330 297 33 10.0% connect.com.au pty ltd AS6332 101 70 31 30.7% TELNOR For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

The Cidr Report
by Tony Bates 22 Jan '99

22 Jan '99

This is an auto-generated mail on Fri Jan 22 12:00:00 PST 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 22Jan99 0) General Status Table History ------------- Date Prefixes 150199 55155 160199 55240 170199 55247 180199 55241 190199 55868 200199 55938 210199 55534 220199 55393 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4442 Number of ASes announcing only one prefix: 2186 (1168 cidr, 1018 classful) Largest number of cidr routes: 355 announced by AS3561 Largest number of classful routes: 1012 announced by AS701 1) Gains by aggregating at the origin AS level --- 22Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 387 143 244 63.0% UNKNOWN AS701 1012 859 153 15.1% UNKNOWN AS2493 319 173 146 45.8% UNKNOWN AS174 655 541 114 17.4% UNKNOWN AS11305 115 7 108 93.9% UNKNOWN AS4200 189 97 92 48.7% UNKNOWN AS3749 158 66 92 58.2% UNKNOWN AS1267 111 30 81 73.0% UNKNOWN AS4755 147 72 75 51.0% UNKNOWN AS4293 208 137 71 34.1% UNKNOWN AS549 218 152 66 30.3% UNKNOWN AS4740 387 325 62 16.0% UNKNOWN AS1221 399 339 60 15.0% UNKNOWN AS7046 253 196 57 22.5% UNKNOWN AS1239 540 486 54 10.0% UNKNOWN AS72 89 37 52 58.4% UNKNOWN AS7657 140 89 51 36.4% UNKNOWN AS7545 110 59 51 46.4% UNKNOWN AS577 221 172 49 22.2% UNKNOWN AS10928 98 49 49 50.0% UNKNOWN AS7496 76 28 48 63.2% UNKNOWN AS852 177 134 43 24.3% UNKNOWN AS719 452 409 43 9.5% UNKNOWN AS3221 84 42 42 50.0% UNKNOWN AS803 72 36 36 50.0% UNKNOWN AS6897 64 28 36 56.2% UNKNOWN AS3561 723 687 36 5.0% UNKNOWN AS7122 110 76 34 30.9% UNKNOWN AS2764 324 291 33 10.2% UNKNOWN AS6332 101 70 31 30.7% UNKNOWN For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

draft agenda RIPE 32 routing wg session
by SchmitzJo＠aol.com 22 Jan '99

22 Jan '99

Dear colleagues, please find enclosed the draft agenda for the session of the routing working group at RIPE 32, Amsterdam. The session will be held Wednesday, 27-January, 9:00am As usual comments, additions, welcome! --- R I P E 3 2 A M S T E R D A M Routing Working Group Session 27-January-1999 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 31 minutes - actions from earlier meetings B. Recent Developments (Joachim Schmitz) - RPSL tutorial - IETF C. Report on RPSL Deployment at the Registries - General Overview (David Kessens) - RIPE NCC (Joao Luis Silva Damas) D. Report from the RIPE NCC (Joao Luis Silva Damas) E. Internet Performance and Fault Tolerance (Abha Ahuja, Craig Labovitz) F. Reality Checking of the RIPE Routing Registry (Joachim Schmitz) Y. General I/O with Other WGs - Cooperation between Routing WG and MBone WG (Kurt Kayser) Z. AOB --- Regards Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

draft minutes of RIPE 31 routing wg session
by SchmitzJo＠aol.com 21 Jan '99

21 Jan '99

Draft Minutes: Routing Working Group. RIPE 31 --------------------------------------------- Chair: Joachim Schmitz (JS395-RIPE) Minutes: Miriam Kuehne (MK16-RIPE), Julia Edwards (JE316-RIPE) Attenders: 99 A. Preliminaries (Joachim Schmitz) Joachim Schmitz opened the working group session, passed the attenders' list around, and asked for a volunteer scribe. Miriam Kuehne volunteered as scribe. During the session Julia Edwards took over. 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 30 o 29.R1 G.Winters, J.Schmitz, RIPE NCC Definition of the IRR and an AUP -in progress- Gerald Winters is giving a presentation in this session on work done so far on this topic o 29.R3: RIPE NCC, JLS Damas Implementation of PGP -to be closed- The action may be considered closed because it will be moved to beta in the next two weeks o 30.R1: RIPE NCC, JLS Damas Implementation of autnum authorization -postponed- Implementation has been postponed because this is one special feature within the more general scope of the RPS Authorization draft o 30.R2: RIPE NCC, J. Schmitz, W. Woeber Organize RPSL tutorials for RIPE 31 -done- The RPSL tutorial has been held. B. Report from the RPSL Tutorial - (Joachim Schmitz) RPSL is the "Routing Policy Specification Language" developed by the IETF RPS Working Group. For those who are not familiar with this topic the following pointers may be of interest: http://www.ietf.org/html.charters/rps-charter.html http://www.isi.edu/ra RPSL is in the stage of deployment phase 2 with the final transition phase from RIPE-181 in sight. Part of the transition is education to make it easier for users to apply RPSL. After some tutorials in the US we had the first RPSL tutorial in Europe just prior to this RIPE meeting. There were approximately 90 participants. The training materials are available electronically at http://www.isi.edu/ra/rps/training Future tutorials will be held at the next RIPE meeting, and plans to offer them as part of the LIR tutorials are currently considered. Joachim Schmitz then thanked the trainers Cengiz Allaetinoglu, David Kessens, and the RIPE NCC, for preparing and performing this tutorial. C. Report from the RIPE NCC (Joao Luis Silva Damas) (http://www.ripe.net/meetings/ripe/ripe-31/pres/ncc-upd/index.html) The report included a general update on NCC activities. In the database software, cross notification was added, making use of the two tags "cross-nfy" and "cross-mnt". The functionality follows the specifications developed by the Routing WG in earlier sessions, both regarding the notification in relation to "autnum" and "route" objects. In addition, PGP authentication will also become available in approximately two weeks for production after this RIPE meeting. This method is supplied in parallel to "none", "e-mail address", "UNIX style password", but offers significantly better security. This method may currently be tested at queries: beta-whois.ripe.net submissions: auto-beta(a)ripe.net in beta status. The implementation follows the Internet draft http://www.ietf.org/internet-drafts/draft-ietf-rps-dbsec-pgp-authent-00.txt developed in the RIPE Database Security Taskforce, and written up by its members Janos Zsako. D. Reports on RPSL Deployment at Registries o RIPE NCC (Joao Luis Silva Damas) (http://www.ripe.net/meetings/ripe/ripe-31/pres/routing-wg- rpsl/index.html) Phase II of the transition has been completed, meaning that a mirror of the production database is installed and running. The mirror according to definition of transition phases is one-way only (RIPE-181 -> RPSL). The phase II database is accessible at - rpslII.ripe.net - auto-rpsl(a)ripe.net Submissions in RIPE 181 format are still possible and will be translated into RPSL. At the same time straight RPSL submissions are possible. Only autnum objects are currently handled in RPSL format. The database is running using ISI's code written by David Kessens. The usage is still low (which is no wonder because the server just became available). In the future, as part of the database reimplementation, the RPSL capable database will support the full set of RPSL features, and also support the RAToolSet. o ISI (David Kessens) There are three phases proposed in the transition from RIPE-181 to RPSL: phase 1: software development done phase 2: tool development, testing, training real time mirror of IRR in RPSL format special RPSL update path for "autnum" objects *status of today* phase 3: switch over incoming RIPE-181 objects are automatically converted to RPSL during 1999 RIPE, ANS, and Merit are currently in phase 2. MCI and CANET are testing RPSL software. Telstra moved to RPSL, and Connect (AU) is already configuring their routers using the alpha RAToolSet for RPSL. A set of others is know to evaluate. Regarding training and education the following tutorials were held so far - Jun 1998, NANOG in Detroit - Sep 1998, Ripe-31 Edinburgh - Mar 1999, APNIC, Apricot (planned) To make use of RPSL, the following software is available: - RAToolSet - RIPE database with RPSL extensions which is compatible to RIPE db 2.1.3. The full RPSL support will move to beta soon. - R181 to RPSL database objects converter The software is available at http://www.isi.edu/ra/rps/transition o RADB (Gerald Winters) Merit offers a public RPSL server rpsl.merit.edu 43 since spring/summer 1998. Usage is on the rise, and comments from users are focusing on two items - why is the system rejecting my AS object - here is a bug I see In Gerald's personal opinion, a large number of RADB users has not yet logged on to the RPSL server because - the old software works and still seems to satisfy their needs - a steady influx of users exist who do not know RPSL - there is a group of "regular" registry users who think the ISP will do it all Therefore, Gerald lists the following suggestions: - continue the current education strategy - include informative footer messages in email transaction responses - I do not see things as bleak - registry admin's will certainly be putting in extra email consulting hours. Usage and involvement by ISPs at this time is not much. Most of it comes from specialists, or users already interested having discovered the potential in RPSL. Usage outside the US, especially in Europe is still low. It is obvious that more training is needed, and work to make it more useful. Users will definitely change their attitude if usability is better. E. Do we need a Routing Registry for IPV6? (Joachim Schmitz) (http://www.ripe.net/meetings/ripe/ripe-31/pres/ to come soon) In the introduction, a short review was given of what currently is part of the IPv4(!) routing registries, and what benefits its users have from it. It is obvious that today no IPv6 registry exists, and the question was raised whether on is needed. Then the current situation regarding IPv6 was described, and the expected development of IPv6 "Inter6net" with its interaction towards IPv4 listed. Looking at the benefits the IPv4(!) IRR offers, it seemed obvious that they are also applicable to an IPv6 routing registry. Consequently, the conclusion was drawn that a need for an IPv6 routing registry exists, which may even add more value by easing the coexistence of IPv4 and IPv6, and may help in transition to IPv6. The time to raise the topic is not too early because during the 1st quarter of 1999 the IPv6 address allocation is likely to begin. The presentation was finished with a call for participation to explore the idea and to define the requirements. F. An AUP for the IRR (Gerald Winters, Pierre Thibaudeau, Joachim Schmitz) The authors feel that a need exists to build an acceptable use policy for the IRR. To start with the question was discussed what an AUP is. It may simply be defined as a document which lists acceptable IRR practices and data, covering topics for the users like - what purposes should the IRR be used for? - what types of data would I register? - Are there important relationships between objects I should be aware of? - Can I find suggestions for maint. my data? The goals of the AUP may be summarized as - add value to the IRR - address the concerns of (the user and db admin) - provide an easy to understand single point of reference - prevent abuse The AUP may then be used - as reference point, especially for new users - by registry admins signing the AUP to declare the data as conformant with it - by users (eg, comparable to the implied consent from the RIPE copyright in the RIPE.db) The AUP is still under development. The work on it is not yet complete, and some of the suggestions require further detailed discussion. The talk was given to make the community aware of the AUP, to solicit feedback, and to ask for support. The IRR AUP will definitely acknowledge other efforts. Others are currently defining relevant policy rules or have already done so - RPS (rps-auth) - RIPE NCC - Merit Some of the ideas to follow overlap or duplicate existing policies. This is not a bad thing, and it shows consistency with out goal to provide a single point of reference. In the following part of the presentation, a starting framework for an AUP was shown: - Contact information should be kept up to date "Contact information is important data which facilitates communication between network parties. Therefore it is encouraged to keep role and person object data up to date as well as all tech-c and admin-c references." - Commercial uses of the IRR "All commercial uses are stricly forbidden. Contact information must not be used for commercial purposes, advertising purposes, or any other purpose beyond the scope of activities relating to the successful operation of the Internet." - Old objects Old objects are a matter of concern. They are not necessarily invalid. However, current does not imply up to date. So aging out objects based on a "changed:" time stamp (even machine generated) is a probably a bad idea. Using global routing data with IRR information is a better solution. A suggestion may build on read time stamps, because it shows that even old data is still accessed, and therefore most likely still valid. Yet, it must be explored whether this approach is practical. Obviously, there is a series of items which needs further discussion. This includes the concept of cross notification and whether it is recommendable or not. The following discussion did not very much enter this area but focused on the abuse of data in the registry, including contact information by spammers, reluctance of service providers to disclose their policies (company policy and possible business impact), and security of data in the database. G. Routing Policy System Security (Cengiz Allaettinoglu) Due to time constraints the presentation on this topic was moved to the Database Working Group session. Joachim Schmitz apologized to the Cengiz, and thanked Wilfried Woeber for accepting the transfer. Y. I/O with other WGs The presentation on whether a Routing Registry for IPv6 is needed was also given as input at the IPv6 Working Group. Z. AOB There were no additional comments or issues. Agenda ------ R I P E 3 1 E D I N B U R G H Routing Working Group Session 23-September-98 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 30 minutes - actions from earlier meetings B. Recent Developments (Joachim Schmitz) - RPSL tutorial C. Report from the RIPE NCC (Joao Luis Silva Damas) D. Report on RPSL Deployment at the Registries - ISI (David Kessens) - RIPE NCC (Joao Luis Silva Damas) - RADB (Gerald Winters) E. Do we need a Routing Registry for IPv6? (Joachim Schmitz) F. An AUP for the IRR (Gerald Winters) G. Routing Policy System Security (David Kessens, Cengiz Allaettinoglu) Y. General Input from Other WGs Z. AOB Summary of Actions ------------------ Action 29.R1: G. Winters, J. Schmitz Definition of the IRR and an AUP Action 31.R1: RIPE NCC, J. Schmitz, D. Kessens Basic Design for an IPv6 IRR Miriam Kuehne, Julia Edwards, Joachim Schmitz, 21 January 1999

1 0

RIPE NCC PGP license distribution
by Joao Luis Silva Damas 20 Jan '99

20 Jan '99

Dear all, as you may be aware from past presentations at RIPE meetings and discussions in the lists, the RIPE Database now supports PGP authentication as a stronger way of protecting your database objects. This use of PGP with the RIPE Database is seen by PGP Inc as a commercial use of their software that therefore requires a commercial license. To enable users to take advantage of the new feature, the RIPE NCC will distribute PGP licenses to Database users according to the policy and procedures described in a new RIPE Document: RIPE 190, available now at the RIPE NCC's website. http://www.ripe.net/docs/ripe-190.html To obtain more information on how to use PGP with the RIPE Database, please refer to the recently release RIPE 189 document, also available at the RIPE NCC's website. http://www.ripe.net/docs/ripe-189.html Please direct any questions/comments to ripe-dbm(a)ripe.net Best regards, Joao Damas Database Group RIPE NCC

1 0

Re: AW: Agenda item suggestions
by SchmitzJo＠aol.com 18 Jan '99

18 Jan '99

Dear colleagues, there were two proposals to discuss multicast issues in the Routing WG. Christian Panigl wrote: > How about integrating the multicast routing issues into the Routing-WG > agenda ? And still, if there's some specific action item on multicast > routing and/or Mbone coordination we could establish a task-force within > the Routing-WG. And as Tiziana wrote, multicast routing should become a > natural service in the european backbones, at least very soon. and then Thomas Telkamp added: > Integrating these routing issues in the Routing-WG might help to keep > focus. I absolutely think the interest of the community in this is still > there. > > Kurt, at least we have an agenda topic for next meeting ;-) > I do not have any objections to discuss multicast routing in the Routing-WG. As far as I see from current planning (not yet on RIPE web site) the MBone session comes after the Routing WG session. So we will not have a clash if we share the topic. However, I would like to suggest that in order to properly deal with the topic that we take this as input to the Routing WG. I would then require a short presentation from you - if someone is interested to give a sketch of the ideas (no solutions yet; they still need to be developed, obviously ;-) I greatly appreciate it. Please write back to me for proposals. Thanks a lot Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

Re: AW: Agenda item suggestions
by Christian Panigl, ACOnet/UniVie 16 Jan '99

16 Jan '99

>Date: Fri, 15 Jan 1999 13:14:09 +0100 (MET) >From: heiligers(a)noc.dfn.de > >i think there is the need for european multicast coordination. For >example questions regarding pruning or administrativly scoped >boundaries, .... >I would suggest to keep at least the mailing list as a european forum >for discussing problems regarding multicast deployment and operation. How about integrating the multicast routing issues into the Routing-WG agenda ? And still, if there's some specific action item on multicast routing and/or Mbone coordination we could establish a task-force within the Routing-WG. And as Tiziana wrote, multicast routing should become a natural service in the european backbones, at least very soon. See you CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---

2 1

The Cidr Report
by Tony Bates 15 Jan '99

15 Jan '99

This is an auto-generated mail on Fri Jan 15 12:00:00 PST 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 15Jan99 0) General Status Table History ------------- Date Prefixes 080199 54976 090199 54679 100199 54744 110199 54918 120199 54860 130199 54884 140199 55099 150199 55155 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4408 Number of ASes announcing only one prefix: 2168 (1156 cidr, 1012 classful) Largest number of cidr routes: 355 announced by AS3561 Largest number of classful routes: 1013 announced by AS701 1) Gains by aggregating at the origin AS level --- 15Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 389 144 245 63.0% UNKNOWN AS701 1013 860 153 15.1% UNKNOWN AS2493 319 173 146 45.8% UNKNOWN AS174 650 536 114 17.5% UNKNOWN AS5668 129 35 94 72.9% UNKNOWN AS3749 157 65 92 58.6% UNKNOWN AS4200 178 91 87 48.9% UNKNOWN AS1267 111 30 81 73.0% UNKNOWN AS4755 147 74 73 49.7% UNKNOWN AS4293 208 137 71 34.1% UNKNOWN AS549 218 152 66 30.3% UNKNOWN AS4740 388 326 62 16.0% UNKNOWN AS8517 134 75 59 44.0% UNKNOWN AS1221 395 336 59 14.9% UNKNOWN AS7657 142 87 55 38.7% UNKNOWN AS7545 111 58 53 47.7% UNKNOWN AS72 89 37 52 58.4% UNKNOWN AS3493 252 200 52 20.6% UNKNOWN AS7046 238 187 51 21.4% UNKNOWN AS1239 531 484 47 8.9% UNKNOWN AS10928 96 49 47 49.0% UNKNOWN AS7496 74 28 46 62.2% UNKNOWN AS577 210 164 46 21.9% UNKNOWN AS852 175 132 43 24.6% UNKNOWN AS719 452 409 43 9.5% UNKNOWN AS3221 84 42 42 50.0% UNKNOWN AS803 71 35 36 50.7% UNKNOWN AS6897 62 27 35 56.5% UNKNOWN AS7122 109 75 34 31.2% UNKNOWN AS2764 327 294 33 10.1% UNKNOWN For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

RE: EIX WG at RIPE 32
by Christian Panigl, ACOnet/UniVie 14 Jan '99

14 Jan '99

>Date: Thu, 14 Jan 1999 10:14:16 +0000 >From: Fearghas McKay <fm(a)mids.org> >To: <eix-wg(a)ripe.net> > >Request for Presentations at RIPE 32 > >Sorry for the delay in getting this out. > >We have been allocated two slots on the Wednesday morning session at RIPE 32 > >Wednesday 27 > > Room 1 Room 2 Room 3 >9:00 +----------+----------+-----------+ >10:30 | LIR | Routing | EIX | > +----------+----------+-----------+ >11:00 +----------+----------+-----------+ > | LIR | MBone | EIX | >12:30 +----------+----------+-----------+ > >Please can you let me know if you would like to make a presentation, and >provide a short synopsis & equipment requirements. Hi Fearghas, imho it's not a good idea to place Routing/EIX (nor Mbone/EIX) in parallel. Anyway, in principle I'm ready to give a short update for the VIX. Regards CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---

1 0

New RIPE doc + new RIPE Database release
by Joao Luis Silva Damas 14 Jan '99

14 Jan '99

Dear colleagues, we are happy to announce a new RIPE document together with a new maintenance release of the RIPE Database code. New RIPE Document RIPE 189 - RIPE NCC Database documentation update to support RIPE DB ver. 2.2.1 A new RIPE document to supplement RIPE 157 as reference material on the use of the RIPE Database. Describes new or modified functionality since RIPE 157 was issued. Covers DB releases up to the 2.2.1 release (see below). New RIPE Database release Version 2.2.1 is mostly a maintenance release. There are very little user visible changes from version 2.2. For more details please read the release notes available at ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-2.2.1 This version will go into production at whois.ripe.net next Monday. It is available for download now from ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.2.1.tar.gz Best regards, Joao Damas & all the Database Group RIPE NCC

1 0