Skip to main content

Plenary Minutes

Minutes 24th RIPE meeting _____________________________________________________________ 24th RIPE meeting Minutes NCC staff Working Group Chairs/Scribes Berlin, Germany April 22-24, 1996 _____________________________________________________________ ripe-m-24.txt Page 1 Minutes 24th RIPE meeting _____________________________________________________________ AGENDA 1. Opening 2. Adoption of the Agenda 3. Minutes 23rd RIPE meeting 4. Actions 23rd RIPE meeting 5. RIPE NCC Report 6. Routing Arbiter Report - Update 7. Address Space & Routing: Conservation vs Aggregation 8. Review of RIPE NCC Activity Plan 9. Report from the IETF 10. Working Groups Reports 11. Next RIPE meetings 12. AOB 13. Closing APPENDICES Appendix 1: List of Participants Appendix 2: Open Action Items _____________________________________________________________ ripe-m-24.txt Page 2 Minutes 24th RIPE meeting _____________________________________________________________ 1. Opening 1.1. Welcome Rob Blokzijl welcomed the participants to the 24th RIPE meet- ing in Berlin, which was (co-)organised by DFN and held in the Mathematics Building of the Technical University of Berlin. After that, Dr. Klaus Rebensburg from the university held an opening speech. He showed some data about Berlin, among others the various scientific institutions and the net- work projects that the University was involved in. 1.2. Papers tabled: - Agenda for the 24th RIPE meeting - Working Group Agendas - List of Participants of the 24th RIPE meeting - CIX magazine 2. Adoption of the agenda Aside from a minor change (as Elise Gerich could not come, Gerald Winters would hold the Routing Arbiter update report), there were two additions to the agenda: o Joachim Schmitz would give a presentation on the new German broadband research network. o Rob Blokzijl would speak a few words about the European Council who are looking into the structure of the European Internet and the need to impose regulations. These points were handled at convenient times in between the other agenda points and are minuted under AOB. 3. Minutes 23rd RIPE meeting The minutes of the last meeting were approved with no changes. 4. Action points 23rd RIPE meeting The action items from the 23rd RIPE meeting minutes were reviewed. The following list comprises the ongoing action items only. All other action items were closed. Action 23.1 on Geert Jan de Groot To write up recommendations for managing nameserver con- figurations. Action 23.3 on RIPE NCC To incorporate a page where TLD policies can be pub- lished at its WWW site. _____________________________________________________________ ripe-m-24.txt Page 3 Minutes 24th RIPE meeting _____________________________________________________________ Action 23.5 on RIPE NCC To include a pointer to the EU-Mbone-FAQ in the RIPE WWW-server. Action 23.8 on Daniel Karrenberg To circulate a detailed proposal for the stored: attribute. Action 23.11 on Wilfried Woeber To initiate discussion on the mailing list about the extension of the inet-rtr: object. 5. RIPE NCC report For the first time, the RIPE NCC report was given by 3 peo- ple. First, Mirjam Kuehne gave a status report on the registration services. She showed some statistics on a.o. the number of incoming messages to and the number of registries (that is still growing with a rate of about 1 per working day). Upon touching the closure of the Last Resort registries, which the NCC is still dealing with, there were some ques- tions from the audience. Wilfried Woeber asked who of the Last Resort registries wanted to remain operating and thus become a normal provider registry. Mirjam answered that in many of these cases, the Last Resort registry was operated in conjunction with another (provider) registry by the same com- pany, so after some discussion they would probably also close. Miguel Sanz wanted to know what the actual process of closing the registries comprised. The answer was: these reg- istries will not receive service anymore and they will be asked to return the free address space to the NCC. Joachim Schmitz wanted to know what the new request tracking system was that the RIPE NCC was using. Mirjam told that after looking at some existing packages that were not consid- ered suitable, an own system had been made. It was hoped that the system would soon be ready to be released to the inter- ested people, after some debugging was done. Slides of Mirjam's report can be found at: The new business manager Carol Orange went on with a presen- tation on the new website that the RIPE NCC was working on, together with the School of Communication Systems in Utrecht. She showed a basic outline of how the site was going to look, and went into the system that would be used to prevent links to outdated information. After the website presentation she spent a few words on the financial situation of the RIPE NCC. _____________________________________________________________ ripe-m-24.txt Page 4 Minutes 24th RIPE meeting _____________________________________________________________ An overview of this can also be found in the Quarterly report, which is available at:{txt|ps} There were a few remarks about the website from the audience, among others that it would not be a good idea to have a visi- tors counter as caching of webpages will be done more and more. Also, there was a demand for information about which addresses are allocated to which registries. Carol said this would be incorporated in the website. Action 24.1 on RIPE NCC To incorporate information about which addresses are allocated to which registries in the website. After this, Daniel Karrenberg touched a few other subjects. He told that at last the NCC has been able to do some more technical project again, in the form of the redundant route robot which was caused by the discussion at the 23rd RIPE meeting. Daniel noted that it is important for the NCC to be able to react to RIPE's needs. Another point was that the period for budget planning of 12 months is actually too long. One thing where this can be seen is the increase in the number of registries, that is again higher than expected. At the next Contributors' Committee meeting in September, the NCC will probably suggest a shorter planning period. The restructuring of the NCC in terms of persons, which was necessary due to the growth, has been taken up. There is more hierarchy and division of tasks, now that there is a Manager Registration Services and a Business Manager. Daniel noted that the technical/software development would follow and also urged everyone who knew somebody with the qualifications for a Manager Technical Staff, to take up contact with the NCC, as this position is extremely hard to fill. Willi Huber had a question about the developments on the new usage-based charging scheme. The response was that with the new ticketing system, measurements have started. However, Daniel said that there is no clear direction yet in which plans will develop. 6. Routing Arbiter Report Gerald Winters showed some slides that highlighted the devel- opments in the Routing Arbiter tools. One of them is the AS Explorer, that now shows the ASes in a better way with (where possible) the names of the ASes instead of the numbers. Also, the amount of BGP traffic between ASes is displayed. Of each AS, time statistics on BGP traffic can be viewed. _____________________________________________________________ ripe-m-24.txt Page 5 Minutes 24th RIPE meeting _____________________________________________________________ Another tool is rtconfig, that now can also deliver code to configure Cisco routers. Gerald said that, because of the ongoing effort in Merit to clean up duplicate entries in the RADB, the number of AS and route objects is still decreasing. He also spoke a few words about who uses the RADB to register their policy or to con- figure their routers from it. There was a question from Ivan Communod on how the AS Explorer gets the names for the ASes. Gerald did not have the precise answer. 7. Address space & routing: conservation vs aggregation Daniel Karrenberg stated that the developments concerning this agenda point had already been discussed in the Routing working group and that they were also reported in the RIPE NCC Quarterly report. He had put this item on the plenary agenda to see if the audience had any questions or stories about developments since the last meeting. Also, he wanted to urge the audience to make other people aware of the problems and get them to do the right thing. There were not many reactions. A few questions were raised about publishing the statistics of the redundant route robot somewhere, so that it was publicly visible who the big offenders were. Daniel noted that that is already being done (a top 10 is sent to the Routing working group every week) and that it is planned to make statistics available nearly realtime. 8. Review of RIPE NCC Activity Plan Rob Blokzijl reported on the BOF about the revision of the Activity Plan that was held earlier. All the points in the activity plan had been reviewed. It was felt that the activ- ity plan did not need much updating. One or two points could be deleted and one new action had been proposed. Rob noted that people who are interested can join the discus- sion on the (majordomo-maintained) mailinglist . Below follows a brief list of comments and proposals that were received on the various action points during the BOF. All points not mentioned are unchanged. 3.2 c) Integrity of data: Not very active, should be taken up again now that staffing situation has improved. _____________________________________________________________ ripe-m-24.txt Page 6 Minutes 24th RIPE meeting _____________________________________________________________ Action 24.2 on Daniel Karrenberg To make a proposal for discussion in the Database Work- ing Group about how integrity checking of the RIPE Database should be taken up. 3.4 Coordination of database exchange Difficult to fulfill. Proposed to reformulate to reflect realistic possibilities. 3.5 Keep record of operational contact points Not realistic. Proposed to remove activity. 3.6 Placement of name servers Proposed to reformulate (monitoring & consistency checking) 3.9 Routing Registry Maintenance Not very active though useful activity. Needs more resources (1.5 FTE) Proposed to split into 2 activities: Routing Registry maintenance and training support for Local IRs. 3.10 PRIDE Tools Maintenance Needs reformulating, current version is useless 4.2 Database management tools Needs reformulating to be more general (not only whois) 4.3 DNS quality control tools Proposal to remove 9. IETF Report Joyce Reynolds held a talk about the last IETF meeting held in Danvers. She gave a comprehensive overview of the struc- ture of the IETF and of changes in the working groups and the IAB/IESG, and of things happening in her own area, User Ser- vices. Joyce published excellent, ASCII text, sheets which probably give the best summary of her talk and can be found at: 10. Working Group reports The chairs from the various working groups gave reports on the working group meetings that were held earlier. The min- utes made by each working group chair/scribe follow below, if they have been published to date. It is expected that more will be included in a next version of these RIPE Meeting min- utes. (The minutes may have been edited slightly to align the style with the rest of the minutes. Separate working group minutes _____________________________________________________________ ripe-m-24.txt Page 7 Minutes 24th RIPE meeting _____________________________________________________________ in original form can be retrieved from ) _____________________________________________________________ ripe-m-24.txt Page 8 Minutes 24th RIPE meeting _____________________________________________________________ 10.1. Routing Working Group Chair: Willem van der Scheun Scribe: Joachim Schmitz 10.1.1. Opening The preliminaries were done within short time (passing par- ticipant list around, looking for a scribe) 10.1.2. Minutes of last meeting, Action points The minutes of the last meeting were accepted without changes. Then, the actions from earlier meetings were dis- cussed. Action 22.8 on RIPE NCC/Merit To make the RADB publicly available on the the RIPE FTP server (if Merit concords) status: DONE Action 22.9 on RIPE NCC/ANS To find a final date when to give up advisory tags. status: DONE. Actually, the tags have been ignored by ANS since Nov 1995. Action 22.10 on Daniel Karrenberg To trigger the discussion on the mailing list of the Routing WG, which focus to choose for a future tool development project and to come to consensus on it status: OPEN (not yet started) Transferred to chairman Willem van der Scheun Action 22.11 on Daniel Karrenberg Based upon the focus found in the Routing WG, to prepare a draft paper for the new project and to present it at the next RIPE meeting in January status: OPEN (depends on previous action) 10.1.3. Agenda Bashing Then the audience was asked for any changes on the agenda. Willi Huber asked how to deal with organisations which want to become multihomed. This topic was discussed under the AOB item of the agenda at the end of the meeting. A short presen- tation by Peter Lothberg was added on a suggestion for expo- nential route flap dampening after "5. Routing table growth". 10.1.4. Routing Registry Progress Daniel Karrenberg of the RIPE NCC reported on the progress of the routing registry. It is found to be in good shape, espe- cially since - for the registration of new ASs, submission of a routing policy has become compulsory. This data is actually used _____________________________________________________________ ripe-m-24.txt Page 9 Minutes 24th RIPE meeting _____________________________________________________________ (by ANS, BT, and possibly others) to generate filters. ANS added on 14.May 1996 (Curtis Villamizar) that prior attempts to automate generation of policies for new ASs failed. The reason is missing data in the registries (aut- nums, routing policies, insufficient as-macros). At this point ANS still relies on notification from adjacent providers. - the effort to reduce redundancies and remove old data is continuing. This is most notable on the route objects. Their overall number in the RIPE database declines. ANS added on 14.May 1996 (Curtis Villamizar) that they have code to clean up prefix based policy exceptions. However, the RIPE NCC is caught again by the growth of the Internet and its resources did not permit to handle all new items or reports on errors in the database software. Steven Bakker then asked about the current state of the extended as-in, as-out attributes. As it turned out these attributes have not proceeded beyond the draft state and are not yet implemented in the database software. Moreover, the current PRIDE-tools won't work if the extensions are used in the database. Obviously, quite some effort must be put into it. However, to express certain routing policy elements the extension are indispensable. No workaround exists in the cur- rent implementation. The topic was transferred to the database working group. A presentation will be given there, showing the development of the database software in the last months as it was focused on authorization. The presentation will include future plans regarding further elements for the database. 10.1.5. Routing table growth The main presentation in this meeting of the routing working group was given by Daniel Karrenberg on the growth of the routing tables. It will be made available on the RIPE FTP- server as soon as DK has returned from vacation as ripe-m24-dfk-Less-routes Part of the data may also be found in the quarterly report Q1, 1996{txt|ps} As DK pointed out it has become a well known problem that ISPs which do full routing have run into severe problems regarding the size of routing tables and routing stability. This lead to ideas of quite repressive prefix filtering (e.g. by Sprint not accepting smaller prefixes than /19). However, Europe is in a good shape at least with respect to 193/8 and 194/8 because allocation of address space was done in aggre- gatable chunks from the start and there are many good neti- zens. To illustrate this DK showed some statistics he did for the combined 193/8 and 194/8 address space from the routing _____________________________________________________________ ripe-m-24.txt Page 10 Minutes 24th RIPE meeting _____________________________________________________________ table of the RIPE border router. He finds that o the total address space increases (doing no DNS analysis but simply counting each /24 as if it contained 256 hosts, /23 as 512 hosts etc). This conforms with allocation o the total number of routes decreases. This is due to aggre- gation. o the number of redundant routes also decreases. Currently, there are only approximately 12% redundant routes (but roughly 25% a few months ago). RIPE NCC started posting information on redundant routes per AS a few months ago and the response from ISPs is good. Actually, aggregation requests from the NCC were often accepted. Data on redun- dant routes is available on the RIPE FTP-server at* Yet, the definition of when to treat a route as being redun- dant is not easy. Up to now a route has been defined as redundant if it was possible to build a less specific aggre- gate which contains this more specific route, based upon ori- gin and AS-path information. However, there is a general feeling that many more redundant routes exist if origins or other information could be analysed more thoroughly. For the time being DK wants to o automate the analysis possibly allowing near real time analysis and use a dedicated machine from which to collect the data o educate and explain to more ISPs why this effort is valu- able and needed, maybe even trying to give hints on router configuration o convince people possibly by peer pressure to really adopt the changes necessary on their side Future development should include refinement of the defini- tion of equivalent or redundant routes, respectively, and probably extension of the analysis to the net outside Europe. These topics were vividly discussed by the audience. Wilfried Woeber asked how "outside Europe" could be defined - whether geographically or by address space. DK answered that it was not yet specified, but by definition European routes are in 193/8, 194/8. WW also wants to have the effort extended to the 192/8 block, at least for the allocations done in Europe and asked whether this was a political of technical problem. DK did not see real problems but estimated that problems could arise because on the RIPE NCC border router not all US routes are seen which might make analysis beyond Europe more difficult. Blasco Bonito wanted to push the education element and asked whether a FAQ on this topic existed. Actually, Hank Nuss- bacher has already started the CIDR FAQ. Probably, some addi- tions should be made. An action was put on the chair- man to investigate the status of the CIDR FAQ and see whether addi- tions are needed, probably by triggering a discussion on the mailing list. _____________________________________________________________ ripe-m-24.txt Page 11 Minutes 24th RIPE meeting _____________________________________________________________ Mike Norris pointed out that configuration examples for routers will be difficult to set up because it depends on the local situation of each ISP and router hardware or software used. Joachim Schmitz added that the current analysis should be extended by comparing the data of routing tables to the route objects actually registered at the database, maybe even test- ing conformity with the routing policy as it is found in the database. DK agrees and thinks that it is a very important step to be done in the future. Yet, according to DK's opinion the work done so far on discovering redundant routes could be used for this. Finally, DK asked how the routing working group could be involved. He asked for suggestions, especially on filtering of prefix lengths where he thinks that reducing redundancy is more worthwhile (even a /32 prefix could be meaningful if it points e.g. to a root nameserver). Ruediger Volk suggested to identify which ASs are of European origin to reduce the effort. Other valuable points are peer pressure and endorse- ment. 10.1.6. Exponential route flap dampening After this talk Peter Lothberg presented a suggestion on exponential route flap dampening, another effort to reduce the pressure exerted by Internet growth. Given several inter- connected ISPs with a flapping connection on one end, this may lead to complete loss of connectivity with respect to the other end across the intermediate ISPs. The reason is that propagation of routing information takes time. If the flap- ping frequency is higher than propagation across the net at least one ISP in between will not have a valid route for the corresponding connection at any given time. Besides computing new routing tables over and over again, dropping of packets is also costly for routers (if they do not have a default route). To circumvent this problem PL suggests that updates on the routing tables should be done ever more reluctant the greater the prefix of the route is. The premise is that small prefixes are most likely to be aggregates and should be updated as soon as possible while greater prefixes should either be aggregated (e.g. by forcing people to renumber when changing ISPs) or the connections made more stable (which is difficult with smaller organisations and ISPs as experience shows). As a first draft proposal, prefixes of /16 should be updated without delay, /17 with a tiny delay, /18 with small delay, etc, /24 maybe changed only once a day. Surprisingly, no protest was uttered from the audience. However, there is no implementation of this scheme yet while PL thought that it could be implemented pretty fast. In the following discussion MN felt that dampening delays must be globally the same and should be hardcoded to be efficient - but it would then be difficult to change them if need arises. A further clarifica- tion among DK and PL stated that dampening is applied to _____________________________________________________________ ripe-m-24.txt Page 12 Minutes 24th RIPE meeting _____________________________________________________________ outbound updates only. ANS added on 14.May 1996 (Curtis Villamizar) that the imple- mentation of route flap dampening is complicated business. It should only be applied to EBGP (probably inbound only) and delays must be handled carefully. If this is not done correctly, inconsistent data may arise, routing loops occur, or black holes are generated. Moreover, route withdrawal should be propagated faster than announcements. 10.1.7. Routing WG future activities, input to RIPE NCC This item from the agenda was skipped. Discussion will be done through the mailing list first. 10.1.8. AOB The final topic of the meeting was the discussion of multi- homed organisations. WH asked whether anybody had collected pros and cons to give when requests occur. This did not seem to be the case but the general feeling was that multihoming should not be encouraged because o it leads to more routes in the Internet o if more specific routes are announced by one ISP involved, less specific ones by an other, then the ISP with the more specific announcement will attract the traffic which is not necessarily desired o moreover, it may become necessary that certain ISPs down- stream should prefer routes at given exchange points to reach the multihomed organisation through certain ISPs rejecting routes through other ISPs. This is near to impos- sible. PL thinks that this problem is solved automatically as the Internet evolves by the bare needs of running the Internet. New action items: Action 24.3 on Daniel Karrenberg To put his presentation on routing table growth on the RIPE FTP-server as routes Action 24.4 on Willem van der Scheun To investigate the status of the CIDR FAQ and see whether additions are needed, probably by triggering a discussion on the mailing list. _____________________________________________________________ ripe-m-24.txt Page 13 Minutes 24th RIPE meeting _____________________________________________________________ 10.2. Local IR working group Chair: Mike Norris Scribe: John Crain 10.2.1. Preliminaries The minute-taker/Scribe was chosen. The agenda was agreed upon. 10.2.2. RIPE 23 There were no comments on the minutes. Actions outstanding; Action 21.3 on Daniel Karrenberg, Mike Norris To draft a recommendation on charging by local IRs until September DONE Action 23.6 on RIPE NCC To organise a Local IR workshop in conjunction with RIPE24. DONE Action 23.7 on RIPE NCC To include a paragraph in ripe-104++ on procedures for the reverse delegation of partially assigned class B networks. DONE 10.2.3. Reports from registries Report from regional registry RIPE NCC, Mike Norris introduced the quarterly report. He asked if it could be moved to the plenary as it will be presented there anyway. Nobody objected. No reports or "war stories" from other registries. No reports from other regional registries. 10.2.4. IP Address Space Assignment Procedures RIPE-104 Blasco Bonito mentioned that it was difficult to explain the reasons for the static-dialup policies. He asked if this could be explained more concisely in ripe-104++. Mike Norris stressed that a major point in 104++ is that an _____________________________________________________________ ripe-m-24.txt Page 14 Minutes 24th RIPE meeting _____________________________________________________________ assignment is only valid so long as the criteria on which the assignment was based are still valid. He also announced that inaddr procedures (RIPE-105) have also been incorporated into RIPE-104++(Draft version). Mike Norris stressed that RIPE-104++ was not yet complete. Action 24.5 on RIPE NCC, Editorial Committee To complete the RIPE-104++ draft document and circulate it. There was also consensus that the parts of ripe-104++ that were approved already, should be published as a RIPE document even though the full document was not complete yet. This should be done because a draft document would not have suffi- cient authority, while the old ripe-104 was no longer opera- tive. Supporting documentation. Mike Norris announced the combination of RIPE-128 and -129 in the draft document RIPE-128++. Commented that this was defi- nitely needed and quickly. This document had been discussed in the LIR workshop and some problems had been noted. Espe- cially the points concerning end-user use of the document. He suggested that the document be discussed for a short period and then accepted as soon as possible. Mike Norris asked for comments on the documents: Yves Devillers asked when would the documents be ready for formal adoption. The document should be ready for RIPE 25 in the third quarter of 1996. The previous RIPE-104++ is in use and the first four sections have been approved at RIPE 23, the rest should be approved at RIPE 25. There were concerns about running on a "Draft document". Daniel Karrenberg & Rob Blokzijl stated that at the moment it is the best document we have. Action 24.6 on RIPE NCC To produce new IP Address Space request forms in May 1996 (Note: The currently adopted chapters of RIPE-104++ are now published as RIPE-136. The IP Address Space request form and the supporting notes are published as RIPE-137 and RIPE-138.) _____________________________________________________________ ripe-m-24.txt Page 15 Minutes 24th RIPE meeting _____________________________________________________________ 10.2.5. Charging by Local Internet Registries RIPE NCC Charging model, This is in the RIPE NCC Report and will be left until the plenary. Paper by Karrenberg and Norris Mike Norris presented a draft sheet concerning charging behaviour for Local IRs. The document identifies name- and address-space as finite resources with no intrinsic value. Recommendations for registries are; Registries should publish there operating procedures, details of the services they offer, including tariffs etc and the fact that they do not sell name- or address-space as such. Special case registries should publish policies and be open. This is the best way to stop monopoly complaints. Daniel Karrenberg stated that the content of the document is already the consensus but now needed writing down. Blasco Bonito stated that he agrees with the content but would like to see lobbying of the Top Level Domain adminis- trators on this document. The document will be passed on to the DNS-wg and posted to the TLDs known to the RIPE NCC. It will also be posted on a TLD mailing list. Various persons had problems with some of the wording, espe- cially those sections concerning, consensus and profits and the phrase "nor be seen to generate". There was some discussion as to if a domain-name holder can resell that name. This falls outside the scope of the document and is a matter of local rules. The document only concerns the behaviour of LIRs. The document tries to document how a registry should behave not at the next level. Mike Norris summed up this by saying that the document is about charging for services and not for name- or address- space. It is meant to be a summary of expected behaviour. The document will be passed on to the DNS wg with idea of adoption in the plenary. _____________________________________________________________ ripe-m-24.txt Page 16 Minutes 24th RIPE meeting _____________________________________________________________ Action 24.7 on Mike Norris To circulate the paper on changing by registries to the TLD registries. 10.2.6. Training RIPE Training courses There have been three since RIPE-23 and three more are planned. The training courses have been receiving positive feedback. Recommendations have been made for separating the training into different categories/levels. There are also new ideas for training courses. 10.2.7. Input/Output with other working groups Database-wg 104++ is already there. Routing-wg Improving aggregation by reclamation is it worth while? DNS-wg "Charging by Local Internet registries" document. 10.2.8. Global Registry Coordination Daniel Karrenberg: There has been an increase in phone calls from US NOCs because of wrong or misleading info in the Internic database. Do others have problems? Should we ask the internic to remove all info? There was general consensus to ask the Internic to remove the data. The question was raised "Should the AS objects also be removed?". Action 24.8 on Daniel Karrenberg To raise the question of removing data on European net- works from the InterNIC database. Because some US providers insist that your AS is registered in the database before they will peer with you, we shouldn't ask for these to be removed. _____________________________________________________________ ripe-m-24.txt Page 17 Minutes 24th RIPE meeting _____________________________________________________________ 10.2.9. Reverse Domains Mike Norris: The procedures are now in RIPE-104++. Anything to report? Daniel Karrenberg stated that the situation with was "not that bad". 10.2.10. AOB Carol Orange announced that the Quarterly reports were out- side _____________________________________________________________ ripe-m-24.txt Page 18 Minutes 24th RIPE meeting _____________________________________________________________ 10.3. Netnews Working group Chair: Felix Kugler Scribe: Felix Kugler 10.3.1. Introduction Welcome to the first meeting. The participants list was passed, there were 21 attendees. Nobody wanted to risk being scribe and it took some time to find a "volunteer'. Unfortu- natly, it was impossible later on to get the notes. The min- utes are now based on the chair's sparse notes. There were no changes proposed to the agenda. 10.3.2. News traffic analysis Felix Kugler presented a number of slides showing how News traffic grew from March 95 to March 96, both in terms of articles (+40%) and data volume (+400%). Measurement point was a SWITCH News server. The alt hierarchy now dominates News traffic with approx. 85% of the total volume, and it has by far the highest growth. The daily traffic pattern shows that still most articles originate in US. We see traffic peaks during US-"active hours" corresponding to night to mid- morning in Europe. Interestingly, weekend data volumes are much higher nowadays and the average article size is signifi- cantly higher at those times. Slides are available from ripe24/ Conclusion: News traffic is growing at a breathtaking pace and adds up a considerable amount of the total traffic of a typical network. The lion's share of News volume is in the alt hierarchy. The good news is that Netnews traffic peaks at times where Europeans use less bandwidth for interactive work. Analysis of today's News distribution paths Heiko Rupp (XLINK) presented the model of his path analysis system. A number of well connected sites define a special channel on their News server which pipes header information of every incoming News article into a Perl script. The script parses the Path:-header line and fills a database of trans- mitted articles between adjacent news servers. An extract of this database is sent to Heikos workstation on a regular basis where the data is combined and analyzed. Fancy scripts create Postscript maps automagically. The resulting maps are available on Xlink's WWW server. They are considered examples only because only three measuring sites - located at XLINK (DE), SWITCH (CH), and University of Pisa (IT) - were used for the prove of concept. _____________________________________________________________ ripe-m-24.txt Page 19 Minutes 24th RIPE meeting _____________________________________________________________ This work got much attention. Heiko will improve his scripts and announce them when ready. He takes care that no patches on the installed news server software is needed which would make the package difficult and dangerous to install. Two potential weaknesses were pointed out: the maps are based on the article count and not on the transmitted data volume which is considered more important for the underlying net- work, furthermore the graphs do not show the direction of newsflow. It was decided to stick with what we have now and make this operational. In a later phase the package could be enhanced to address the problems mentioned before. Three additional ISPs volunteered to install and run the scripts for "production": ACONET (AT), DEMON (UK), TELIA (SE). For a reasonable coverage, more measuring sites will be needed. This can be accomplished offline. In the "production phase", data shall be collected once per week. More details will be announced later. Heiko's slides are available from 10.3.3. Minimizing Netnews resource usage Transatlantic newsfeeds It was agreed that avoiding waste of transatlantic bandwidth has top priority. Low latency interconnections between Euro- pean endpoints of US-feeds shall minimize multiple transmis- sion of articles over the expensive transatlantic links. In fact, part of this News Backbone already exists, and it even crosses the boundaries of the "big" European service providers. Unfortunatly, the latency is in many cases clearly too high, mostly due to overloaded News servers and links. There are only few servers with online monitoring facilities so that the performance of many servers often can be guessed only after a certain time when local statistics are available. Based on the newsflow maps and "human experience" the news- feed topology should be improved and a News backbone be real- ized. As soon as this fast European News Backbone works well and reliably, a reduction of the number of US-feeds can be considered. Gerhard Winkler (ACONET) points out the value of local peer- ings because bandwidth costs are negligible in most cases. However, local peerings might be difficult to arrange for competitive considerations when the newsflow between the peers is heavily unbalanced. _____________________________________________________________ ripe-m-24.txt Page 20 Minutes 24th RIPE meeting _____________________________________________________________ Coordination of intra-ISP News distribution It was tried to get an idea from the attendees how News is distributed within the international ISP's networks. The resulting picture is very incomplete and to be interpreted with caution. DANTE: No managed News service so far but plans to start a pro- ject. Central NRN's with multiple international links usually have good, bilaterally coordinated newsfeeds, single attached NRN's have more problems to get feed. Contact: Felix Kugler, SWITCH EBONE: No managed News service, no central coordination. It is reported that the informal coodination works well and that every connected network can get a full feed for free from a neighboring network. Contact: Gerhard Winkler, ACONET PIPEX: Runs several News servers so that there is usually only one feed on an international link. Contact: Mark Turner, PIPEX UK The contacts mentioned above do not necessarily denote responsible persons, but usually well informed people. Other methods to save resources Dropping newsgroups/hierarchies with excessive volumes (all kind of binaries) is considered a bad move though pushing binary stuff onto ftp/WWW-servers would be a reasonable goal. The problem is how to filter out binaries. The obvious first approach would be to filter based on the newsgroup name. How- ever, binaries are often posted to non-binary groups exactly to bypass such newsgroup exclusions. Filtering based on article size will most probably not work either. It just leads to smaller but more fragments and reduces the probabil- ity that a binary gets transmitted completly, thus triggering numerous "please repost" requests. Mikael Kullberg (TELIA) remarks that it was probably a mis- take to enlarge the maximum fragment size on Usenet from 64kB to typically 1MB. It is probably not possible in practice to go back to smaller fragments in a coordinated way, so we have to live with the big fragments we have now. The use of intelligent (dynamic) servers and proxies is con- sidered interesting for leaf sites. It is not a topic for the WG at the moment. _____________________________________________________________ ripe-m-24.txt Page 21 Minutes 24th RIPE meeting _____________________________________________________________ 10.3.4. Making the backbone more reliable - News backbone server requirements There was only a short discussion due to time shortage. This topic is to be pursued on the netnews-wg list after the meet- ing. There was consensus that the following issues should be tackled: - latency goals - minimum expire period - minimum set of newsgroups - control message handling - handling of national/regional hierarchies - status monitoring facilities Some sites already have online-monitoring facilities in place. The following were mentioned at the meeting: PIPEX: WWW-interface (ex: SWITCH: VT-100 based (ex: telnet, login: shownews) A list of News servers with available monitoring information is planned to be setup after the meeting. 10.3.5. Tools This agenda item too was postponed due to time constraints. It was pointed out that Dave Barr maintains very complete INN pages on his WWW server with a bunch of useful tools. Check for more info. innfeed, a new INN backend program, is now in beta-phase. Though it still has some etches it is considered an important improvement over today's nntpsend/nntplink programs. It will be part of future INN releases. 10.3.6. The future of Netnews distribution Apart from improvements of the current News transmission technology, fundamentally different ways to transport News are possible. Keywords are satellite transmission and IP mul- ticast. Satellite transmission is already in use at least in the US, but none of the attendees had detailed knowledge or experi- ences about this. Heiko Rupp (XLINK) gave a short introduction about News transport via IP multicast. UUNET obviously has experimented with this technology some time ago, but gave up for the moment due to limitations in their implementation (a 9kB size limit imposed by UDP code) and the fact that no reliable mul- ticast network is in operation yet. There was a presentation on a USENIX conference about their system. Check the document _____________________________________________________________ ripe-m-24.txt Page 22 Minutes 24th RIPE meeting _____________________________________________________________ "Drinking from the Waterhose" by K. Lidl and J. Osborn, for detailed info. 10.3.7. Central info point for Netnews distribution This agenda item was dropped. The WG will take care of this as soon as there is a need for an info point. 10.3.8. Closing The netnews WG is likely to meet again at the next meeting, but a final decision is postponed. _____________________________________________________________ ripe-m-24.txt Page 23 Minutes 24th RIPE meeting _____________________________________________________________ 11. Next RIPE meetings The scheduling of the next meetings was discussed and the following dates and locations were agreed: o RIPE 25 - September 1996 - Amsterdam, Netherlands (Note: The date was later set to September 23-25) o RIPE 26 - January 1997 - Amsterdam, Netherlands o RIPE 26 - April 1997 - Dublin, Ireland 12. AOB Two agenda items that had been added and handled at conve- nient times in between the other points: 12.1. Developments in European Council Rob Blokzijl told the audience that there was a point of decision on the agenda of the European Commission to start a process that will investigate the problems of the European Internet and impose regulations. He stated that RIPE had two options: either ignore this and possibly have regulations imposed on them in the future, or investigating what goes on and trying to influence the direc- tion that will be taken. Daniel Karrenberg noted that if the last option is pursued, then this clearly changes the charter of RIPE which used to be a forum for purely technical issues. Robs answer was that the RIPE NCC has already been broadening its scope, and the European Council will see the NCC as a regulatory body. He hereby referred to the NCC charging model. Aidan McDonald noted stated that he thought the focus of the European Commission would be mainly on social affairs, refer- ring to a presentation he had seen from an Irish Minister who is part of the Council. Rob said that this was one issue, but that there was also a commission that was going to study reg- ulation. Mike Norris made a statement: As Internet people we tend to laugh at bureaucrats imposing regulations. We must realise that to a certain extent we are bureaucrats ourselves, and impose regulations on ourselves, in order to run our business and keep the Internet working together. We should perhaps look how we can persuade the European Council that what we do already, is a good thing. 12.2. Presentation about B-WiN Joachim Schmitz gave a presentation about the new Breitband Wissenschaftsnetzwerk (B-WiN, = broadband research network ) that is installed all over Germany. In the past few years, _____________________________________________________________ ripe-m-24.txt Page 24 Minutes 24th RIPE meeting _____________________________________________________________ there had been several investigations on higher bandwidth than the currently used WiN (Wissenschaftsnetzwerk) that runs IP over x.25. The network that came out and is now built is a Virtual Private Network based on ATM. The German backbone is 34 Mbit/s, some of the network's lines are 155 Mbit/s. At the moment there will only be IP services delivered, later it is planned to have the possibility of direct ATM connections for customers. Joachim showed some maps and statistics about test results and how the network is now. The empty network has been tested and at this moment customers are being moved from the WiN to the B-WiN. Daniel Karrenberg asked if there was a solution for the fact that there were now 34 Mb lines inside Germany and all out- side links were 9 or 10 Mb. Joachim answered that this was still being investigated. Traffic analysis had shown that 70% of the traffic stays inside Germany. Peter Lothberg asked if there were any Internet Exchanges connected to the B-Win, like in Sweden. Joachim answered that other ISPs are customers of the network. There are no public IXes. To a question of Aidan McDonald on who provided the switching equipment, he answered that Deutsche Telekom did this at the main nodes. Others are also provided by the cus- tomers themselves. These switches are the same. Erik-Jan Bos asked if there had already been some tests with IP over VPB. There had, and if anybody was interested Joachim could provide a pointer to the test results. 13. Closing Rob Blokzijl thanked the TU Berlin for providing the room facilities and DFN, specifically Juergen Rauschenbach, for the efforts in organising the meeting, and declared the meet- ing closed. _____________________________________________________________ ripe-m-24.txt Page 25 Minutes 24th RIPE meeting _____________________________________________________________ List of participants Roland Acra Cisco Systems, Europe James Aldridge EUnet Communications Services Richard Almeida Internet Network Services Ltd Amar G Andersson Telia Net Jesper B. Andersson Telia Net Jose Manuel de Arce Telefonica Transmision de datos Eva Arriola Telefonica Transmision de datos Steven Bakker DANTE Tony Barber PIPEX International Andrew Beaven Cable Online Ines Birke Xlink, Karlsruhe Rob Blokzijl NIKHEF Asquith Bonaparte JIPS NOSC (JANET) Brehde DESY Antonio-Blasco Bonito IT-NIC Erik-Jan Bos SURFnet bv Daniele Bovio America Online Philip Bridge Unisource Wilhelm Buehler Xlink, Karlsruhe Sedat Capkin SARA Roberta Caponi University of Pisa - Italy Graca Carvalho Telenet Portugal Tim Challenor Internet Network Services Ivan Communod Global One John Crain RIPE NCC Guy Davies UUNET PIPEX Magnus Danielson KTH Yves Devillers EUnet - France Gert Doering SpaceNet GmbH ( Sabine Dolderer DE-NIC Oliver Doll EUnet Deutschland Armando Domingues FCCN/RCCN Barbara Dooley Commercial Internet eXchange Libor Dostalek PVT,a.s. Francis Dupont INRIA Rocquencourt Havard Eidnes NORDUnet Erzsebet Erdei Westel900 GSM Alfons Friedl SERVICOM Luciano Gaido I.N.F.N. Juan A. Garcia RedIRIS Elisabetta Ghermandi INFN-CNAF Andrew Hilborne ONYX Network Services Kevin Hoadley JANET/ULCC Hans Petter Holen Schibsted Nett Nandor Horvath EUnet Hungary Jan Hrdonka EUnet Czechia Willi Huber SWITCH Robert Huey CompuServe Inc. Sabine Jaume RENATER Vit Jelinek SPT TELECOM, a.s. - Nextel, o.z. Johannes 5 Joemann TerraOnline _____________________________________________________________ ripe-m-24.txt Page 26 Minutes 24th RIPE meeting _____________________________________________________________ Daniel Karrenberg RIPE NCC Kurt Kayser ECRC, Germany Ed Kern DIGEX David Kessens RIPE NCC Ronald Khoo Demon Internet Limited Karen Kinsella Telecom Eireann Kimmo Kosonen Telecom Finland Petr Kral CESnet Mirjam Kuehne RIPE NCC Felix Kugler SWITCH Mikael Kullberg Unisource Business Networks / Telia Klaus Landefeld Nacamar Ingrid Ledererova CESNET Lars-Johan Liman EBONE Guido Loeffler University of Muenster Peter Lothberg STUPI AB Michael D. Lyons AT&T Tomas Marsalek GTS CzechCom Aidan McDonald RTC Carlow Keith Mitchell PIPEX International Herman Moons DNS-BE Registration Office - KULeuven Roderik Muit RIPE NCC Ireneusz Neska NASK Mike Norris HEAnet Thomas Ohrbom UNINETT Jarmo Oksanen Telecom Finland Knud Bisgaard Olesen Tele Danmark Erhverv Carol Orange RIPE NCC Mariusz Ostrowski NASK Edouard Ouin INRIA Berthold Paffrath Deutsche Telekom Ulrich Plate Nacamar Federico Porri Telecom Italia Franck Pradal France-telecom Vlado Pribolsan HPT Francesco Pugliese Telecom Italia - Network Division Kristian Rastas Telecom Finland Juergen Rauschenbach DFN Annie Renard INRIA Joyce Reynolds Information Sciences Institute Marc Roger BELNET/OSTC Paul Rolland OLEANE Nicola Roserba Telecom Italia Valeria Rossi CILEA Heiko W. Rupp NTG/Xlink Jussi-Matti Salmela Telecom Finland Miguel A. Sanz RedIRIS Willem van der Scheun SARA Heiko Schlichting FU Berlin Joachim Schmitz DFN-NOC, Rechenzentrum Univ-Stuttgart Ivan Sedinic HPT - Croatian Post and Telecom Nicholas Shield UKERNA Dimitri Sidelnikov FREEnet Franck Simon RENATER _____________________________________________________________ ripe-m-24.txt Page 27 Minutes 24th RIPE meeting _____________________________________________________________ Oliver Smith Demon Internet (UK) Cliff Stanford Demon Internet Henk Steenman SURFnet Stefano Suin University of Pisa - Italy Peter Suveges GTS Hungary Martin Telgmann Deutsche Telekom Nigel Titley British Telecom Marton Tkacik Westel900 GSM David Tomalin Cable Online Bill Unsworth U-NET Limited Pavel Vachek CZ.CESNET Daniele Vannozzi CNR Ruediger Volk Deutsche Telekom Holger Weinhardt EUnet Deutschland GmbH Gerhard Winkler Vienna University Computer Center Gerald Winters Merit Network, Inc. Wilfried Woeber VUCC / ACOnet Janos Zsako BankNet _____________________________________________________________ ripe-m-24.txt Page 28 Minutes 24th RIPE meeting _____________________________________________________________ List of open action items Action 23.1 on Geert Jan de Groot To write up recommendations for managing nameserver con- figurations. Action 23.3 on RIPE NCC To incorporate a page where TLD policies can be pub- lished at its WWW site. Action 23.5 on RIPE NCC To include a pointer to the EU-Mbone-FAQ in the RIPE WWW-server. Action 23.8 on Daniel Karrenberg To circulate a detailed proposal for the stored: attribute. Action 23.11 on Wilfried Woeber To initiate discussion on the mailing list about the extension of the inet-rtr: object. Action 24.1 on RIPE NCC To incorporate information about which addresses are allocated to which registries in the website. Action 24.2 on Daniel Karrenberg To make a proposal for discussion in the Database Work- ing Group about how integrity checking of the RIPE Database should be taken up. Action 24.3 on Daniel Karrenberg To put his presentation on routing table growth on the RIPE FTP-server as routes Action 24.4 on Willem van der Scheun To investigate the status of the CIDR FAQ and see whether additions are needed, probably by triggering a discussion on the mailing list. Action 24.5 on RIPE NCC, Editorial Committee To complete the RIPE-104++ draft document and circulate it. Action 24.6 on RIPE NCC To produce new IP Address Space request forms in May 1996 Action 24.7 on Mike Norris To circulate the paper on changing by registries to the TLD registries. _____________________________________________________________ ripe-m-24.txt Page 29 Minutes 24th RIPE meeting _____________________________________________________________ Action 24.8 on Daniel Karrenberg To raise the question of removing data on European net- works from the InterNIC database. _____________________________________________________________ ripe-m-24.txt Page 30