1.1. Welcome
Rob Blokzijl welcomed the participants to the 21st RIPE meet- ing 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
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 Con- tributors 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
Daniel Karrenberg presented the RIPE NCC Report. The statis- tics 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 Reg- istries 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 com- prises 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 Reg- istry' 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 initia- tives 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 actu- ally 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
o ftp://ftp.ripe.net/ripe/presentations/ ripe-m21-dfk-NCC-REPORT.ps.Z
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 expendi- tures 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 men- tioned in the NCC activity plan. However, the billing sched- ule of 1996 would still have to be decided upon by the con- tributors 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 spon- sors. 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
o ftp://ftp.ripe.net/ripe/presentations/ ripe-m21-dfk-NCC-FIN.ps.Z
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 princi- ple, 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 busi- nesses 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 com- mitted 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 compa- nies 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.
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
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 encoun- tered, which were very small in number.
Afterwards, Daniel Karrenberg thanked the NSFnet for provid- ing routing stability during many years.
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 configura- tion, so the turnoff was pushed back from friday to tuesday. At tuesday when the peering sessions were turned off, a sin- gle 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" hap- pened 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 installa- tion 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 termi- nate high-speed european circuits.
10.1.4. European GIX deployment
PL claimed that a structure similar to the new US architec- ture would be highly beneficial for the development of euro- pean Internet infrastructure. He presented a list of pro- posed 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 sub- scribe 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 configu- ration permits to solve a problem where BGP is the appropri- ate 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 sub- optimally, and that the likely reason would be that the ser- vice provider uses Frame Relay for delivering the IP service. In PL's opinion that didn't make too much sense. That par- ticular 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: [email protected]. Send to [email protected] 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 dis- cussing 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 proceed- ings. 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 reg- istries 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 organisa- tion 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 reg- istries, 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 sub- sequent 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 sub- scribers 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 bud- get in order to provide for financial stability and continu- ity.
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; reg- istries 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). Hostmas- ters 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 con- sultancy 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 charg- ing? 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 TER- ENA? 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 reg- istry 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 rec- ommendation? Q2:Should the RIPE NCC publish a list about charging reg- istries? A1:Yes, some recommendations would be useful: For which ser- vices 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 train- ing course to help new registries to fulfill their function as Local Internet Registry. This was coppeled with the charg- ing 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 pro- ject. 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 contain- ing 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:
Daniel Karrenberg summarized other topics in the current dis- cussion: 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 con- tact 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 care- ful 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 appro- priate to their network confi- guration. In many cases it will be best to obtain addresses for the whole net- work 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 techni- cal 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 ini- tiative. 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:
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 with- out 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:
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 men- tioned 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 com- peted 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 provid- ing 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 imple- mentation 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
o ftp://ftp.ripe.net/ripe/presentations/ ripe-m21-david-DB-REPORT.ps.Z
Merit is also working on the database software and has pro- duced 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 pro- vided 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 auto- mate handle assignment because this would require both a DB- commit function as well as require the modification of sub- mitted 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 avail- able 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 Blokz- ijl 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 pre- sentation. 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. Objects should be sent to :
- 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.
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 proto- col development. Merit is responsible for development and maintenance of the RADB, network management and routing engi- neering. Current status:
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.
http://www.ra.net o ftp://ftp.ra.net/routing-arbiter/tools/RAToolSet
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
Comments:
10.5.5. Routing Policy System (RPS)
Importance of ripe-181 acknowledged as document has become informational RFC: rfc1786.
IETF working group formed
Routing table growth slowing down. Chief problems now seen to be route update processing and flapping.
Trade off between renumbering to ISP block when you move provider or paying for ISP to route your prefix. Uncer- tain how this will develop.
Daniel Karrenberg asked for European input to document, which is vitally important.
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 ques- tion of data is copied between different databases was nega- tive.
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
o 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 fol- lowing 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 multi- lines.
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 direc- tory 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 "Rende- vouz 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 redis- tribute 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.
The scheduling of the next meetings was discussed and the following dates and locations were agreed:
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.