RIPE 20 Minutes

1. Opening

1.1. Welcome

Rob Blokzijl welcomed the participants to the 20th RIPE meeting hosted by NIKHEF in Amsterdam, The Netherlands.

Rob announced that this would be the first meeting in a new different format:

The working group meetings were held before the plenary session. More than one working group meeting could take place simultaneously. During the plenary session, the chairmen of the different working groups would (still) give reports of the working group meetings.

1.2. Apologies

Apologies were received from the following persons:

Erik-Jan Bos (SURFnet)
Thomas Jacobson (Internet-Way, a new ISP in Paris)

1.3. Papers tabled

Agenda for the 20th RIPE meeting
Working Group Agendas - one document
List of Participants of the 20th RIPE meeting
RIPE NCC report - Daniel Karrenberg
RIPE NCC Financial Status and Billing Procedures - Daniel Karrenberg

2. Agenda

The agenda was approved. Note: some of the agenda items were rescheduled during the meeting but they are minuted as originally scheduled.

3. Minutes of the last meeting

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

4. Review of the action list of the last meeting

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

Action: 17.7 Wilfried Woeber, NCC
To produce the necessary documentation for the new DB software.

Action: 19.6 Geert Jan de Groot
To document new attribute "status" proposed to describe whether a network is delegated, reserved or assigned.

Action: 19.7 NCC
To circulate the revised ripe-115 to the local-ir list for comments.

Action: 19.10 Erik Jan Bos, Wilfried Woeber
Written proposal to extend the "inet-rtr" object ready before RIPE 20.

Action: 19.11 NCC
To propose new domain object for in-addr.arpa

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

Action: 19.14 Erik-Jan Bos
To write a short document describing how to use the rtr-obj to describe location of m-routers.

5. RIPE NCC Report

Daniel Karrenberg presented the RIPE NCC Report. He showed that the growth continues. The correlation between the number of DNS hosts and the parallel growth of the number of registries seemed not to have changed. This means that there will probably be at least 240 registries at the end of 1995. The new registries need more support and guidance than those having a long Internet history. They are now a significant load factor just to get them started on the registry procedures. But they provide more income!

The situation is still close to getting out of hand, but improving. For the registry functions, 37 messages a day are received and the 'ncc' mailbox receives 41 messages a day. More than 50% of these messages are routine questions, this means there is a large risk of the staff burning out. But Daniel was a little bit more positive about the current work load situation then last time. The situation is still bad, and backlogs in the hostmaster queue continue, but there are some signs of a better situation.

By appointing a new administrative staff member (David Kessens), a promotion of Mirjam Kuehne to the technical staff and a conscienscious objecter, Roderik Muit, who is now working for the NCC, there is now more personnel available. However, Marten Terpstra will be missed, who is leaving the NCC after the PRIDE project has been finished. The personnel resources still lag behind for what is actually needed, since this was the number of people needed last year. A result of this is that it is still not possible to do everything that should be done according the RIPE NCC Activity Plan.

For the coming period it is planned to develop training and documentation for new registries. Furthermore, a ticketing system will be introduced to keep better track of the larger number of requests we expect. The billing procedures will be streamlined to make less errors and to keep up with the larger number of registries and also a new charging model for 1996 should be developed. The Quarterly reports will be restarted in a new revised format but the most important thing to do is still trying to keep up with the growth.

After the report there was room for asking questions.

Julia Hendler issued a question about resolving the NCC's staffing problems. Daniel answered that something could most probably be done about that once the financial situation was stable. At the present time, 20% of the NCC expenditure budget was confirmed. There was hope that 100% would be covered soon and at that time the RIPE NCC would be able to hire more staff.

Mike Norris addressed the issue of continuation of the hostcount. He requested that different countries should do their own hostcounts; this would be easier for the NCC to collect all the data. Rob Blokzijl encouraged the audience to do the hostcount locally. Blasco offered to do this for Italy.

Action: 20.1 Mike Norris
To flag those countries who could do their own hostcounting to the NCC.

The slides of the presentation can be found at:

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

6. RIPE NCC Finances

Right after the report, Daniel did a short financial report. There was no agreement reached on the funding model for 1995, despite several efforts by TERENA and the NCC. However, consensus was reached that the 1996 funding model should be more usage based and the NCC committed to develop alternatives by mid-1995.

A conservative budget of ECU 407500,- compared to the ECU 245000,- of 1994 was presented. Furthermore a summary was shown of the revenue situation as of January 23rd. 70% of the budget was confirmed informally (E-mail, phone) and 20% was actually secured by getting a formal commitment.

Starting February 1st, the RIPE NCC would process requests from contributing registries before those from non-contributing registries and individuals. This is necessary to ensure that those contributing to the costs of the service are not suffering from the load generated by those that do not contribute.

Requests receiving "normal service" will be processed in the order of receipt of the request at the NCC as usual. It is aimed to reply to these requests as quickly as possible.

Requests receiving "time permitting" service will be processed only when there are no outstanding "normal service" requests and other NCC core activities permit. The NCC may also interrupt processing of a "time permitting" request should a new "normal service" request arrive.

Until February 28th, all who had formally confirmed that they are willing to contribute to the RIPE NCC finances would be served as though they have officially committed.

More information regarding the new charging scheme can be found in:

ftp:/ftp.ripe.net/ripe/new-registry

Conclusions:

With the signed commitments, the expenditure budget of the NCC has to be covered soon. If this is not reached, the expenditures will have to be cut down.
The NCC is still overloaded.

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

Milan Sterba asked if there would be any differentiation of the NCC service level between organisations contributing fully, and those contributing less than estimated. Daniel answered that there were no plans to do this, but this discussion should be held in the ncc-contributors mailinglist. It was not up to the NCC to make their own decisions on this. So the only criteria for the level of NCC services would be if an organisation was contributing or not.

Rob Blokzijl noted that in the future, a system of usage based charging would be put into action, so this was a temporary solution. The matter was referred to the contributors list, because the audience present could not solve this matter.

Daniel Karrenberg noted that a list of contributors would be published.

A question was asked if the US providers would have a competitive advantage, since the InterNIC services are funded by the government. Daniel answered that this situation is not going to last forever.

The question came up how the NCC was going to implement the priority difference, i.e. regarding to telephone calls. The answer was that most queries are not answered on the phone, if they can be issued by fax or e-mail. For faxes and e-mail there would be different queues for contributing and and non-contributing members.

Juergen Rauschenbach proposed that the NCC should develop a few models of charging to present to the NCC contributors list. One of this models could be the German DENIC funding model.

Milan Sterba suggested that the NCC contributors should find out how to sponsor requests from developing countries. Daniel responded that he would bring cases with merit to the attention of the NCC contributors.

The financial report is available at:

ftp://ftp.ripe.net/ripe/presentations/ripe-m20-dfk-NCC-finances.ps
ftp://ftp.ripe.net/ripe/presentations/ripe-m20-dfk-NCC-finances.txt

7. Joint Projects: PRIDE Final report

Marten Terpstra held the final report presentation of the PRIDE project. The main objectives of the PRIDE project were to provide tools that make use of a Routing Registry, to provide information about the routing registries, and to coordinate with other routing registries.

The PRIDE tools were released in two stages. Most of the tools are ready to use now, although prconn and prconfig are not finished due to changing requirements (CIDR) and time constraints.

Information about the routing registries was provided by the PRIDE guide which gives information about how to register in a routing database and how to use the information in the database. Furthermore 1 day courses were given for internet service providers focussed on the use of the tools and the Guide. The courses did receive very high satisfaction rates.

As part of the coordination effort, the ripe-181 document is now generally accepted as "de facto" Routing registry standard. Many people are now using ripe-181 and the ripe database software. Many other routing registry projects were started in various places. The PRIDE project team tried to keep close contact to these groups and to try to develop one standard.

The project was done by Tony Bates, Marten Terpstra and Daniel Karrenberg (30%) during one year, and was funded by Joint Network Team, UNINETT, UUnet Technologies Inc., EUnet BV and RENATER.

It was possible to ask questions after the presentation.

Antonio Blasco Bonito asked if Marten could give some keywords to what prconfig is supposed to do. Marten answered that the objective was that prconfig makes (currently) in a very crude way a CISCO/gated working set.

Mike Norris said that Marten could be proud on what he made of this project. Hereafter he asked what happens now regarding to the continuation of the project. Daniel answered that this is part of the Routing Registry maintenance activity, which is now part of the RIPE NCC activity plan. Furthermore he asked everybody to report bugs.

Rob Blokzijl asked if Marten had suggestions for a PRIDE-2 project and if there was a task here for the routing working group. Marten replied that they could be more involved in the architectural problems.

8. Regional Registry Reports

8.1. INTERNIC report by Mark Kosters

The talk of Mark Kosters was more or less a summary of the presentation given by Kim Hubbard for the local ir working group. See more details in the working group reports 12.1.3.1.

8.2. APNIC report by David Conrad

David Conrad gave a presentation on APNIC. First he told about the historically grown situation that there were already several NICs in certain countries. Also, the language and cultural differences asked for a more distributed approach. Since APNIC runs on a small budget and saw the problems of the other regional registries there was another incentive to not go for a centralized model but to use a system of NICs in every country.

APNIC is now run on a part-time (40 hours a week!) basis by David. The rest of his time he works at one of Japan's service providers. He told that currently the situation regarding to networking in the Pacific area is still behind North-America and Europe but grows with a fast pace.

9. TERENA

Steve Druck started his introduction with announcing the JENC6 (6th Joint European Networking Conference) with the theme "Bringing the world to the desktop", to be held may 15th-18th in Israel. The conference will focus on the increasing penetration of networking in the daily research and educational practices and the underlying technology and infrastructure needed for this.

He then talked about TERENA's activities. The activities of both RARE and EARN would continue under TERENA. The GUM NCC (former EARN activity) and the RIPE NCC were mentioned as examples.

In the services area TERENA can sometimes act as a service provider, e.g.:

for a project which is a general service to some community, and there has been no other service provider identified.
when services evolve from a voluntary basis of coordination efforts
when neutrality is necessary

After this, Steve mentioned the possibility that a new CERT coordination center could develop into a TERENA service, but he stressed that that did not mean he wanted to take this project away from someone else.

Rob Blokzijl asked if this was a solicitation for a CERT coordinated by RIPE. The answer was that it could be, if the RIPE members reached a consensus about this. Rob asked all participants if they had anything to say about the CERT coordination effort, since he didn't hear any reactions (yet).

Mike Norris commented that it was clear that the conclusion was that RIPE supports TERENA in their view. Steve answered that that was not so clear and asked for a proposal to evaluate the setting up of a CERT service.

Rob Blokzijl commented that he would bring this up at the next TERENA Technical Committee meeting and that most people want the CERT to be on a neutral ground.

Action: 20.2 Rob Blokzijl
To bring up the CERT issue during the next TTC meeting

Gilles Farrache asked what had been changed between RARE and TERENA. Steve explained that TERENA is an organisation of research networks. He added that IBM has applied to be a member. They want to join for academic and research networking, as well as Digital. These organisations will be non-voting members. Others are welcome to join.

Rob Blokzijl noted that RARE had a policy of 1 member organisation per country, as well as EARN. This rule would be hard to apply for some countries, e.g. Russia, where it is difficult to define such "research networks". Steve answered that this rule still applied, but there was a continuing discussion on this matter. One of the options was to get an umbrella organisation as a member representing Russia. Earlier, EARN had also tried to move to a multi-representative per country model, but had reverted to the old model in the end.

Daniel Karrenberg asked about TERENA's other (RARE style) activities besides services. Steve replied that TERENA's current thinking is mostly project oriented. Other Internet commercial service providers are welcome to join these projects. Then Daniel asked if PRIDE-like projects would be possible together with commercial providers. Steve answered that this was indeed possible. Tomaz Kalin commented that the results of these should be of interest for the research and/or academic community and they should be publicly available.

Mike Norris asked if a technical program document would be published. Tomaz answered positively, and advised to contact to get more information.

After this, Gilles Farrache asked if Steve thought that the one member per country model should be dropped. Steve answered that he personally thought something should be changed but he also noted that this model seemed to work for the academic world.

10. IETF Report

Joyce Reynolds held a long and clear talk about the last IETF meeting. She gave a comprehensive overview of what happened in a large number of working groups and focussed on the User Services area where she is actively involved. Furthermore she gave an overview of the the newly proposed working groups with their goals. Joyce published excellent, ASCII text, sheets which probably give the best summary of her talk:

ftp://ftp.ripe.net/ripe/presentations/ripe-m20-jkrey-IETF.txt.Z

11. IPv6

This point was put on the agenda to discuss the idea of a new IPv6 working group.

Wilfried proposed to keep a time schedule of 4 to 6 months to get the working group in place. At least it should be there before the end of the year. He was not sure if this was possible.

Steve asked for the role of the governments in this; should they actively participate in the IETF or more on the local level, and what is the role of security here? Daniel immediately brought up the clipper chip controversy. Joyce replied that she heard that even Scotland Yard was confused about this. Peter Lothberg mentioned that an encryption field should be present.

Rob Blokzijl brought the discussion back to the original topic by remarking that we always asked to participate directly in the IETF instead of forming own groups, however we should consider doing something ourselves this time.

Daniel replied that since we are an operating group we should not be involved in the actual design. However, IPv6 will have such a huge impact that we should do something. He proposed that the IPv6 working group should be an operational working group to experiment on this subject.

Steve mentioned that he saw the distinction between the operational questions and more fundamental questions. Rob answered that we should not form another forum. That was the reason he agreed with Daniel that the group should be an operational group.

Francis Dupont stepped forward and showed a sheet with his ideas about the new working group:

Technical work specific to the European situation
Pilot project for migration
feedback to RIPE

Rob proposed to start this discussion on the list within the the next four weeks.

Action: 20.3 Rob Blokzijl
To start discussion on the IPv6 working group

Mike Norris added that he supported this. He said he felt this working group was more like a project. Rob then asked Steve: If I understand Steve correct, we could ask TERENA to assist us? Steve answered that this was indeed the case.

Daniel finally commented that we could now go forward by going to discuss this further on the list.

12. Working Groups Reports

12.1. Local IR working group

Chair: Mike Norris
Scribe: Anne lord

12.1.1. Introduction

Mike Norris, the chairman, welcomed the participants to the Local IR meeting. Anne Lord volunteered as scribe to take the minutes. The group met twice, for 1.5 hours each meeting. Proposed alterations to the agenda are below:

start with items 1, 2 and 3 on the agenda - follow item 3 with item 12. (will be reported as per scheduled agenda order)

12.1.2.1. RIPE 19 minutes

There were no changes to the minutes as previously circulated.

12.1.2.2. RIPE 19 actions

18.3 done : Geert Jan de Groot To investigate monthly publication of error files on reverse zone files, similar to the host count error files.

19.2: Mike Norris
At the 20th meeting to raise the training of local IR's as a topic for discussion.

19.3 open: Daniel Karrenberg
To make an inventory document of the problems associated with charging for address space.

19.4 closed: Daniel Karrenberg
To recirculate draft proposal on use of private address space for VSE's not connecting to the Internet. Circulate proposal to the WG mailing list.

19.5 closed: RIPE NCC
To organise a meeting between regional registries, with representatives from the RIPE local - IR working group.

19.6 closed: Geert Jan
To document new attribute "status" proposed to describe whether a network is delegated, reserved or assigned.

19.7 open: RIPE NCC
Circulate revised ripe-115 to the local-ir mailing list for comments.

19.8 open: Daniel Karrenberg
To prepare specification for the format of the list of service providers.

12.1.3. Reports from Regional Registries

There was an open invitation to all local registries to contribute under this agenda item.

12.1.3.1. Kim Hubbard - InterNIC

Kim Hubbard reported on the IP registry activities of the InterNIC, giving also some background information about how their operation is organised.

Overview statistics:

3 staff handle 3000 - 4000 requests per month.
Each staff member handles approx 20-30 telephone calls per working day.
They handle approximately 5000/month allocations and assignments to ISPs.
2000/month single and small block assignments.
Class B assignments are running at 20/month. This has been quite stable for some time.

Address Justifications requested:

class B's

min 10% utilization expected
subnet mask plans
network diagrams

class C's

CIDR blocks to ISPS gradual increase in allocations "handholding" procedure will be initiated in the future.
subnetting plans
host/subnet counts

The procedure of referring small ISPs to larger ones for address space will change.

Additional Services by IP Numbers Group

shared WHOIS project approximately 2000 reassignments/month
inverse address registration approximately 500 delegations/month
AS number allocation approximately 60/month currently not a lot of justification is required by requesters

Current Issues facing the InterNIC

rfc1597/1627 policy on encourage its usage or not
single low host requests
"portable" addresses
ISP allocation guidelines
ISPs want to see these in writing
registry guidelines
the InterNIC is working with other Regional Registries in this area to coordinate and streamline efforts

12.1.3.2. RIPE NCC Report - Daniel Karrenberg

The slides of Daniel's presentation were part of the RIPE NCC Report which was presented in the plenary session, which are available from

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

Overall the statistics shown in the report reflect the expected linear growth of the Internet with respect to DNS, the number of local IR's, It is expected that there will be around 240 local IR's by the end of 1995. The current breakdown is as follows:

Enterprise Registry: 14
Last Resort Registry: 31
Provider Registry: 103

of which:

17 are large 29 are medium 57 are small

It is clear that the growth curve of the number of new local registries is increasing. The new registries require more and more support and guidance and are a significant load factor on the RIPE NCC. However, the up side is that they should provide more income in the long term.

The number of incoming messages to hostmaster is increasing and is now averaging around 37 messages a day. The workload and growth is such that this now accounts for more than 50% of staff time, leaving very little time for other needed activities. The staff situation is improving - now 4.5 FTE, but is not enough to cope with the pace of growth.

With reference to the invoicing for 1994, some erroneous bills have been sent for which Daniel apologized.

In terms of activities over the last quarter, the RIPE NCC is just "keeping up". A better billing mechanism has been implemented, new classless db is running well, there has been internal reorganisation and new staff have to be trained.

In the questions that followed, Daniel made it clear that the workload of the registry work was such that it had become clear that a a ticketing system integrated with mail was needed. On this there was a request to the participants for input - Mark Kosters of the InterNIC has developing an in-house tool that might be useful although it is still under development.

There was a question concerning the criteria for local registries: whether they were still the same as those stated in ripe-104. In response, Daniel noted that because of the very high number of new local registries, the procedures for management of the address space with respect to the local registries has been tightened. Basically now, all new registries follow a "handholding" procedure with an assignment window of 0 which increments to larger amounts over time. Ripe-104 will be revised to reflect this.

There was also a question regarding the newer "Enterprise Registries" and who qualifies in this respect. Enterprise Registries are those which coordinate the address space deployment for an organisation. One of the criteria to determine "eligibility" is the existence of a large corporate networking division within that Enterprise. It was felt that written guidelines were needed in this respect and that these should go into the next revision of ripe-104.

12.1.3.3. Local Registries Report

Wilfried Woeber had previously circulated to the list some questions concerning the policy on reallocation of address space in the light of an ACOnet customer who reallocated addresses.

This is quite clearly undesirable. Wilfried said that he would put a clear message in the ACOnet application form in an attempt to prevent this, and urged other local registries to do likewise.

12.1.4. Charging in 1995

The charging model for 1995 is fixed. It was agreed to at the RIPE contributors meeting held on September 21st, 1994. The workplan for 1995 and the expenditure budget of 407,000 ECU were presented at the meeting and both were unanimously accepted.

The current status of the budget is that 30% of the planned expenditure has not yet been raised for 1995. During 1995, paying registries will receive a service level above non-paying registries. As from February 1st registries that have committed in writing will get a priority service.

To speed up paperwork, the RIPE NCC will accept a commitment to pay from a registry as though it is a formal agreement. This is only until February 28th, 1995.

There were a number of comments and questions from the audience regarding the financial status of the RIPE NCC and the billing arrangements. Funders were encouraged to use the if they had any queries.

There was a question concerning unfair competition from service providers who are not funding the RIPE NCC and therefore do not have the same financial commitments. Daniel commented that he cannot determine who is and who is not a service provider, nor who is or who is not a registry. He can only control the service level they receive.

12.1.5. Future charging models

Daniel Karrenberg reported on the current thinking for future changes to the funding model. The NCC Contributors Committee have discussed and approve a system of usage based charging in 1996. For this to be in place from 1996 onwards, it is vital that the discussions begin soon. Critical decisions need to be made regarding the metrics to be used, the percentage basis of the "usage" based fee. Input is sought from the local registries themselves and the discussion on the local-ir@ripe.net mailing list should begin between now and the next RIPE meeting in Rome.

Concern was expressed that public bodies and government funded IP services will need to know their expected costs ahead of the financial year.

12.1.6. Training

Given the overhead that the new registries are now putting on the RIPE NCC, it is clear that there is a need for some registry "induction" or training to take place. It was agreed at the contributors last year in September, that the start up fee would be used to provide some of the resources for this activity. The proposed medium for the training is the WWW. All local registries are asked to provide any material if they have in-house material themselves that is applicable.

Action: 20.4 Mike Norris
To send mail to the list asking for input on the content of the training material.

It was agreed that the focus of the training would not be "how to be a service provider" but on the functions of a local registry, especially with respect to RIPE interaction.

12.1.7. Revision of ripe-104

Very Small Enterprises - VSE's

Previously circulated to the mailing list was a document by Daniel Karrenberg describing a proposed method of handling requests from VSE's whose address space assignment utilization rates are very low. There was no feedback to the document so the discussions have died.

Briefly, the document proposed the following :

if no outside connectivity and low host numbers, don't assign unique address space.
when VSE's do connect, ISPs are recommended to use dynamic address space assignment.

Wilfried Woeber commented that the ideas presented in the paper sounded sensible, but he was concerned that he lacked a thorough understanding of the technical implications. It was agreed that an "applications document" was needed to accompany this proposal and to circulate the draft of this document to the list.

Action: 20.5 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.6 Mike Norris
To recirculate to the local-ir@ripe.net mailing list the document on VSE's as drafted by Daniel Karrenberg.

Slow start of registries - Assignment Window

In the next revision of this document, there will be a description of the "handholding" procedures and the sliding window mechanism which is now applied to all new registries.

Daniel Karrenberg announced that a number of registries, in the past, have assigned excessive amounts of address space to their own organisations. This practice clearly does not follow the procedures for address space assignment and is not in the interests of conserving address space. After some discussion it was agreed that local IR's will themselves have a self-assignment window, with a threshold of either 4 or 8 class C's which they can assign to themselves without review. Anything higher than this, must be submitted to the RIPE NCC for review.

Future of Last Resort Local IR's

Last Resort IR's are not currently being charged for RIPE NCC services, because they provide valuable support function to the RIPE NCC. In the future, 2 options present themselves:

Last Resort IR's charge for their services like any other ISP and multiple Last Resort IR's may co-exist. They could be called "provider independent" registries.
The distinction between last resort and other registries will disappear as all will be providing a chargeable service.

This brings up the issue of the "ownership" of address space.

The discussion of portable address space within the IANA is currently very topical. The IANA says that *unless* a contractual arrangement with the customer is made, by the ISP, the customer retains the right to take the address space with them if they change ISP. To try to negate this trend, ISPs could make a charge for out-of-block routing announcements. The customer is faced with the choice of a price/renumbering trade-off.

12.1.8. Revision of European IP network number form (ripe-124)

There was a request that the supporting text for the admin-c: contact person asks that the contact person is available at the site of the network.

12.1.9. Global Coordination

Daniel Karrenberg reported that both the InterNIC and the AP-NIC procedures with respect to address space assignments are in line with the RIPE NCC. However, the IANA does still make large assignments (which the InterNIC has to carry out).

It is felt by all Regional Registries that rfc1466 is in need of revision. On Friday 27th January, 1995, a meeting has been scheduled between all the Regional Registries to discuss and align policies as well as draft a revision of rfc1466.

Action: 20.7 Mike Norris
To circulate to the local-ir@ripe.net mailing list a summary of the meeting between the Regional Registries.

12.1.10. Reverse domains

This is reported previously by Geert Jan de Groot under 18.3

12.1.11. Tools

Geert Jan reported that 70% of the reverse domain delegation requests contain errors in their set up and are returned to the sender. The French NIC (Benoit Grange) is developing a tool which does some error checking. The tool will be distributed once it is finished.

Daniel Karrenberg asked the audience how many people were using the stt tool developed at the RIPE NCC. No-one admitted to using it.

12.1.12. Database issues

12.1.12.1. RIPE handles

Geert-Jan gave a short presentation on the use of RIPE handles and how they can be generated with finger. When you do:

finger handle.YourInitials@whois.ripe.net

the next free handle will be shown.

Action: 20.8 Geert Jan de Groot
To summarize the RIPE handle tool and to distribute to the local-ir@ripe.net mailing list.

12.1.12.2 Use of "person" object

The use of the person object was clarified. The admin-c: contact should be a person and the tech-c: contact can be a NOC.

12.1.13. AOB

Billing

There is a directory ftp://ftp.ripe.net/ripe/registries which contains all the billing relevant documentation. Daniel Karrenberg asked everyone to note that the format of some of the information in this directory has changed recently.

Part of the registry database maintained by the RIPE NCC has "billing information". Please note that if you are located in an EU member state, you should quote your VAT number otherwise you will be charged +17.5% extra.

If you have any doubts about the billing data the NCC holds about your organisation, please don't hesitate to check with to ensure that the data is correct and up to date.

12.2. Database Working group

Chair: Wilfried Woeber
Scribe: Andreas Knocke

12.2.1. Administrative stuff

The agenda was agreed upon as proposed. Andreas Knocke (DE-NIC) volunteered to act as scribe for the meeting.

12.2.2. The "new" database software: review, future

Report by Marten Terpstra: The new software had been announced at the RIPE 19 meeting in Lisboa. After being available for external testing it was put into production in October 1994.

Since then some bugs were fixed and some (small) syntax checking features were added, users of the database should not have noticed the change - mostly.

Recently the database was moved to a dedicated (new) machine (Sparc/5, whois.ripe.net).

As a general remark, Marten urged everybody to use the generic names for accessing the individual RIPE NCC services because a number of services (ftp, whois, www) have already been moved to different machines. Renumbering the RIPE network also required to renumber the machines.

Documentation and future development of the software package shall be done by Daniel Karrenberg and David Kessens - due to the fact that Marten is leaving the RIPE NCC right after this meeting.

Finally the official release will be available from

ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-1.00.tar.gz

Other aspects of general interest:

Time stamps (as requested by Merit and agreed upon in Lisbon) have not yet been added. Maybe Merit is going to add that functionality. Still there should only be one common version of the software.

Hashed comments (# starting after white space) are allowed in any object submitted to the database although comments are *not* stored in the database itself. While there was some discussion of allowing "end-of-line comments" this was dropped to avoid breaking scripts.

Still an empty line (only white-space) is required to separate objects from each other.

12.2.3. RIPE Handles

RIPE Handles are necessary to uniquely identify person objects with identical names and are required for the exchange of information with other databases, e.g. the InterNIC. Handles created for use in the RIPE environment database are very similar to the well-known NIC-Handles but have the string "-RIPE" appended to make them unique amongst different registries. Given the more distributed model of operation, the APNIC is going to append the relevant ISO 3166 country codes for the same purpose.

Unique RIPE Handles can be obtained by fingering whois.ripe.net:

finger handle.XY@whois.ripe.net

where XY is the initials of the person's name to have a handle assigned. E.g. to request a handle for a given John Doe just do:

finger handle.jd@whois.ripe.net

which returns something similar to:

First free handle: JD5-RIPE

Using this (interim) method of obtaining unique handles introduces a possible race condition. This is yet to be solved.

There are still some loose ends when a person object is updated to get a handle field. Occasionally there may be duplicate person objects created. In this situation the out-dated object can be simply deleted.

RIPE Handles are currently considered to be in field test.

On a more general level it was proposed to investigate the legal aspects of storing person-related information in a publicly accessible database.

12.2.4. External interfaces

The SWIP (Shared Whois Project) for exchanging information amongst the (Regional) Registries requires unique handles.

The rwhois project (see RFC 1714) - Mark Kosters of InterNIC briefly reported on the resources available (he is working on it in his spare time). A final beta version might be available at the end of Q1 1995.

12.2.5. Review of objects and links

Inverse lookups: It is very desirable to have a way of doing inverse lookups. This is needed to find out where all the references to a given object (persons, but maybe inetnum objects as well) are coming from.

Action: 20.9 RIPE NCC
To do an implementation analysis on inverse lookups in the RIPE database.

"status:" attribute Geert Jan de Groot explained that this attribute was indeed required for keeping track of address assignments. Marten had agreed to implement it on the fly to support a new tool for NCC internal use.

As implemented, the acceptable values for this attribute are "Delegated" "Assigned" (and "Reserved"). The little sketch below depicts the model:

total delegated delegated assigned address to RIPE to local-IR to customer space 193/7 19?.*/16

12.2.6. Meta objects

Contrary to the current recommendation the person object is "mis-"used by a couple of entities to describe role accounts and similar things.

Daniel Karrenberg agreed that this can indeed be useful, even if he opposed this use in the past. However "admin-c" for an object still has to point to a real person object.

Action: 20.10 Havard Eidnes
To write up a proposal with input from the Local-IR WG and the EOF (European Operators Forum)

12.2.7. Input from the DNS-WG: domain object

In addition to a brief report on the decisions within the DNS-WG, Piet Beertema elaborated on the information scheme for keeping track of domains under the TLD ".nl" which has been implemented. Piet intends to remove all objects other than the one for .nl itself. This proposal calls for a forwarding pointer in the RIPE-DB that links to the machine where the data is actually available (the name server for .nl).

Questions discussed and issues arising from this proposal:

How can compatible schemas be maintained? With the updated domain object this can be achieved, although the representation for persons are different - tools have to "keep this in mind".
The referral mechanism. The rwhois package is not yet ready for production use and has to be extended for CIDRization (whois++ the same). The RIPE DB software currently lacks the concept of forwarding queries (comparable to proxy forwarding in BIND) for forwarding to other whois servers.

There was a general consensus that the domain object is a very good candidate for starting a pilot to distribute information to the environment where it is maintained.

With regard to person objects, the allocation registry and the routing registry, the RIPE database should not be modified right now (production use and automatic configurations!).

Action: 20.11 RIPE NCC
To investigate (as time permits) distribution of the domain information in the RIPE database and to investigate a "private" approach for referrals.

Havard Eidnes reported on a tool to check the primary zone file for .no against the registered domain objects.

Action: 20.12 Havard Eidnes
To publish the tool to check a primary zone file against registered domain objects, for the benefit of other top level registrars.

12.2.8. AOB - any other business

None, thus the WG meeting was closed.

12.2.9. Report on an out of band discussion for the minutes

"An additional, informal BOF happened just before the lunch break - inheritance of authorization was proposed and discussed for hierarchical objects which would resolve a common question: the authorization of allocations from a delegated block and of the addition of subdomains within a registered top level domain."

12.3. Connectivity Working group

Chair: Milan Sterba
Scribe: Christian Panigl

12.3.1. National reports for new countries

New Countries Hostcount (presented by MS) Country Overview (what to talk about) (presented by MS)

international connectivity territorial coverage new services projects to be accomplished soon other providers (peerings and arrangements) problems

BG: (supplement by Christian Panigl)

International lines (very unstable): 19.2kb Sofia-Vienna (Academy of Science, to be replaced by 64kb satellite soon) 19.2kb Blagoevgrad-Vienna (American University)

AUBG.BG and ACAD.BG (CICT) not yet interconnected locally

[the following paragraph has been submitted as a comment to the draft by Daniel Kalchev from UUnet BG]

EUnet is the primary Internet provider in Bulgaria (also connecting most universities). EUnet operates a reasonably stable 19.2 kbps line between Amsterdam and Varna, and an national backbone linking Varna, Plovdiv, Sofia and other larger towns. The international capacity will be upgraded as soon as the Bulgarian PTT is able to supply digital circuits.

CZ: (Vaclav Novak)

International lines: 512kb Praha-Amsterdam (EMPB) 128kb Praha-Vienna (EBONE, to be upgraded to 256kb soon) 128kb Praha-Bratislava (SANET.SK)

National lines: mainly 128kb and 64kb connecting Liberec, Ostrava, Olomouc, Brno, Plzen and Ceske Budejovice

Service providers: CESnet, COnet, EUnet CZ Do not have official agreement but exchange traffic

New: Prague academic MAN now runs on an ATM backbone (six sites)

HU: (Geza Turchanyi) (didn't want to present anything because of major discussions going on internally in Hungary)

International lines: 2*64kb Budapest-Vienna (EBONE, to be replaced by 1*256kb soon) 512kb(+128kb) Budapest-EMPB/EuropaNET

LI: connected via EUnet (e-mail only)

MA: connected via EUnet (e-mail only)

MK: connected via Slovenia (e-mail only)

PL: (Lukasz Ploszajski)

International lines: 2Mb Warsaw-Stockholm (satellite NORDUNET,UNISOURCE) 128kb Warsaw-Vienna (EBONE) 9.6kb to Moscow and Minsk 64kb Stockholm-Lviv (satellite)

National lines: NASK national infrastructure is based on medium (64 kbit/s) or high (2 Mbit/s) speed lines among 10 major cities (Warszawa, Torun, Gdansk, Szczecin, Poznan, Wroclaw, Katowice, Krakow, Lublin, Lodz). There are metropolitan networks operating in majority of these cities and in the nearest future all these cities will be covered by high speed MANs. All intercity lines are going to be upgraded to 2 Mbit/s. There is also a dozen of towns interconnected via 9.6 kbit/s links.

ATM-Pilot services in Warsaw (WARNET)

For more information, see:

http://www.nask.org.pl/NASK/ripe-info.html

RO: (Eugenie Staicut)

International lines: 9.6kb Bucharest-Vienna (UniCom, to be replaced by 64kb satellite soon) 9.6kb Bucharest-EMPB/EuropaNET (Polytech) low speed line to Moldova (operated by UniCom)

National lines: UniCom and Polytech not yet interconnected locally (will be done Feb/Mar 95), ~20 leased lines to UniCom(16 within Bucarest, 4 in the country), ~7 leased lines to Polytech

Commercial providers: EUnet (international public X.25 to Paris), PIPEX (satellite to Budapest), SPRINT, Rompak/Transpac(no IP services yet)

RU: (Alexei Platonov - state academic projects)

The academic community relies on both commercial (Relcom, IASnet) and academic providers (Moscow State University/DFN), Russian Space Science Agency, Freenet (represents Russia in TERENA))

Goal : provide services to all the scientific community by means of all networks which work correctly: RELARN project

In Moscow - the optical backbone has problems with cost sharing, it has brought much technical experience, is now split into two parts: South - running, financed by International Science Foundation (Soros) North - planned state project of the Moscow MAN

In regions - the concept is to create regional NAPs (St. Petersburg, Moscow, Ekaterinburg, Novosibirsk, Chabarovsk) and a backbone network to interconnect them. Users connect to the net through regional providers, connected to the NAPs.

(Dmitri Burkov - Relcom)

Local situation - communications paradise in Moscow for the rich - do it yourself situation in St. Petersburg - almost nothing anywhere else

Major players - SovAm, Sprint group, Relcom, RUNNET - all have important plans to implement national backbones over higher-speed satellite links. Dima talks to most/all of them to: 1) establish relationship and connectivity within Moscow 2) proceed jointly in setting up national satellite overlay 3) jointly participate in CIX international.

Many small resellers of the big: IASnet, Glasnet, Freenet are customers of Relcom, and there are many others.

LB: (Sam Lutfallah)

International lines:

Provided by LIBANPAC (France Telecom/Italian Cable), X.25, satellite and marine cable. Restrictions for international data communications reported; international lines extremely expensive; reselling data-communication services is not allowed; network literacy problem.

Hints from the audience to overcome restrictions: "establish association, services for members only"; "don't ask, do it"; "tag it experimental, not service"

JO: (Imad Ayoub)

NETS company provides e-mail services, since 1994 (~120 customers) Only analog circuits available Requests (RIPE) 'cookbook' for new service-providers (not only routing, registry and the like, but also higher level services like news, mail, ...)

12.3.2. PHARE and DANTE: (Michael Behringer)

PHARE money is not restricted to EuropaNET connectivity, essentially the country national academic network itself decides which line the money should go into. For more information, see:

http://www.dante.net/PHARE.html

EuropaNET AUP has gone, but is still primarily research and development and has no commercial customers directly connected. The correct use of the PHARE project money is enforced through a careful selection of the EuropaNET customers (national national academic networks).

Dima Burkov complained about unrestricted reselling of the capacity in Baltic states. Answer: "We cannot strictly control what is sent over these lines"

Peering with Ebone and EUnet.

List of PHARE financed lines as stated by Michael (installed/planned)

12.3.3. Peerings & Partners of EBONE (Bernard Tuy)

POPs in Paris, Vienna, Munich, Stockholm, Geneva

New installed peering (currently 128k) between EUnet (Amsterdam) and EBONE (Vienna), old with EuropaNET, Nordunet

12.3.4. PIPEX (Keith Mitchell)

Activities in Central and Eastern Europe: 64 kbit to Slovenia, local PIPEX IP services reseller Quantum VSAT POP in Hungary - Banknet, aimed to resell services over all CEE

12.3.5. RIPE Connectivity Document Store Status

The invitation to RIPE NCC contributors to join the CDS has worked quite well and has to be repeated periodically

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

CDS home page needs rewriting

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

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

12.4. Routing working group

Chair: Marten Terpstra
Scribe: Willem van der Scheun

12.4.1. Opening, scribe, administrativa

Marten Terpstra chaired this working group meeting. Willem van der Scheun volunteered for the minutes.

12.4.2. New chairman for the routing working group

After the last WG meeting in Lisbon Jean-Michel stepped down. Since then no candidates for chairing the routing WG have been found. During the meeting all remained silent. So it seemed the routing WG would be without a chair.

Note from the minute-taker: After the meeting Willem van der Scheun reconsidered chairing the routing WG and volunteered. So the routing WG now does have a new chairman.

12.4.3. NSFnet, NACRs, the advisory attribute and the RIPE database

Elise Gerich gave a presentation on the transition from the NSFnet PRDB to the Routing Arbiter Database (RADB). The transition has to be completed before april 1995. At the time of the presentation submitted NACR's are stored both in the PRDB and in the RADB. From both databases a new AS690 routing configuration is made and these two are then compared.

There are some changes in the NACR procedure. NACRs could be sent in only by the AS690 peer AS that was listed as the primary AS and had to be ACK'd by all secondary ASes. Now home ASes can send in NACRs themselves. These have only to be ACK'd by the primary AS. A message that announced this change was sent to the nwg mailing list. As European operators are not on this list, this change was not known. Marten will forward the message to the routing-wg mailing list.

Action: 20.16 Marten Terpstra
To forward the new NACR procedure to the routing-wg mailing list

The PRDB will be retired a few weeks after the meeting. After that Merit will accept both NACR's and route objects with the advisory attribute. For European nets, the information will be extracted from the RIPE database, so no registration with the RADB is needed. A similar agreement has been made with MCI for their database. In case of conflicts the information in the RADB will be authorative.

The advisory attribute is one of the additional attributes to ripe-181. The syntax is "advisory: ASxxx string". It is an advisory to ASxxx, so the syntax and semantics of "string" are defined by ASxxx. For AS690 an example would be "advisory: AS690 1:AS200 2:AS701".

Merit will set a date after which NACR's are no longer accepted and the RADB will only be filled from the routing registries. This will be announced on the routing-wg mailing list.

Action: 20.17 Merit
To announce on the routing-wg mailing list when NACRs will stop being accepted

The question on how to get the advisory attributes in the RIPE database was discussed. It was decided that the NCC would preload the database with the advisory attributes based upon the information on the PRDB and the RADB. Before this, a comparison will be made between the RADB and the RIPE DB. The preload will be done shortly before the NACR's are no longer accepted.

Action: 20.18 RIPE NCC
To compare the AS690 routing information for European routes as stored in the Merit RADB with the information on the RIPE DB and report on mismatches

Action: 20.19 RIPE NCC
To preload the advisory attribute from information in the Merit RADB shortly before Merit retires the PRDB.

Action: 20.20 Merit
To keep the RIPE community up-to-date on the transition process through the routing-wg mailing list.

Havard suggested to use the AS object to define a "default" advisory for routes originated in that AS. This suggestion was not accepted.

12.4.4. CIDR status in Europe

Marten presented some figures that he would also present in the plenary session.

On January 24th, the routing table had over 24.000 routes. (At the moment of writing these minutes, about 4 weeks later, it is almost 25.000). The routing problems are not just the size of the routing table. With more memory this can be tackled. A more serious problem at the moment are the enormous amount of route flaps that causes router CPUs to spend a lot of their cycles on routing table updates. A better usage of CIDR would decrease the number of route flaps.

Merit has performed a survey asking why CIDR was not or could not be used. Answers vary, but most are that AUP issues prohibit CIDR usage, that the equipment used does not support CIDR, that it's not their problem or that CIDR is fully unknown. Further deployment of CIDR seems more a social than a technical problem.

12.4.5. AOB

No other business

12.4.6. Closing

Marten closed the meeting

12.4.7. Questions and comments after the report in the plenary session

After the presentation of the working group report in the plenary session it was announced by Rob Blokzijl that a new chairman has been found for the routing working group:

Willem v.d. Scheun

12.5. MBONE working group

Chair: Rob Blokzijl
Scribe: Willem van der Scheun

12.5.1. Opening, welcome, minute-[wo]man

Erik-Jan Bos could not make it to this meeting. Rob Blokzijl will act as chairman of the meeting, Willem van der Scheun volunteered to take the minutes

12.5.2. Minutes of the Lisboa meeting

There were no comments on the minutes, so they were accepted.

12.5.3. Terms of Reference

As these have been circulated at the meeting, there has been not enough time to read it. This item was postponed to the end of the meeting. After a short reading period, the ToR were accepted.

12.5.4. Status Mbone

12.5.4.1. Europe

Francis Dupont gave a short presentation on the Mbone status in France.

Maps of the French Mbone can be found on

ftp://ftp.inria.fr/network/mbone/maps/mbone-*

Rob gave a short explanatory talk on Mbone. He also mentioned the big improvement made by the tunnel between SURFnet and CERN over the Amsterdam-Geneva T1. The quality of this tunnel is high enough to view the recently started broadcasted seminars by CERN.

The PNO ATM pilot is used by the MICE project. Michael Behringer mentioned the ongoing test of an IP overlay network on the PNO ATM pilot. Circuits have been established between Finland, The Netherlands, Spain and Switzerland.

12.5.4.2. US connectivity

The transmissions from the US vary widely in quality, to say the least. This lead to Rob asking if there is any well established mechanism for noticing, tracking and solving problems in the Mbone. Alas, such mechanisms do not exist.

Nikhef wants to use the Mbone for conferencing with sites in Japan. The connection to Japan is very bad, due to a very high threshold between the US and Japan and problems in the Japanese backbone.

The UK refuses tunnels with mrouted versions lower than 3.2

Blasco mentioned that Sun does not support the Sun videoboard on SunOS, only on Solaris. Also installing an Mbone router with the multiple ethernet board is not possible under SunOS, as this board is only supported on Solaris.

Milan wondered if the Mbone itself would be a medium to distribute trouble tickets once it has stabilized. The meeting thought that this was not feasible.

12.5.4.3. Maps

The group expressed the need for maps of local or national Mbone infrastructure. This could start with collecting existing maps. Herman van Dompseler of Nikhef volunteered to produce a new European Mbone map. Some maps and other info on Mbone and teleconferencing can be found on

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

Having an up-to-date map will make it a lot easier to make improvements on the Mbone infrastructure.

Action: 20.21 Herman van Dompseler
To produce (and maintain) an European Mbone map.

12.5.5. New developments

12.5.5.1. PIM (experience)

PIM is used in the Moscow region. Experience was still limited as it was only operational since 1 week, but at least it seemed to work and to interoperate with mrouted. The Mbone feed comes in over a satellite link between Moscow and Germany. Software used in Moscow is 10.2(2.2). Interoperability between PIM and mrouted includes pruning.

12.5.5.2. Implementation plans

Francis and ACOnet have definite plans to start using PIM. In ACOnet it will run over the SMDS infrastructure. Kevin Hoadley wanted to know if PIM supports SMDS group addressing. Francis thought it does not, and that broadcasting will be needed. ACOnet has no problems with this, but Janet cannot do broadcasting.

Francis mentioned that PIM for BSD 4.4 would be available soon. When it was available, he would send a pointer to the Mbone mailing list.

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

12.5.6. AOB, closing

The status of updating the router object to include mbone routers is unclear.

12.5.7. Questions and comments after the report in the plenary session

Erik-Jan Bos gave an URL for more information about the European MBONE:

http://surver.wind.surfnet.nl

12.6. DNS working group

Chair: Francis Dupont
Scribe: Paolo Bevilacqua

12.6.1. Domain object

We decided to update the domain object template because some attributes were mandatory whereas they should obviously be optional or obsolete. A proposal had been published before the meeting. Two remaining decisions were made:

the subdomain (sub-dom) attribute will be kept optional
the domain net (dom-net) attribute will be moved to obsolete

There is still a strong need for a sharable tool for IR that can use both DNS and database data. It is solicited to have a tool to convert automatically from zone files to RIPE database or/and the reverse. Benoit Grange proposed a tool that can fill name server (nserver) attributes from DNS NS resource records. Havard Eidnes proposed another tool that can detect discrepancies between DNS and the database.

A proposal was made to split the object database. In this context it was proposed to have private objects, to let IRs have a better management for local needs. This would give two choices to national IRs:

run a local whois server
use the RIPE server (with current domain object) Again it was proposed that it should be mandatory mandatory for each IR to provide (directly or not) the whois service. The "look-and-feel" of domain entries should be the same in order to keep the possibility to use whois server output for automatic tools. (=> DB WG)

12.6.2. AOB

We talked about IRs and ISPs charging for name space allocation. (=> local-IR WG)

The last version of Paul Vixie's BIND is version 4.9.3 beta 17. There is another stock: RU-BIND by Leonid Egoshin.

A minimal support in DNS software for IPv6 experiments is hardly needed (today in BIND 4.9.3 beta 17, it is not possible to put AAAA resource records into zone files).

Several name servers still use low TTL (the recommended value is 64), or worse, don't use UDP checksums! We remind name server managers that UDP checksums are *mandatory* for name servers!

12.6.3. Future

The RIPE chairman proposed to change the current working of DNS WG in order to get a group where DNS bad configurations and operational problems can be discussed and *solved*.

12.6.4. Questions and comments after the report in the plenary session

After the presentation of the working group report it was possible to ask questions and give comments.

Rob noticed a lack of cooperation on DNS related problems. Therefore Rob proposed that a new activity would be founded or a change of focus of the DNS working group was needed. The activity should then concentrate on the operational DNS coordination area. Since Francis Dupont resigned from the chair position of the DNS working group, also a new chair is needed. Leonid Egoshin who developed RU-BIND was named as a good candidate.

12.7. NIDUS working group

Chair: Nandor Horvath
Scribe: David Kessens

12.7.1. Introduction

Nandor Horvath, the chairman, welcomed the (few) participants to the NIDUS working group meeting. David Kessens was appointed as a scribe to take the minutes. The group had a time slot of 1.5 hours but needed only 45 minutes.

12.7.2. GARR project report

Antonio Blasco Bonito from GARR held a short talk on the GARR project. The project is partially completed. A modified wais server has been made for this. About 60% of the academic community in Italy is now in the map. The largest problem so far is keeping the maps up to date. Milan Sterba asked if it was possible to install a map via world wide web automatically. Blasco replied that this should be possible but that the software to do this isn't there yet.

More information can be found at:

http://www.cnr.it/italy.map.html

(This link is not valid, ask Blasco for more details)

and

wais://wais.nis.garr.it

12.7.3. TERENA report

Frode Greisen held a short presentation about TERENA, formed as a result of a merger of EARN and RARE. It is still organised by having one national network member per country. However, TERENA is currently discussing if it will be possible to allow for associate members, which is for organisations who are interested in TERENA, and for international members, for example inter-governmental organisations like the UN. One of the challenges TERENA is facing now is the fact that they should do now with half the combined budget of EARN and RARE together. This means that new projects should be done on a more voluntarily basis and should require less staff.

The TERENA Technical Committee decides about new projects. Rob Blokzijl, chairman of RIPE, is now a member of this committee and suggested to read the following document before coming with proposals:

ftp://ftp.terena.nl/working-groups/wg-isus/minutes/london-12-94

12.7.4. IETF - US Area report

This item was originally on the NIDUS agenda but since there were so few people in the working group meeting, and the idea was that this is an interesting subject for all, it was decided that this presentation given by Joyce Reynolds would be rescheduled to take place at the plenary session.

12.7.5. Questions and comments after the report in the plenary session

After the presentation of the working group report it was possible to ask questions and give comments.

Rob proposed to disband the NIDUS working group on assumption that we get regular reports from the IETF and TERENA. Nobody objected to this proposal.

Action: 20.23 Nandor Horvath
To inform the NIDUS working group about the decision that it had been disbanded.

12.8. EOF Meeting

Chair: Peter Lothberg
Scribe: Havard Eidnes

12.8.1. Welcome

Being the host of the meeting, Rob Blokzijl welcomed everyone and informed about the local logistics.

12.8.2. Agenda Bashing

No changes to the agenda.

12.8.3. Appointment of minute taker

Havard Eidnes was appointed minute taker.

12.8.4. Apologies

No apologies received.

12.8.5. Previous Minutes

Frode Greisen had a comment concerning a note in the minutes which said "PL asked if this model could be extended to other common areas in Internet network service provision." (referring to the agreement concerning the operation of the London Internet Exchange (LINX)).

Some countries have formed consortia to take care of the funding issues wrt. DNS registration, examples of Germany and Japan were mentioned. There was expressed interest in collecting the schemes used in the various countries - however, no volunteers stepped forward to coordinate this.

12.8.6. Status of European Interconnect Points

PL presented a matrix showing some of the different characteristics of the Internet exchange points in Stockholm, Paris, CERN, London and Amsterdam. The characteristics were:

IP address space used is part of D-GIX space? Of the ones above, only Stockholm and Paris use this.
If it is possible to "bring your own box" to the exchange facility. Earlier CERN and Paris didn't have this -- they now have it as an option.
If the boxes on the exchange point are centrally managed or whether they could be managed by off-site personnel. Also here, CERN and Paris only provided central management, whereas now they have this as an option.
All the exchange points mentioned above are fully operational.
Technology used. Only Stockholm has FDDI as an option, all the other exchange points use Ethernet as the interconnect medium.

Also, several more exchange points were mentioned which are already in operation or are being set up, specific mention was made of an exchange point in Denmark at UNI-C, one or two in Italy (one of them using Frame Relay as the interconnect medium, thus the routers connected to that exchange "point" are not co-located) and one in Moscow in Russia where they plan on using FDDI.

12.8.7. Report from IEPG meeting in December

At the 4th EOF meeting, Havard Eidnes was appointed to be the European co-chair of the IEPG. He attended the IEPG meeting in San Jose in December and gave a short summary of the meeting:

The US Internet networking scene is ready for large changes, and some of the service providers (Sprint and MCI) presented status reports of their backbone planning and implementation.
The issue of settlements for peering was raised. There was some discussion of where the delineation between what is "inside" and what is "outside" a provider's borders should be. This also generated some discussion on the e-mail lists later where it was argued that settlements for peering would be unwise.
David Conrad of the APNIC raised the issue of charging for address space or leasing out address space to applicants, at a rate of approx. USD 0.10 per host address. This is partly to fend off unreasonably large requests, but also partly to generate income for the APNIC to support its activities. If it were to be implemented it would generate pressures on other registries to do something similar.
PL commented that the IEPG is becoming quite a large group, and this tends to slow progress and discussion.
There is talk of a MAE-West possibly to be implemented in NASA Ames' facilities.
Rumor had gotten around that there an International Internet Operator's Conference was going to be organised, initially planned for the end of February in San Diego. This came as a surprise to a large subset of the audience at the IEPG meeting. The IEPG had been invited to hold a meeting in conjunction to this conference, however since very little was known about the agenda for the conference it was decided that the next IEPG meeting would be held in conjunction with the summer IETF meeting being held in Stockholm.

Frode Greisen commented that the conference has been rescheduled for April 11-12, still in San Diego. There had not been any agreement on a program for the conference yet. A purpose of the conference would be to have a meeting in a little more formalized format with presentations, papers etc., and also to act as a common meeting ground for the various operators. The ISOC (specifically Frode Greisen) is still open for suggestions on this conference. A quick poll of the audience showed interest from maybe 1-2 persons on attending the conference.

12.8.8. Report on US changes and progress

Peter Lothberg presented a short summary, Elise Gerich filled in with more details when she arrived concerning the ongoing changes of the US Internet networking infrastructure.

The NSFnet-sponsored ANS backbone network will be removed at the latest end of April 1995. The major remaining providers are ANS, MCI and Sprint. At this time, more than 50% of the US regional network service providers have fully completed their transition away from NSFnet. Some of the large regional NSPs have moved to MCI (e.g. BARRnet and NEARnet).

Of the NAPs (Internet Exchange points, so-called Network Access Points) planned, only two are fully used for the exchange of production traffic. These are the Sprint NAP in NY and the de-facto NAP operated by MFS, also known as MAE-East or MAE-East+. The other two planned NAPs (to be operated by Ameritech in Chicago, and PacBell in California) do not yet carry production traffic, mainly due to packet loss problems caused by problems with the ATM DXUs used in those implementations. Ameritech has declared that they will implement a fall-back solution based on co-location and FDDI should the ATM-related problems remain unsolved. This fall-back is planned to be ready by mid-february. PacBell has not planned a fall-back solution.

A question was raised about the federal network service providers such as ESnet and NSI -- the background being that some of the european academic service providers receive their US connectivity through usage of links terminating in ESnet. ESnet is perhaps the most pragmatic of the federal networks, in that they are connected to MAE-East. The other federal networks are basically only connected to the FIXes. EPG explained that the federal networks tend not to sign blanket traffic exchange agreements with other service providers, but more "pick and choose" depending on who they have a mission-oriented interest in exchanging traffic with.

At this point PL presented a schematic drawing showing the interconnections between MCI, ANS, Spring, ICM, ESnet, NSI and Milnet.

The question of how to handle the CIX was also raised -- PL said that the CIX is now more or less irrelevant -- as seen from Stockholm only 15 or 20 routes are only reachable through the CIX.

Wrt. the problems with the ATM NAPs, PL shortly explained the problems with the lack of buffer space on high-speed paths. This is more fully explained in a paper by Curtis Villamizar which is available from

ftp://ftp.ans.net/pub/papers/tcp-performance.ps

There was also talk about a new exchange point being established on the US west coast at the NASA Ames facility but open to any network service providers, probably to be called MAE-West and to be based on co-location of equipment. So far this has not materialized.

Of special interest for the European networks, it was noted that the ICM project in its current form is scheduled to terminate at the end of 1995, and that NSF will eventually be getting out of the business of sponsoring network infrastructure. Keith Mitchell quoted a rumor stating that British Telecom, through their partnership with MCI, would be installing a link to the London Internet Exchange and be willing to carry traffic to and from MCI customers to the service providers at the LINX -- the terms and conditions in connection with this were unknown.

The issue of transit traffic from Europe to Asia was also mentioned. Australia is going to become an MCI customer, so that is "not a problem". However, for other service providers connecting to a US west coast Internet exchange point someone needs to subscribe to transit service.

There is also a problem of how to finance high-speed trans-atlantic links without giving some people free rides -- the cost of the infrastructure has to be recovered somehow.

Lastly, EG explained about the changes to the NACR process which is planned. The new infrastructure with the NAPs contain a function called the "Routing Arbiter" (RA for short). Part of this function is to operate a routing registry which is going to be based on the RIPE-181 model and software. The old way of requesting connectivity to the NSFnet (submitting NACRs) would be handled for approximately two more weeks, and thereafter new submissions would have to use the RIPE-181 syntax. It was also the clear intention that e.g. european service providers would only have to register their routes in one place -- importation of data from the RIPE database was planned. To be able to do that would require a small addition to the RIPE-181 schema for the remaining period of the NSFnet transition, known as the "advisory" attribute. This proposal will be handled in the RIPE DB working group.

12.8.9. Intra European routing

PL reviewed a couple of possible network configurations for a regional service provider showing the minimal requirements for their external (and internal) routing. Single-homed providers can use default routing, multi-homed providers can in some cases cope with a "mostly-default" configuration. However, if the neighbor not on the default path announces classless routes, the need for BGP-4 routing arises.

As for configurations for default routing, PL recommended that a default route be propagated by the up-stream neighbors with BGP instead of relying on a "default network". The reasons are several, among others quicker convergence, the removal of the need to pick a network to point default at, etc. However, default routing still has its problems if there are other problems "downstream" from the place injecting a default route or a default network, and to be fully safe against such problems there really is no other alternative than to run with full routing. This costs more money (more expensive equipment) but is easier to maintain (less man-time).

PL also pointed to a currently severe problem in the Internet which at this time is not routing table size (most people who need it have installed 64MB routers by now). The current major problem is the amount of routing updates occurring on the Internet, most of these can be characterized as "route flaps". This is causing the processors in the routers to overload, with lacking responsiveness to routing updates and general poor performance as a result. There are two ways to correct this problem:

Go after the service providers producing the most routing updates and telling them this is counter-productive.
Fully deploy CIDR, as this tends to reduce the number of routing updates (if only a component of an aggregate becomes unreachable, no routing update is sent).

Both of these avenues are being persued. There was some discussion about the dissemination of "flap reports" and that something needs to be done to better make the "troublemakers" aware of that they are causing problems. And again, we were reminded that CIDR deployment is too slow and that those who have not CIDRized their announcements should go back home and do so.

Some concerns were raised over whether the many new small service providers are aware of their duties in this regard, and that they may contribute substantially to the lack of CIDRization and the increase in the route flaps. After some discussion it was decided that it would probably be a good idea to invite some of the new players to a workshop prior to the next RIPE meeting. However, questions were raised whether we would meet the intended audience (e.g. whether they could afford to travel) with such an initiative. It was also pointed to the indirect service providers as a natural place for receiving the required guidance.

12.8.10. Global routing

An example showing the current inoptimal and asymmetric traffic patterns involving 5 service providers was given as an example of the amount of coordination which is required to fix routing problems. It was pointed to that more or less "global" adoption of RIPE-181 could be a possibility, however, in the given example two of the service providers did not belong to the RIPE community and hence have not (yet) started using RIPE-181.

12.8.11. NOC interaction

The problem here is among other things how to "route" trouble tickets and to ensure reliable hand-off of responsibility for fixing problems. This problem also partly points to the maintenance (or lack thereof) of contact person information in e.g. the RIPE database.

It was also pointed out that one should define the expected minimum responsibilities of new Internet service providers, such as "you need to know X" and "you need a NIC and NOC function" etc. The similarity to the GISD work was pointed out, however what seems to be required is a one-page summary which will be read and which points to other documents for further information.

12.8.12. Aggregation of non European address blocks

It has been a desire from certain corners to do "aggregation on a grand scale", e.g. on the border to the US aggregate all the european routes into e.g. 193.0.0.0/8 and 194.0.0.0/8. This is of course not without it's problems, and whether this is really practically feasible remains to be seen. There is however a concern that new (and sometimes old) service providers are registering large blocks of consecutive class C network numbers for inclusion in the NSFnet routing -- these should instead be handled via CIDR.

At the meeting noone raised any major objections to the plan of doing this "grand-scale" aggregation.

12.8.13. Impartial CERT coordination in Europe

Little time remained to handle this issue. Frode Greisen presented the TERENA view which basically was that CERT coordination in Europe maybe was not ready as a "service", and therefore could be handled as a pilot project under the auspices of TERENA. However, this issue is still undecided within TERENA.

The EOF opinion on the issue was sought, noone raised their voices at this point. The issue was postponed for the next meeting.

12.8.14. AOB

None.

12.8.15. Next meeting.

Possibly mid-april at KTH in Stockholm

Next "plenary" meeting in conjunction with the RIPE meeting in Rome in the beginning of May.

12.9. The MAPS working group

Although, the MAPS working group didn't meet this time, Daniele did a proposal for a more common format how to show the progress of a project. Therefore he proposed to use a more schematically format as used in the connectivity tables used in the connectivity working group. To start with, the RIPE meeting action list should use this format to show the progress of the action list of the ripe meeting.

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

The matrix will be advertised on the list before the meeting. During the meeting it will be reviewed and one can explain why certain actions were not done (yet).

13. Next RIPE meetings

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

RIPE 21 - 8-10 May 1995 Rome, Italy.
RIPE 22 - September 1995 Amsterdam, The Netherlands.
RIPE 23 - January 1996 Amsterdam, The Netherlands.

Following the pattern of 2 meetings a year in Amsterdam and one outside Holland, it was agreed that the Spring 1996 (April/May) meeting would be held in Berlin.

14. AOB

None.

15. Closing

Rob Blokzijl thanked the participants for attending and NIKHEF for providing the room facilities and lunches, and declared the meeting closed.