RIPE 21 Minutes

1. Opening

1.1. Welcome

Rob Blokzijl welcomed the participants to the 21st RIPE meeting in Roma, Italy, that was organised by GARR/NIS and hosted by the CNR.

After that he gave the word to the president of CNUCE, Prof. S. Trumpe, who also welcomed the participants. He said he was happy to see this amount of people attending - it was the largest RIPE meeting until now, with around 110 attendees. Also, he noted that from the people attending, one could see that commercial providers now formed the majority of organi- sations interested in the Internet, as opposed to academic organisations.

1.2. Papers tabled

• Agenda for the 21st RIPE meeting
• Working Group Agendas
• List of Participants of the 21st RIPE meeting
• RIPE NCC income status - Daniel Karrenberg

2. Agenda

The agenda was approved. Note: the talk on the Internet World Exposition was held at the start of the meeting, but the agenda items are minuted as originally scheduled.

3. Minutes of the last meeting

The minutes of the 20th RIPE meeting were approved with no changes.

4. Review of the action list of the last meeting

The action items from the 20th RIPE meeting minutes were reviewed. The following list comprises the ongoing action items only. All other action items were closed.

Action 19.12 on Marten Terpstra (to be taken over by NCC)
To write up the proposed "stored"/"processed" attribute.

Action 20.2 on Rob Blokzijl
To bring up the CERT issue during the next TERENA Contributors Committee meeting

Action 20.5 on Daniel Karrenberg
To draft outline "applications document" to support the proposed plan on how to deal with address space requests from VSE's Action 20.10 on Havard Eidnes To write up a proposal with input from the Local-IR WG and the EOF (European Operators Forum)

Action 20.14 on Milan Sterba
To update the Connectivity Document Store home page

Action 20.13 on Milan Sterba
To periodically send out a call to RIPE NCC contributors to publish in the Connectivity Document Store

Action 20.15 on Milan Sterba
To produce a metrics sheet for the Connectivity Document Store

Action 20.22 on Francis Dupont
To send a pointer to PIM for BSD 4.4 as soon as it is available

Action 20.24 on Daniele Bovio
To set up the matrix to keep track of the RIPE meeting actions

5. RIPE NCC Report

Daniel Karrenberg presented the RIPE NCC Report. The statistics that he showed, indicated that the number of hosts and local registries was still growing. The growth was not even linear anymore. Especially the number of small Provider Registries was increasing, the other categories remained almost constant in size.

Daniel indicated that the new Provider Registries need more support and guidance than the ones having a longer Internet history. They form a significant load factor. Once again it was made clear that the RIPE NCC only gets them started on registry procedures and is not teaching them how to run a service provider business.

The number of messages received by the RIPE NCC also shows an increasing growth. This does not leave enough time to support the local IRs and not at all to adapt and produce documents. Due to the fact that more than 50% of the NCC workload comprises routine duties, the risk of the (technical) staff burning out still remains.

The number of staff, in FTE, has remained constant since the last meeting. However, a new junior hostmaster is being hired, in the person of Hatice Kuey, who will start mid-June. This amount of staffing is not enough by far. The additional FTE should be consumed by the new activities 'Routing Registry' and 'PRIDE Tools Maintenance' that the RIPE NCC has accepted. As for the other jobs, the NCC is still 'in catch-up mode'. There is no time left for strategic actions.

Conclusion: The situation is still improving but only very slowly.

The report went on with an overview of the activities since the last report:

• A better billing mechanism has been implemented with more structured procedures. At this point the new procedure had become a routine operation.
• The registry activities were being streamlined by the introduction of a ticketing system for hostmaster requests. This kind of extreme automation did not look not very friendly to the outside world sometimes, but was necessary with the workload the NCC experiences.
• Preparations had been made to resume the quarterly reports: the gathering of statistics and report formatting had been more automated and simplified.
• A course has been developed for the training of registries. The outline of this course is available.
• Of the Routing Registry Maintenance project, the activity plan has been completed, but there has been little other action in this field so far.
• No progress has been made on the development of a charging model for 1996.
• The coordination among the Regional Registries has improved. (During talks it became clear that the rumour on the InterNIC being less strict in handing out IP addresses than the NCC, is not true.) The production of an RFC1466bis document appeared more difficult than expected due to some controversial issues involved.
• The most important activity, however, had been keeping up with the daily workload.

The plan for the coming period, besides trying to keep up, is to start all those activities mentioned. There will be a first training course for new local registries on June 26th. There will be work done on the routing registry maintenance, the startup of the quarterly reports and the 1996 charging model. There are no new projects.

The new NCC staff will have to be trained and also there are plans to hire more staff, being another junior hostmaster and a deputy manager. However there might be some problems in getting new staff and it will not be realised before the end of the year. The NCC is planning to use temporary external help as much as possible. Daniel urged everyone with initiatives on this to talk to the NCC.

After the report there was room for asking questions.

There was a remark from Peter Lothberg that the RIPE NCC could delegate some of the work to the Local Registries, because the workload was getting so high. Daniel replied that the NCC actually does this as much as possible and that is why the system in Europe works so well. The work that the RIPE NCC does at the moment is difficult to distribute as the

NCC has to coordinate and monitor it and to watch out that the guidelines are being followed.

Mike Norris asked if the NCC has any knowledge if the requests that are sent to the ip-provs mailinglist are actually being honored. The reply was that the NCC hardly has any idea about this, as the Local Registries contact the requesters directly. Two to three requests a day are posted on the list. About one requestor in 2 months comes back to the NCC a second time, this is the only indication the NCC has.

Stephan Biesbroeck asked if the NCC is sure that there are only Local Registries on the ip-provs list. The answer was positive; the mailinglist is automatically generated from the registry database.

The slides of the presentation are available at the URL

• ftp://ftp.ripe.net/ripe/presentations/ ripe-m21-dfk-NCC-REPORT.ps.Z

6. RIPE NCC Finances

Daniel's financial report started with an overview of the RIPE NCC expenditures in 1994. The actual expenditures for staff resources were higher than budgeted, the other expenditures didn't deviate much from the budgeted amount.

In the books, the 1994 income was as budgeted. With the credit from 1993 taken into account, the 1994 income and expenditures yielded a booked positive result. However, there were still a lot of unpaid contributions for 1994 so the real result was negative. The NCC was chasing late payments.

The unpaid contributions were partly caused by the fact that the billing procedure had been removed too far from the NCC, and the NCC had almost no possibility for sanctions. These problems had been fixed. As of 1995, the billing was handled by the NCC itself. All the billing data were stored in a reg- istry database and the NCC had introduced different levels of service to distinguish among those contributing and those not contributing.

Compared to the 1994 expenditure budget, the 1995 budget showed a much higher amount for staff resources and related expenditures. Some increase might be needed if the growth on the workload continued. On May 4th, the amount of payments committed were already 118% of the expenditure budget and 67% was actually paid. The income from the sign-up fees for new registries would be kept aside from the normal expenditures to be spent on those new registries used for the training of new registries.

After the presentation, there was room for questions and remarks.

Lars-Johan Liman asked how the 1994 reserves were going to be used. The answer was that there probably would be none, as it was not clear yet if the result would be positive or nega- tive. Keith Mitchell asked if Daniel was sure that he could get the payments from those who hadn't paid their 1994 bills. Daniel said he was quite confident of that.

There was a question from Klaus Landefeld if there were still commitments coming in. The answer was positive. He then asked if the status of the RIPE NCC as a non-profit organisation would still be valid, with a considerably larger income than budgeted expenditures. Daniel replied that there were no tax problems. TERENA is a non-profit organisation and the NCC can take the money with them into the next year. To Klaus' inquiry to the procedures of the next year, if the income would continue growing like this, the reply was that the money would all go into the staffing and the tasks mentioned in the NCC activity plan. However, the billing schedule of 1996 would still have to be decided upon by the contributors committee in July 1995. Wilfried Woeber made the remark that the NCC would need the money reserves, because in 1996 the payments would not be in at one third of the year but at the end, due to the usage based charging model.

Mike Norris asked for an estimation on the income from sponsors. Daniel replied that it would be about 5% of the NCC budget. The income from sponsors would be used for extra things, not for the general budget of the RIPE NCC. Because of lack of time to do extra things, the NCC hadn't invoiced the sponsors yet.

The slides of the presentation are available at the URL

• ftp://ftp.ripe.net/ripe/presentations/ ripe-m21-dfk-NCC-FIN.ps.Z

7. Internet 1996 World Exposition

Carl Malamud gave an introduction on the Internet 1996 World Exposition that is to be held during the whole year of 1996 on the Internet. It will be in the spirit of the World's Fairs that were held at the end of the 19th century and focus on the Internet and the way that the Internet will affect people's lives.

Carl expanded on the functions of the earlier World's Fairs, which were:

• to educate consumers on the use and possibilities of a new technology;
• to challenge engineers to find new ways to use and things to build with the technology (an example is the Eiffel Tower);
• to give new impulses to industries.

The World Exposition will be held during the whole year. There will be pavilions and activities in various places around the world as well on-line on the internet. In principle, everyone can hire a pavilion.

A few of the pavilions are:

• A Global Schoolhouse pavilion that will contain links to schools that are connected to the Internet;
• An Internet Town Hall, that will be dedicated to finding ways for individuals to participate in the Information society;
• A Toasternet pavilion, that will be aimed at bringing new and unusual devices onto the Internet;
• A Small Business Pavilion aimed at how to bring small businesses onto the Internet;
• A Future of Media pavilion.

A lot of other pavilions from institutions and companies were also mentioned.

There were a lot of Corporate Sponsors already who had committed to giving money and other resources to make this event possible. At the moment of the RIPE meeting, there were 5 countries that had agreed on joining the World Exposition: The US, Japan, Thailand, the Netherlands and the UK. A lot more were expected to follow soon. The organizing committees in the different countries were named, as well as the companies who would form a kind of a 'technical alliance' to make this all possible. European activities would be coordinated by RIPE.

The biggest World Exposition sites would be connected by an 'Internet Railroad': a T3 leased line around the world that would carry data traffic at a certain schedule.

One question that was asked after the presentation concerned the way this whole project was managed. Carl explained that his group of people who were working on it, was a non- commercial research institute. The secretarial work would be delegated to various parties around the world. The research on this project would be done together with the corporate sponsors and other parties involved.

The question came up what would happen with the Internet Railroad after the World Exposition was over. Carl replied that it would not be free anymore to put anything on the line, as it would be during the exposition, but he would try to convince the participating organisations to leave the line and the equipment installed to be used.

8. IETF Report

Joyce Reynolds held a long and clear talk about the last IETF meeting held in Danvers. She gave a comprehensive overview of the structure of the IETF and of changes and things happening in a large number of working groups. She focused on the User Services area where she is actively involved, and the IPNG area. Joyce published excellent, ASCII text, sheets which probably give the best summary of her talk and can be found at the URL:

• ftp://ftp.ripe.net/ripe/presentations/ ripe-m21-jkrey-IETF.txt

9. NSFnet: post mortem & the new world

In her talk, Elise Gerich gave a concise overview of the development and accomplishments of the NSFnet over the years, for which she had many clear slides representing different aspects of the growth of the net. She also gave an overview of the discommisioning of the NSFnet and the problems encountered, which were very small in number.

Afterwards, Daniel Karrenberg thanked the NSFnet for providing routing stability during many years.

10. Working Groups Reports

The chairs from the different 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. At the end of each minutes, you may find questions that were asked by the RIPE21 audience following the reports.

10.1. EOF meeting

Chair: Peter Lothberg
Scribe: Havard Eidnes

10.1.1. Administrivia

Peter Lothberg (PL) welcomed the participants Havard Eidnes (HE) was appointed minute-taker

10.1.2. Previous minutes

PL commented that he had received a minor correction to the minutes, which will be included in the final version. Given that this is a minor change, the previous minutes as included in the RIPE-20 minutes were approved.

PL informed about the next EOF meeting, which will be held in Stockholm just before the next IEPG meeting (which is again just before the IETF meeting). The dates are:

EOF meeting, Friday 14 July, 0930 at KTH, Stockholm IEPG meeting, Sunday 16 July, 0930 at KTH, Stockholm

All the EOF meeting participants were invited to participate in the IEPG meeting.

10.1.3. NSFnet shutdown

Elise Gerich gave a short presentation of "the sequence of events as viewed from Merit". After a meeting at the NSF the shutdown of the peering sessions at the NSFnet attachment points were advanced a week, so that a fallback could be implemented for a (single) week if any problems should arise. NCAR asked for an extension (which was granted), and the ENSS at MAE-East had problems running with the modified configuration, so the turnoff was pushed back from friday to tuesday. At tuesday when the peering sessions were turned off, a single AS (AS 22) was "lost", connectivity was restored for this AS some 48 hours later. Otherwise there were some single-network problems which were dealt with on a case by case basis. Thus, at the 30th of April, a quiet "non-event" happened when the NSFnet routers were turned off.

PL then proceeded to give an overview how ICM was affected by the change. Before the NSFnet shutdown, traffic from ICM to FIX-East averaged 20-25 Mbit/s on average, much of it going to ANS. Since ANS would not be present at FIX-East after the NSFnet service shutdown and ICM was not present at MAE-East+, severe overloading of SprintLink's connection to MAE-East+ was expected if nothing was done. Thus, a new T3 connection from ICM to MAE-East+ was installed, and since the "one week push forward" was done this had to be installed on very short notice. Luckily Sprint managed to install the circuit in time. Later a separate T3 has been added between ICM and the NY NAP at Pennsauken.

PL concluded that the lesson to be taken from the shutdown of the NSFnet service is that turning off a sponsored backbone service and letting the commercial service providers compete on a level playing field actually works quite well and has benefits to the users.

PL also explained the plans for implementing a "Euro-NAP" at the Pennsauken, NY Sprint facility. The Pennsauken installation has better survivability than the MFS facilities in Washington DC, and prices and rack space are both readily available. Due to this facility also housing a US NAP in the post-NSFnet architecture it is a well-suited place to terminate high-speed european circuits.

10.1.4. European GIX deployment

PL claimed that a structure similar to the new US architecture would be highly beneficial for the development of european Internet infrastructure. He presented a list of proposed european *IX point locations:

• Pennsauken, NY, US
• Telehouse, London, UK
• KTH/Tele2, Stockholm, SE
• ? France Telecom / Metropolitan Fiber Systems, Paris, FR
• ? British Telecom, Amsterdam, NL

with the two last ones as more uncertain than the other three. In such an architecture, major service providers need to "touch down" on all the exchange points and can there establish peer arrangements. Service providers not wishing to connect to multiple exchange points typically have to subscribe to some kind of transit service to reach where they want to go.

Also, putting major information servers at or near such *IX points may be an important aspect of optimizing the network usage within Europe.

The ground rules for such an architecture and the specific locations of the *IX points needs to be written down and agreed to by the major players, and this should be done ASAP. PL asked for volunteers at this point, noone came forward during the meeting, though. PL mentioned that there would likely be a meeting in Amsterdam the 6th of June where the providers likely to pull lines to routers placed on the *IX points would be invited.

10.1.5. Service provider interfaces

PL presented a categorization of service provider interfaces:

Type 1: statically routed from the service provider or lives within the service provider's IGP, thus in the same AS as the service provider.

Type 2: single-homed customer using BGP toward the service provider via CPE belonging to service provider but in customer's AS.

Type 3: multi-homed customer, CPE in service provider's own AS, local external BGP peering at customer premises.

Most customers will be in category 1, relatively few will be in category 3. Category 2 is usually not recommended, as it "burns" an AS number. PL commented that that can be fixed by hiding the existence of the AS externally, but this configuration permits to solve a problem where BGP is the appropriate tool.

Also, a definition of where the access point for the service is or can be in each case was presented. The slides from the presentation are available at

• http://www.stupi.se/

under "Peter's opinions", and can be freely copied and used.

10.1.6. Swedish affairs

PL presented some measurement of the performance going to customers of the swedish operators (connected at 64 kbit/s). The graphs showed the result of tallying ping RTTs over 24 hours. PL commented that one particular service provider's rather large variation in RTTs would make TCP behave suboptimally, and that the likely reason would be that the service provider uses Frame Relay for delivering the IP service. In PL's opinion that didn't make too much sense. That particular service provider's packet loss rate was also in the 10% range, whereas the others typically were in the 1% range. When the experiment was repeated from the US, the packet loss rates were in the 15-25% range (ugh!).

PL also showed a graph displaying the growth of the number of new registered domains under .SE -- during the two first months in 1995 there were almost as many new registrations as in the entire year of 1994.

10.1.7. Any Other Business

10.1.7.1. Net 39 experiment

Current predictions are that we will run out of IPv4 addresses by 2018 plus-minus 8 years. This however assumes that the remaining class A address space can be subnetted and doled out to different service providers for assignment to their customers. In order to find and fix any problems in doing this the class A network number 39 has been temporarily assigned for this testing. Every owner of an AS number has the subnet 39..0/24. The assignment is as men- tioned temporary, and lasts until 951131. The point is to experiment without directly involving customers. Currently gated and Cisco code is being tested, Wellfleet was mentioned as a candidate for testing as well.

Keith Mitchell from PIPEX commented that PIPEX has been announcing a subnet of the class A network 9.0.0.0 for some time already (in "production mode"), and the only problem so far was a slight delay in processing of the NACR for the NSFnet service.

The message that multihomed EGP and BGP-3 users will lose out big on this one needs to come out *now*.

A mailing list has been set up to coordinate and discuss this experiment: exp39@isi.edu. Send to exp39-request@isi.edu to join. A hint to Cisco users: do "ip classless" before partic- ipating in the experiment. Some hosts already on net 39 were mentioned:

• anka.stupi.se
• exp39.ripe.net
• postel.wind.surfnet.nl

10.1.7.2. Exchange point meeting

As mentioned above, PL is going to call a meeting for discussing the exchange point architecture and placement for europe on the 6th of June in Amsterdam. (Note: This meeting has been cancelled.)

10.2. Local IR Working Group

Chair: Mike Norris
Scribe: Mirjam Kuehne

10.2.1. Select scribe

The meeting was held in two sessions, on 8th and 9th May 1995. Mike Norris, chairman of the WG, presided. Mirjam Kuehne kindly volunteered to take a record of the proceedings. There were about 110 people in attendance.

10.2.2. Agree agenda and Actions outstanding

Referring to the minutes of RIPE 20, it was noted that all actions for the working group had been completed.

10.2.3. Report from registries

10.2.3.1. Global Registries

Mike Norris reported on a meeting of the three regional reg- istries (RIPE NCC, APnic, InterNIC) held in January 1995 in Amsterdam after the last RIPE Meeting. Mike Norris attended this meeting as a representative of the local IR's in Europe. His report was sent to the local-ir mailing list at 29 Apr 1995. This meeting and another held in San Diego confirmed the good working relations and close cooperation between these registries at worldwide level. Daniel Karrenberg reported that procedures and criteria were being harmonised. The three regional registries are singing from the same hymn-sheet, and contacts between them were being intensified.

10.2.3.2. NCC

Daniel Karrenberg reported on the activities of the RIPE NCC as the regional IP registry for Europe. A big change had been the introduction of a ticketing system to track transactions.

He outlined the formalities this system required of people mailing queries to the NCC and urged all to read ripe-183 where these were documented.

Daniel Karrenberg gave some reasons for the introduction of a ticketing system at the RIPE NCC:

• Since the RIPE NCC receives more and more requests multiple hostmasters work on one mailbox. The ticketing system helps coordinating this activity.
• Sometimes additional information is sent by the requester and not by the local IR that sent the requests originally. Ticketing system helps tracking requests.
• Statistics will be included in the ticketing system that shows how long a request is pending and why. This is not implemented yet.
• Ticketing system can help supporting the model of usage based charging.

Another new procedure has been introduced at the RIPE NCC: the Reg ID that every registry is assigned must be mentioned in every request sent to the RIPE NCC, preferably in the form of X-NCC-RegID: regID. Please read ripe-183 for more details. Currently ticketing is still done by hand, but it will soon be overtaken by a robot. This requires strict adherence to the new formats. If the registry ID is not mentioned in a request sent to the RIPE NCC the ticketing procedure has to be done manually. This will produce delay in processing the request.

A new request can be sent with a new ticket line: NCC#new-request-number This is not specified yet in ripe-183.

Action 21.1 on Daniel Karrenberg
To specify the exact format of NCC#new-request-number and send it to the local IR mailing list.

Details of growth in the activities of the NCC and of the Internet in Europe would be reported to the plenary session.

Daniel Karrenberg reported the current staff situation at the RIPE NCC. He noticed a tremendous increase in number of registries and requests. Unfortunately there is not the same increase in the number of staff. But in June Hatice Kuey will join the RIPE NCC as Junior Hostmaster staff.

10.2.3.3. Reports from Local Registries

No workshop has been organised between local IR's before the RIPE Meeting as usual. None of the present local registries had a report about unusual occurencies in the registries.

Daniel Karrenberg mentioned a problem that occurred with requests from large organisations that had large address space assigned in the past. These assignments were justified by the number of subsidiaries. The address space was meant to be distributed among the subsidiaries. The situation has often changed so that the subsidiaries do not receive address space from the mother organisation and submit requests for address space to local IR's or directly to the RIPE NCC.

Daniel Karrenberg suggested the following procedure: Ask the subsidiary to provide a letter (or e-mail) with a statement that no address space can be received from mother organisation and why. This could help to ask address space back from mother organisation since original conditions are not held anymore.

Daniel Karrenberg said he understands problem for provider to refuse address space to customers but the community needs to avoid that organisations are stockpiling addresses. The RIPE NCC wants to know where addresses are and if they are used. Maybe addresses can be asked back in the future when we run out of address space.

10.2.3.4. Charging for Services

Details of commitments and payments for NCC services in 1995 were circulated. Daniel Karrenberg said that the problem of contributions from EUnet constituents had been resolved. This, together with natural growth in the number of new registries, meant that the current financial position was quite healthy, with 67% of the budget for the year already banked after four months.

Action 21.2 on Daniel Karrenberg
To put billing information in the database.

The meeting discussed charging arrangements for 1996 and subsequent years. In September 1994, the RIPE NCC Contributors' Committee, representing the paying customers, had decided that from 1996 onwards, charging should be related in some way to the volume of service provided. The Committee would meet again in September 1995 to agree on a charging model, which would be prepared by the NCC and discussed on the list beforehand.

It was agreed that the model should be transparent, with subscribers being able to find out what their bills were going to be. Automated transactions would not be counted for billing purposes. The fixed charges for small, medium and large subscribers would probably account for 50% of the budget in order to provide for financial stability and continuity.

Action 21.3 on Daniel Karrenberg and Mike Norris
To draft a recommendation on charging by local IRs until September

The RIPE NCC will restart the publication of Quartely Reports. Production has been simplified.

Questions:

Q: Do last resort registries run by EUnet remain?
A: Yes, but RIPE NCC will watch carefully that addresses are really assigned as last resort.

Q: What is the difference between the prices on the list?
A: Different prices for different sized registries; registries determine their size themselves. The size and the price is published and can be seen and compared by all registries. Size can be changed over the time.

Q: Some registries have higher billing/income than committed. What does this mean?
A: These are new registries and the sign-up fee is added in the income column.

Q: How is the time-permitting procedure working (has it effect)?
A: Is works excellent!

Q: How long is the delay?
A: Technically the RIPE NCC maintains two queues of requests (normal-service queue and time-permitting queue). Hostmasters can proceed with a request in the time-permitting queue when the normal-service queue is empty. This has not happened too often (not at all).

Q: How much resources do referrals to service providers take?
A: The RIPE NCC doesn't advertise itself as such a service and doesn't answer end user questions in general. When the RIPE NCC receives requests for service providers, requester will be pointed to the ip-provs mailing list. We should continue doing this. This does not require too much resources. We don't spend local IR's money to provide consultancy for customers of the competitor.

Q: If RIPE NCC could publish referral information, this would relief the NCC.
A: Referral service is not a problem yet. The RIPE NCC receives 2 of such questions per day. When it becomes a remarkable amount of time, we will find a solution.

Q: Couldn't we take the amount of e-mail messages registry sends to the RIPE NCC as indicator for usage based charging?
A: This is not such a good idea. It discourages registries to ask questions. What, if the RIPE NCC has a question about a request and the registry sends the answer back, should they be charged for this message? No.

Q: Couldn't we improve a model that combines the size of a registry with with the usage? A: This is a good idea.

Q: Couldn't we take inetnum objects in DB as criteria?
A: This could also be a possibility.

Q: What is the current relation between the RIPE NCC and TERENA?
A: The RIPE NCC is still under the umbrella of TERENA. Staff of RIPE NCC is employed by TERENA. But the NCC does all dealings with the registries on its site, apart from the real billing process. We pay 10,000 ECU to TERENA for administrative work. Current problem: TERENA is shrinking, RIPE NCC is growing, problems with hiring more staff.

Q: Can local IR charge customer for their services? If yes, who has implemented it?
A: Yes, local IR's can charge for their services. The RIPE NCC does not know who has implemented it, since no registry informs us about it. Note: It is only allowed to charge for services, it is not allowed to sell address space!
Q1: Should the RIPE NCC publish a document with charging recommendation?
Q2: Should the RIPE NCC publish a list about charging registries?
A1: Yes, some recommendations would be useful: For which services can be charged and for which not; helping with the right language.
A2: No, this is not a good idea. This could be interpreted as selling addresses.

10.2.4. Training

On the last ncc-co meeting it was agreed to produce a training course to help new registries to fulfill their function as Local Internet Registry. This was coppeled with the charging model: New registries pay a sign-up fee that will be used to produce such a course. But while the course were intended primarily to help new registries, "old" IRs were welcome to attend if places were available (those registries that have payed sign-up fee will be preferred). Mike Norris encouraged all registries to avail of this valuable training/ re- training resource for their staff. A lot of procedures and guidelines have changed in the past.

The RIPE NCC has started in March to produce a training course. A project framework has been published to the local-ir mailing list. Some help and input has been offered to the RIPE NCC. Anne Lord and Mirjam Kuehne are running the project. They are currently busy to prepare the course. Please note that they have only two hours per day to do so. The first course will be held at 26 June 1995 and a training guide will soon be published. After this first course, as much courses as necessary will be held. The RIPE NCC is also prepared to give courses abroad, when enough registries come together in one country.

10.2.5. Tools

The monthly host count conducted by the NCC has been further delegated, with sixteen European top-level domains now doing the count locally and making the results available to the NCC.

The NCC had refined existing tools in order to analyse the reverse DNS for IP networks in European blocks. The results showed a very poor picture, with low coverage and lots of errors. People were urged to avail of the tools and to try to improve the situation.

Geert Jan de Groot produced tools that check for errors in reverse delegations and complain if they sustain for a week or more. The tools are available at:

• ftp://ftp.ripe.net/ripe/local-ir/{inaddrcount, revcheck}

David Kessens has written a tool to automate requests for reverse domain delegations. It checks the zone that asks for reverse delegation and produces a fairly long output containing all errors found. The requests sent to the RIPE NCC still contain 70% errors but usually the errors are removed at the second time the RIPE NCC receives the request (that was not always the case in the past). The output that is sent back to the requester helps to correct the request and the zone. The tool is still in the test period at the RIPE NCC. After it is stable, it will be published.

10.2.6. Other Issues

10.2.6.1. ripe-104

Daniel Karrenberg has circulated his draft about VSEs again.

He also reported on the current discussion about address space allocation and assignment procedures: On the IETF it has been agreed to distinguish between two different kinds of address space:

• provider aggregatable address space (PAS)
• provider independent address space (PIS)

Daniel Karrenberg summarized other topics in the current discussion: The exhaustion of IPv4 address space is not the main problem. The main issue is the growth of the routing tables. On average there are 4000 hosts per route. This shows that CIDR works, but still not enough. Some routers begin to fall over. Service Provider and local IR's should only use and assign PAS (see draft from Yakov Rekhter:

• ftp://ftp.ripe.net/internet-drafts/draft-ietf-cidrd- ownership-01.txt)

The current debate mentions sizes of address space for PIS and PAS: smaller and equal than /19 (32 C's): PIS greater than /19 (32 C's): PAS

This discussion delayed the revision of ripe-104.

The providers should decide what prefixes they will route and for what price. It should not be the regional registry's task to make this decision. The registries should clarify the implications of PIS and PAS but not regulate.

Daniel Karrenberg has written a draft that lists the possible implications: If customers receives PAS they may have to renumber when they change service provider. If they receive PIS the addresses might not be routable in the future. There must be a clear contractual agreement between customers and registries, when registries assign PAS. The IANA has been asked to circulate this draft.

Questions, Comments:

Suggestion: RIPE should provide recommendation about prefix length. It is not clear yet where the boundary between PIS and PAS will be (/19?). PAS must be easy to renumber (rather short prefix). But this issue needs more discussion in the Local IR group.

Comment against recommendation: The recommended prefix length will probably change over the time. A recommendation would produce false security. DFK: This has to be clear in the recommendation.

Q: Problem with large multinational organisations that contact varies last resort registries to request address space. A clear statement or recommended guidelines from RIPE is needed.
A: The basic principle is already included in ripe-104: If the multinational organisation is connected only in one place, addresses should be received from this one service provider. If the multinational organisation is connected in varies places/countries it should receive address space from these different service providers. The problem is rather that it is easier for these organisations to ask for small amounts of address space at different registries than for a large amount of address space at one place. It is easier to provide an addressing plan for small parts of a network than for the whole network. There is no clear procedure how this can be prevented apart from being careful and asking carefully for detailed documentation.

Q: Can't the RIPE NCC make a clear recommendation that these kind of organisations should contact the RIPE NCC for address space?
A: There are clear guidelines in ripe-104:
4. Organisations operating a network which spans several countries may obtain address space from a service provider, the RIPE NCC, or the global NIC, as is appropriate to their network configuration. In many cases it will be best to obtain addresses for the whole network from the provider operating the main connection of the multi-national network to the Internet. When in doubt, contact the RIPE NCC for guidance.

10.2.6.2. DB issues

On the last RIPE Meeting it has been agreed that the technical contact in an object can also be a role, e.g. a NIC instead of a person. Harvard Eidnes has written a draft about this issue and circulated to the local-ir mailing list in advance to the 21. RIPE Meeting.

10.2.6.3. Reverse Domains

The group endorsed the recommendation of the DNS WG that the reverse domains of connected IP networks be name served.

Action 21.4 on Mirjam Kuehne and Anne Lord
To incorporate strong recommendation regarding reverse DNS in training materials.

10.3. DNS working group

Chair: Leonid Yegoshin
Scribe: Leonid Yegoshin

We discussed agenda points in reverse order due to chair initiative. Leonid Yegoshin proposed to speak about new topics before old ones.

10.3.1. Mail routing & DNS - what about network load balancing?

Leonid Yegoshin gave a short introduction about network resource load balancing. The primary purpose of it is to diminish load on server hosts and decrease network traffic. Also it is very unlikely that mail from one internal host to another internal host going to neighbour organisation or just country follow a MX record set of destination point. There are some activities to split the load on network resources:

• use round-robin in DNS answers (BIND 4.9.3)
• use short TTL of A records with recalculation of hosts load (see RFC 1794) - use separate sets of name servers for internal and world nets with different representation of DNS tree.

Leonid Yegoshin described yet another decision for network resource load balancing and gave a short overview of experi- mental version of RU-BIND with "region" Resource Records. This approach is based on diversity of source IP addresses of DNS requests and description CIDR-syntax net regions in DNS zone.

At this point there was some discussion about problems and dangers of this approach. One question was about caching RRs in high level name servers. Answer was that there is TTL=0 which don't cached but used an any way. Another question was about multiple RRs and their combination in regions. There is the difference in security goal and load balancing - it is not a way to hide some RRs due to forwarder use. Dmitri Sidelnikov said that it is very dangerous approach - it can increase chaos in Internet and debug problems. Leonid Yegoshin lets take in attention that DNS UDP packet size limit is too small to transfer "region" RR of some providers and can be increased for it. Moreover XFER of "regions" require to change XFER format.

Carl Malamud suggest Leonid Yegoshin to write RFC draft about it. This suggestion was supported by Rob Blokzijl.

Leonid Yegoshin's final question "how many providers are interested in network resource load balancing" remained without a definite answer but there was opinion that it will be interesting.

10.3.2. DNS & network security (incl DNS security itself)

The question "why is it needed?" was clear. Commercial server providing require the reliable check of client source domain name (as another information in DNS). No objection was against this point expounded by Leonid Yegoshin. Now there are three ways to check it:

• reverse domain check. It is very popular but in the general case it is very simple to crash by experienced hackers. Moreover it is crashed time-to-time by some BIND bugs.
• Source Responsibility Check (in RU-BIND, ftp://ftp.kiae.su/) or VALIDITY option in BIND 4.9.3. It accept RR's the only from responsible name server, not from arbitrary source. It is powerful feature but unfor- tunately it is not work (yet?) in 4.9.3 - some comment exists that VALIDITY is not fully debugged. And it can't protect packet spoofing.
• cryptographic sign of DNS exchange. There is RFC draft from DNSSEC WG of IETF for it.
• Some discussion was started from this point about situation in different countries with cryptography and electronic sign.
• Russia (Dmitri Sidelnikov, Leonid Yegoshin cont.) Forbidden by default, but license can be obtained from government body. Unfortunately it is already clear that the only methods from Russian FAPSI would be licensed (FAPSI is Federal Agency for Government Communication and Information). There is the difference between encryption and electronic sign in FAPSI policy, but it is unclear yet. Also the reality is the only FAPSI meth- ods would be used as proof in court - all cryptoanalitic experts are FAPSI experts.
• NL (Rob Blokzijl) - draft to forbid it was rejected now.
• France (Francis Dupont) - forbidden. Electronic sign is legal only after announcing the partner's name for message exchange.

No proposal or decision for Europe was made yet about DNS electronic sign. It is obvious that this is a very difficult political problem. I think that additional mail discussion is needed about the situation. Also it is important due to IPv6 authentication & encryption options.

10.3.3. What is need to keep in RIPE DB about DNS?

There was not very much discussion about this agenda point. There is the objection against keeping information in two places - RIPE DB and DNS. Moreover Piet Beertema has the strong objection against holding any information about DNS in RIPE DB which was repeated in his mail to dns-wg after WG meeting. Nobody insisted on holding it there. After a short discussion on how to find the phone/fax and other in DNS tree (TXT records was again proposed for that), David Kessens mentioned that offered to propose "something" about distributed access to info (in offline, after meeting). Nobody said anything about separating the organisation and interorganisation domains.

10.3.4. Other topics

What about primary/secondary disposition ?

• Net failure & DNS
• where is the level of backup,
• What connectivity lost is essential for the European nets?

These topics were discussed together due to lack of time. France, and sometimes others, meet strange problems with the root name server access from time to time. Discussion about influence of short UDP packet size problem and long root DNS list started. Carl Malamud said what root name servers are need to re-establish near *IX and it can help the problem.

Leonid Yegoshin proposed to investigate problems with DNS failure to find the reasons (by himself) in offline. Any provider who has unexplained DNS problem is suggested to contact him about study.

Action 21.5 on Leonid Yegoshin
To investigate reported DNS failure problems

10.3.5. After WG meeting

Some talks at lunches found yet another problem with current DNS in CIDR environment - reverse domains for Very Small Enterprises. Now in-addr.arpa standard has minimum 256 hosts in a single zone, and it is an uncomfortable maintenance with VSE. If DNS would be changed some way can be found to decide this large limit.

10.3.6. After the presentation at the plenary session

Dimitri Sidelnikov suggested that compatibility among old and new software was needed, as it is unwanted to have two competed system. Leonid Yegoshin replied that this certainly was true. The topic would be discussed further on the dns-wg mailinglist.

Peter Lothberg warned that for a new version of the software there would be no apllication support, which would create quite a mess. Rob Blokzijll replied that this was not true because of compatibility with the old software.

Wilfried Woeber stated that it was desired to make reverse DNS classless. The lively discussion on how to do this became too much focused on detaills and was cut off.

10.4. Database working group

Chair: Wilfried Woeber
Scribe: Wilfried Woeber

10.4.1. Administrative stuff

Unfortunately nobody volunteered to take the minutes. I had to guide the discussions and to take the notes at the same time. Thus these minutes are probably not as comprehensive as we are used to. Apologies.

The agenda was accepted as proposed, without changes.

10.4.2. DB-SW review

David Kessens, RIPE NCC, reported on the current state of the database software and the environment at the NCC for providing maintenance and doing development work.

Activities since RIPE 20 (as Marten and Tony having left the NCC/PRIDE Project) centered on becoming familiar with the software, performing bug fixes and implementing minor extensions, like the "network update" feature whois -U and whois -tv (for template verbose).

Other aspects worth mentioning:

• reverse lookup technology
• hierarchical authorization (initially for domains)
• referrals are being researched and estimates for the necessary implementation efforts are obtained.

David confirmed that the official distribution kit available (anonymous FTP) at the NCC always contains the most recent fixes issued and additions.

For more details please refer to the slides supporting David's presentation which are available from the RIPE NCC FTP Server in the presentations directory

• ftp://ftp.ripe.net/ripe/presentations/ ripe-m21-david-DB-REPORT.ps.Z

Merit is also working on the database software and has produced some tools. These things are available from:

• ftp://ftp.ra.net/routing.arbiter/tools/ RAToolSet

10.4.3. Security

While there was no concern regarding the functionality and usefulness of the authorisation methods already implemented (mail-from:, crypt-pw:) there is a need for even stronger authentication of updates.

PGP seems the way to go, although there is still quite a bunch of open questions and a need for logistic (e.g. key distribution) development. It is not clear at the moment whether this should be integrated (DB, RIPE NCC) or be provided by mechanisms outside the scope of RIPE.

SURFnet reported its intent to use the RIPE-DB for routing configuration as soon as PGP would be available to provide the data reliability necessary. Others expressed strong interest as well.

Merit (LJ) did part of the work already to provide PGP autho- risation for the email addresses in updates.

Comments from the group stressed that it is essential to *not* mix the concepts of authentication and of encryption. Encryption is a logistic and/or legal problem in some regions.

The group is requested to pursue this aspect on the relevant mailing lists.

Action 21.6 on David Kessens and Wilfried Woeber
To investigate the deployment of PGP for the RIPE Database and to draft a proposal.

10.4.4. Review of beta test for RIPE-Handles

The method for generating RIPE-Handles was discussed once again. There are still open issues when trying to fully automate handle assignment because this would require both a DB-commit function as well as require the modification of submitted objects on-the-fly. The group did not resolve this issues, thus the current procedure (finger) remains in place.

It was noted that the scripts involved should be made available to all interested parties.

10.4.5. External interfaces

There is an ongoing discussion (in the light of more than one organisation using the RIPE DB-SW now) on how to keep the various databases in sync. One of the ideas is to accept updates for each and every database on all interfaces, to analyze the "source:" attribute and then to automatically forward the update to the database as indicated by "source:". While this is probably quite interesting, it might not always be what the users intend.

The alternative is to reject updates when submitted for the "wrong" "source:". This is the safe way.

To meet the need of regularly transferring updates from one database to (an)other(s), a method using FTP and providing "deltas" is investigated.

10.4.6. Input for and review of objects

Due to the scheduling of the working groups, there was no input at the DB-WG meeting.

A proposal to expand the internet-router object to describe Mbone routing was circulated after the meeting, as drafted by the Mbone WG.

10.4.7. AOB

None. Thus the meeting was closed.

10.4.8. After the presentation at the plenary session

With reference to the projects mantioned earlier, Rob Blokzijl noted that if people from the RIPE community came up with defined project, funding could probably be found for them.

10.5. Routing working group

Chair: Willem van der Scheun
Scribe: Anne Lord

10.5.1. Opening and agenda bashing

Willem v.d. Scheun opened the session and welcomed everyone to the meeting. The agenda was agreed with some scheduling changes which will be reflected in the minutes.

10.5.2. Minutetaker

Anne Lord volunteered to take the minutes.

10.5.3. Status of the Route Arbiter project, Elise Gerich, Merit

10.5.3.1. PRDB -> RADB transition

There was much discussion during and following Elise's presentation. The main points are:

• May 8th (day of WG meeting) is the last day that NACRs will be accepted by Merit. After this date, old style NACRs will automatically be translated into ripe-181 compliant route objects.
• If you have registrations in the PRDB your data will automatically be converted.
• If you require connectivity to AS690 you will need to register your route in the RADB using the "advisory" tag, as AS690 config files are currently generated from the RADB only.
• The "advisory" tag replaces the old-style NACRS but will be short term only. The end of May was mentioned as the "short-term".
• Global IRR schema means that registering in one RR should be sufficient. However, registering in more than one database will be allowed but not encouraged. The problem of determining priority when there are conflicts in Routing Registry data is still not solved.

A question was asked concerning how to remove duplicates once the priority issue was resolved. There was some discussion, but the problem has yet to be resolved.

10.5.3.2. RA Project

The project began on July 1st, 1994 as collaboration between Merit, ISI (and IBM). ISI and IBM are responsible for the software development of the Route Server and advanced protocol development. Merit is responsible for development and maintenance of the RADB, network management and routing engi- neering. Current status:

• 6 route servers (RS) are deployed:
• 2 Mae East o Sprint NAP
• Ameritech
• PacBell o Mae West (not fully operational)
• The main interconnection-point effort is focussed on Mae East.
• 15 ISPs present
• 11 peering with primary RS and backup
• 6 import and exporting routes from RS.
• none is yet fully dependent on RS.
• only problems reported have been from Sprint.

Elise reported that for the last 10 months RSes have been operational, although the fact has not been communicated since more network management tools were needed and the NOC does not yet have out of band access to the RSes.

• Network Management Area development
• deployed bi-lingual SNMP agent v.2 o Discovery Rover code - reports on state and topology of net.
• NOC formerly ANS, now Merit, University of Michigan.
• RADB is implementation of ripe-181. Some extensions to the syntax were necessary. Specifically there are now attributes:
  • extended-interas-in
  • extended-interas-out
• PGP v.2.6 email authentication added. Development work done by Laurent Joncheray. Description of the mechanism can be found at:
  • http://www.ra.net
  • ftp://ftp.ra.net/routing-arbiter/tools/RAToolSet
• Software development by Cengiz Alaettinoglu on tools that generate config files for ripe-181 policy expressions. Tools are (available from above URLs):
  • rtconfig
  • toolkit

There was a question concerning duration of project and available resources. The RA project is a 5 year project which will terminate in 1999. 14 people are working on the project. All the software is public domain.

10.5.4. NCC Report on the population and usage of the RR

• Maintainence of the RR is a RIPE NCC core activity.
• Little time for actual work to date - current resources are 1 hour per day from Mirjam Kuehne and Anne Lord.
• 3 stage working plan developed based on BGP dump of amsterdam.ripe.net
• chase non-registrations of ripe-181 policy of EU ASes -> nag.
• extract AS path and compare with registered policy -> nag.
• develop tools to do above work auto-magically

Comments:

• Question concerning the consistency of route objects and the home AS. Is this part of the RR activity? Answer was yes, but focus of effort prioritised to above.
• Registering in the RIPE RR is vital. When "advisory" tag goes away, some EU networks not registered may lose some connectivity.
• Ideal end state is to register in one RR only. This should be sufficient for full connectivity.
• Should be free (but not encouraged) to make multiple registrations. Currently some RRs require this (MCI & RADB). Seen as short-term (+/- 2 weeks). Advice for now is to make multiple registrations.
• Currently RRs mirror each others databases. RIPE NCC will monitor dual registrations.

10.5.5. Routing Policy System (RPS)

Importance of ripe-181 acknowledged as document has become informational RFC: rfc1786.

IETF working group formed

• rps
• Charter
• to develop a routing policy description language based on ripe-181.
• to co-ordinate efforts of various RRs
• Co-chaired
  • Cengiz Alaettinoglu
  • Daniel Karrenberg.
• Mailing list established.

10.5.6. CIDRD wg report (Danvers IETF)

• ALE wg merged with CIDRD
• ALE is now 2018 +/- 8 years
• Analysis of address space utilisation was presented. Stats were taken from amsterdam1.dante.net. Figures showed that in 193/194 blocks there was an average of 4,000 hosts per route. CIDR works!

Routing table growth slowing down. Chief problems now seen to be route update processing and flapping.

• Yakov Rekhter presented paper which will soon become Internet Draft
• "Address Ownership Considered Fatal"
• Paper discusses problems arising from portable address space. All ISPs encouraged to assign only "provider aggregatable" address space. "Provider independent" address space assigned by Regional Registries will offer no guarantee of routability. (will be determined by ISPs - some of whom claim to be filtering on longer prefixes.)

Trade off between renumbering to ISP block when you move provider or paying for ISP to route your prefix. Uncertain how this will develop.

Daniel Karrenberg asked for European input to document, which is vitally important.

• rfc1597 stands and is on standards track. Comments in rfc1627 will be incorporated.

10.5.7. After the presentation at the plenary session

Daniel Karrenberg noted that the registration in muntiple databases would only be necessary for the coming weeks.

Peter Lothberg gave the warning that only /15 and bigger blocks would be accepted. Daniel noted that this was only a proposal from the big providers that would not be likely to make it. Peter replied that IPv6 is even worse than this scheme.

There was a question from Wilfried Woeber if there was going to be some kind of a 'cookbook document' on where to register what information. Daniel replied that the cookbook would be: only register in one database. The answer to Wiefrieds question of data is copied between different databases was negative.

Erik-Jan Bos asked for the reason of a transition phase in the RA project, to which Elise Gerich replied that there was more inconsistent data in the database.

10.6. MBONE Working Group

Chair: Erik-Jan Bos (EJB)
Scribe: Christian Panigl (CP)

10.6.1. Opening, welcome, administrativa, agenda bashing

EJB was greatful to Christian Panigl of ACOnet for taking the notes.

10.6.2. European Mbone FAQ

EJB announced a new location for the European Mbone FAQ in

• http://www.nic.surfnet.nl/surfnet/persons/bos/mbone/

containing pointers to related documents, security hints, bugs & workarounds, tools (monipm, tcpdump 3.0). EJB will add some items to the FAQ in the near future. Hints for items to include are welcome.

10.6.3. Mapping aka The European Mbone topology

There is a new European Mbone map made by Herman van Dompseler at:

• http://www.nikhef.nl/www/pub/ teleconferencing/home.html

This map can also be accessed through the European Mbone FAQ home page.

10.6.4. Multicast Mbone Router data base proposal

EJB presented an abstract of his paper "A Multicast Router in the Routing Registry".

After some discussion about the proposal of adding a new attribute "mpeer" to the "inet-rtr" object a more generic use of the existing "peer" attribute was preferred. To be as flexible as possible Geert Jan De Groot (GJDG) made the following proposal:

peer: DVMRP version

Example: peer: DVMRP isi-3.5 ...

The should hold the implementation-dependent config line. This has to be fine-tuned how to handle multilines.

There were some side-steps during the discussion:

Peter Lothberg (PL) asked:

How to document PIM-RendevouzPoints?

How to document/specify Multicast Topology?

How to document/specify routing between PIM clouds?

It was decided to send a requirement wishlist to the IESG (volunteers EJB, PL)

10.6.5. New technologies

10.6.5.1. IGMP over ATM

There is an Internet draft: draft-ietf-farinacci-igmp-over-atm-00.txt which is not (yet?) in the Internet Drafts directory but was sent over the TERENA ATM-TF list. The TERENA ATM-TF is looking at this.

Topic postponed to next meeting (EJB tries to get a tutorial on this from Victor Reijs (VR).

10.6.5.2. PIM presented by Havard Eidnes (HE)

PIM = Protocol Independent Multicast Routing Protocol

• uses unicast forwarding table (topology must adhere to unicast routing)
• two modes:
  • dense-mode: flooding, simple
  • sparse-mode: explicit "join" has to be sent to "Rendevouz Point" to attract traffic
• loop avoidance: RPF lookup

Why PIM?

• scalable
• sends traffic only on request (sparse-mode)
• integrated

Practical PIM:

• early code: Cisco 10.2 (gated on the way)
• "rumors" about bugs (memory leak ?)
• performance (slow switched) (Cisco 10.4 expected to add fast-switch support)
• DVMRP interaction: take care, use access-list to redistribute routes
• PIM cloud off DVMRP OK
• DVMRP off a PIM cloud is at least problematic

Config examples:

PIM-only (simple):

ip pim rp-address d.d.d.d ip multicast-routing ! interface ether0 ip pim sparse-mode ! interface fddi0 ip pim sparse-mode !

PIM/DVMRP interworking router:

ip pim rp-address d.d.d.d ip multicast-routing ! interface tunnel1 ip unnum fddi0 ip pim sparse-mode ip dvmrp metric 1 2 !!! 2 = access-list !!! classfull !!! tunnel source fddi0 tunnel destination e.e.e.e tunnel mode dvmrp ! interface ether0 ip pim sparse-mode ! interface fddi0 ip pim sparse mode ! access-list 2 permit ...

10.6.6. AOB

10.6.6.1. Stockholm IETF

There will be a 34Mb link between Stockholm and US; Mbone-structure has to be rebuilt for IETF (volunteers: Lars-Johan Liman, GJDG, EJB). They will come up with a proposal on the mailing list.

10.6.6.2. ATM-TF (Terena) presented by Michael Behringer

using Mbone to put load on ATM network; nothing should leak out; EJB: get in contact with VR

Summary of Action Items:

Action 21.7 on Erik-Jan Bos
To make the new Mbone-FAQ available (with pointer to the new Mbone map)

Action 21.8 on Erik-Jan Bos, Peter Lothberg
To generate a requirement wishlist wrt. multicast rout- ing features and send it to the IESG.

Action 21.9 on Erik-Jan Bos (Wilfried Woeber)
To update the proposal "A Multicast Router in the Rout- ing Registry"

Action 21.10 on Erik-Jan Bos
To get in contact with Victor Reijs for a tutorial on "IGMP over ATM" and the Terena/ATM-TF

Action 21.11 on Lars-Johan Liman, Geert Jan De Groot, Erik-Jan Bos
To redesign Mbone structure for the Stockholm IETF

10.6.7. After the presentation at the plenary session

Wilfried Woeber asked if there was no overlap in activities of the MBONE working group and the ATM task force. EJB's opinion was that that this was not really the case as the ATM task force focuses on a more selected group of people.

11. Next RIPE meetings

The scheduling of the next meetings was discussed and the following dates and locations were agreed:

• RIPE 22 - 11-13 October 1995 - Amsterdam, NL
• RIPE 23 - January 1996 - Amsterdam, NL
• RIPE 24 - May 1996 - Berlin, Germany

12. AOB

None.

13. Closing

Rob Blokzijl thanked the participants for attending, GARR/NIS for organising the meeting, UNINET for providing the terminal facilities and CNR for providing the room facilities and lunches, and declared the meeting closed.