Skip to main content

RIPE 16 Minutes

1. Opening

Apologies were received from the following persons who were unable to
attend the meeting:

  • Jan Guntograd - Technical University, CZ
  • Roland Acra - CISCO
  • Stephan Biesbroeck - Leuven, BG
  • Bob Collet - SPRINT
  • Ljubomir Stefanov - Bulgarian Academy of Science
  • Radoslav Dakov - Bulgarian Academy of Science
  • Oliver Korfmacher - NetCS
  • Clemens Schrimpe - NetCS

1.1. Welcome

Rob Blokzijl welcomed the participants to the 16th RIPE meeting hosted by NIKHEF and held at WCW, Amsterdam.

1.2. Approval of the agenda

The agenda was approved.

1.3. Papers tabled

Papers:

  • Agenda for the 16th RIPE meeting
  • Working Group Agendas - one document
  • Map of International IP connectivity in Central & Eastern Europe
  • RIPE Connectivity Report - draft
  • RIPE NCC Review - draft paper
  • Decisions of the RARE/RIPE Coordination Meeting (CoA (93)052)
  • Current version of DNS advice txt - P. Beertema

Presentation notes:

  • DANTE Mission Statement
  • GARR on-line Network Resource Guide

Publications:

  • EUnet Infrastructure Map
  • ACOnet 5th Network Seminar - Notice
  • EARN Resource Discovery Pamphlets

2. Minutes of the last meeting

2.1. Approval of the minutes

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

Action: 15.4 Bob Day/NCC
To fold in the comments of the working group on the ripe-draft-hints-v1.txt, circulate the document to the wg list and publish as a ripe document. It was confirmed that Bob Day was extremely busy and that the action should be taken off him. Mike Norris volunteered to continue the work.

Action: 15.7 Marten Terpstra
Fold in comments and republish amended ripe-72.

Action: 15.10 Daniel Karrenberg
To propose new tags "created" and "assigned" to the database working group for consideration.

Action: 15.17 Glenn Kowack and Tony Bates
Write a top level introduction for the user as an add-on to the GISS paper once it has been written.

Action: 15.19 Peter Lothberg
To draft document on Inter-AS local information.

Action: 15.21 Daniel Karrenberg
To draft document on colouring.

3. RIPE NCC Report (Daniel Karrenberg)

The RIPE NCC Report was given by Daniel Karrenberg and included a presentation by Marten Terpstra on the new RIPE Network Management Database software. Copies of both presentations can be found in the RIPE document store in the presentations directory, files:

  • ftp.ripe.net/ripe/presentations/ripe-m16-dfk-NCC-REPORT.ps.gz
  • ftp.ripe.net/ripe/presentations/ripe-m16-marten-DBPLEN.ps.gz

4. Joint Projects Progress (Tony Bates)

Tony Bates reported on the status of the three Joint RARE/RIPE projects carried out at the NCC. Copies of these presentations can be retrieved via ftp from:

  • ftp.ripe.net/ripe/presentations/ripe-m16-tony-GISSREP.ps.Z
  • ftp.ripe.net/ripe/presentations/ripe-m16-tony-RSREP.ps.Z
  • ftp.ripe.net/ripe/presentations/ripe-m16-tony-PRIDE.ps.Z

5. RIPE NCC Review Board (Rob Blokzijl)

Rob extended thanks to all those who provided input to this activity - especially Wilfried Woeber and Milan Sterba. A draft document has been produced summarising the outcome of the review. This document was circulated as a tabled paper at the meeting and can also be found in the RIPE document store in the following directory in file:

  • ftp.ripe.net/ripe/docs/ripe-drafts/ripe-draft-ncc-review.txt

The above draft was would be discussed further at this meeting (see below) in two BOF sessions.

6. RIPE NCC Activity Plan (Rob Blokzijl)

One outcome of the NCC Review process will be a new Activity Plan for the RIPE NCC. Further refinement of the draft RIPE NCC Review document and further input to the new RIPE NCC activity plan was identified as immediately necessary. This RIPE meeting would be the forum to discuss these agenda points further. The outcome of these discussions are reported under item 18 of the agenda "Reports from the Working Groups/BOF's".

7. RIPE & RARE (Rob Blokzijl)

Rob Blokzijl reported on a coordination meeting that had taken place between Kees Neggers (RARE President), Tomaz Kalin (RARE Secretary General) and himself. A write up of that meeting, produced by Kalin, was distributed at the meeting.

The main conclusions of the meeting were that the following mode of operations and coordination is still valid:

  • RIPE and RARE are independent organisations.
  • RARE has a technical program, but will not include IP coordination in this program: it will rely on RIPE for all IP related matters.
  • RIPE will not set up a technical program of its own, it will use the mechanism of the RARE technical program for executing projects.
  • To ensure close cooperation on the technical level, RIPE appoints a representative on the RARE technical committee.

It was concluded that the Route-Server and GISD project was a good example that this set of agreements is able to get good progress in organising new projects.

On a related subject, Rob Blokzijl mentioned that the RIPE NCC is still mainly funded by RARE member organisations. An organised drive to get funding contributions from non RARE member organisations is on the way; results are coming in, but more is still needed.

8. Network Resource Discovery

8.1. GARR on-line network resource guide (Giuseppe Romano)

GARR presented the results of their On-Line Network Resource Discovery work. The resource guide can be accessed via telnet:gopher.nis.garr.it or gopher:gopher.nis.garr.it

The presentation concluded that the RIPE database, relating to network operations, was not an appropriate medium for storing this kind of information. It was therefore suggested that the results of this valuable work should be discussed further within the NIDUS working group with a view to identifying future developmental work and possible collaboration with related interest groups.

Photocopies of the presentation were distributed at the meeting. Further information relating to this project can be obtained from Giuseppe Romano.

8.2. Guide to Network Resource Tools (Daniele Bovio)

Hard copies of the EARN Network Resource guides were distributed at the meeting. The guides are intended to provide a service to end-users. It is planned that these documents will eventually be available on line as rfc's. Updated revisions to the guides will be forthcoming shortly.

9. How do we ensure a good working European Internet in 1995 (P. Lothberg)

Peter Lothberg presented his view of the technical developments necessary to ensure a good European Internet operation in 1995. Contact Peter Lothberg for more details.

10. Update on the new JIPS services (Phil Jones)

The ASCII text of this presentation can be found in the ripe document store in the presentations directory:

  • ftp.ripe.net/ripe/presentations/ripe-m16-pwj-JIPS.txt

10.1. Introduction

It seemed timely to have an update for RIPE on what was going on in JANET. This relates substantially to IP. RIPE members had noted the large and expanding number of DNS-named hosts in the United Kingdom. This was by no means all JANET developments of course: there were commercial providers in the United Kingdom, and the numbers of these were increasing. However, there was much activity in the JANET community, and that was the subject of the talk.

10.2. Requirements(1)

  • the latest! ... audio, video, high speeds, etc.
  • plus'more of the same', much more.
  • connectivity: general, but with emphasis on'similar communities', i.e. those around the world (as well as in the United Kingdom) involved in research, academic work and education.

This much was probably as expected.

10.3. JANET - Status Quo

JANET was an X.25 network, with IP running as an optional service over that. (The JANET IP Service, JIPS, offered a full routing service, with connected institutions having to concern themselves with routing only in so far as it was necessary for them to deal with it.) There were other network level protocols run over the X.25 service too, e.g. CLNS. However, it was X.25 and IP that were the JNT-supported services. Over 75% of the JANET traffic was IP-related, and this proportion was rising.

Of the 200 or so institutions connected to JANET, some 50 or so were connected by leased lines at 2mbps, with the rest connected at 64kbps or less.

JANET had international links via the US/UK `fatpipe', and via both Ebone and Europanet.

10.4. Requirements Revisited - Network Services

These were:

  • IP
  • CLNS
  • YBTS ("Yellow Book")
  • CONS
  • X.25 per se (e.g. for X.29)
  • Proprietary methods
  • + (later?) as required for `isochronous services'. (ATM?).

In summary, the major requirement was clearly IP, but the requirement of users in the JANET community for X.25 needed to be catered for, and for the indefinite future.

10.5. Plans and Developments

Higher Speeds (34mbps+) were required internationally. On a national basis, the SuperJANET project was developing services at these speeds and greater to add to the JANET profile of operational Network services and to enhance JIPS.

To make JANET more efficient and effective, the `base' protocol on JANET will change to IP. To cater for X.25, the JNT was seeking ways to run X.25 over IP, and X.25 alongside IP (e.g. using frame relay).

10.6. SuperJANET

12+ PDH-connected institutions, 4*34mbps. (Later: SDH). 45+ SMDS-connected institutions, 10 mbps, including the above. SuperJANET will provide IP connections at higher speeds to be incorporated within JIPS. There was obvious (e.g. financial) pressure to remove leased lines from institutions connected via SuperJANET.... and later, there was to be ATM.

10.7. Special Issues

Name Ordering

There will be an announcement soon of a date after which the official ordering will change to be consistent with the `international' order. Phil would keep RIPE informed.

UK, GB, ISO3166 and all that: - There had been an effort to get ISO3166 changed so that 'UK' replaced 'GB'. This seemed to have failed. Changing from UK to GB should be expected to cause much disruption and inconvenience for users all over the world. RIPE might wish to consider pressing for continued use of 'UK' as the abbreviation for 'The United Kingdom of Great Britain and Northern Ireland' on the global IP Internet.

10.8. Documents

Documents (e.g. 'Network News') can be ordered care of the JANET LIAISON Desk. In particular, there was a Network news 'special issue' on SuperJANET last year.

11. Update on EMPB services

11.1. Status EUROPAnet (Svend Moeller Nielsen)

The slides of the presentation given at the RIPE meeting plenary can be found in the document store in directory and file:

  • ftp.ripe.net/ripe/presentations/ripe-m16-EMPB-status.txt

The developments of the EuropaNET since the last RIPE meeting were presented together with the near term enhancements.

The major activity was the execution of the IP Pilot which started March 1, 1993. It entered a preproduction phase June 16, 1993 and ended successfully September 2, 1993.

6 regional networks had participated in the Pilot: SWITCH, JANET, GARR, RCCN, DFN and SURFnet. All were using BGP3. Some connections were done on 64 kbps running IP encapsulated inX.25 to a EuropaNET internal decapsulation point. Others were made on 1.5 and 2 Mbps lines using HDLC/LAPB or PPP. Everyone had a back-up connection via X.25 to a decapsulation point inside EuropaNET. In addition hereto a gateway was established by DANTE between EuropaNET and EBONE to provide Internet connectivity. The gateway which now is operational at512 kbps is managed by SURFnet. A second gateway will be established shortly in London. It will be operated by JANET.

During the Pilot basic connectivity was checked using PING, and trace route and by running TCP and UDP based applications PING tests were furthermore used to monitor availability and to measure round trip times, RTTs. Average RTT between an IP host in Amsterdam and an IP host in London, Dusseldorf or Zurich is 30 msecs. With a host in Madrid it is 70 msecs. This corresponds in practice to the propagation delay.

Different aspects of the routing protocols EGP 2 and BGP 3 were investigated, like distributing of routing information and timers to update and to reconnect.

Throughput was tested at 2 Mbps between DFN and SWITCH by means of a UDP based program implemented by DFN. For 64-byte packets the results were:

  • switch -> dfn: 1736 pps
  • dfn -> switch: 1781 pps
  • For 1024-byte packets: 223 pps

This corresponds quite good to the lab-tests where a little more than 1800 pps was measured without the EuropaNET nodes being fully loaded. A TTCP test carried out by SURFnet between DFN and SURFnet gave:

  • 64 bytes packets: 898534 bps
  • 1024 bytes packets: 941969 bps

The result is practically independent of the packet size and shows the limitation of the TCP window in use. Tests were also done using TCPBLAST for connections involving 64 kbps. Up to 57 kbps was achieved. Now the service has entered the production phase. Connected are besides the pilot participants, RED-Iris, BELnet, HEAnet and RESTENA.

In the coming weeks the X.25 tunnels will be moved from NIKHEF and JANET to internal EuropaNET decapsulation points.

The EuropaNET NMC runs a primary name server: (dns1.empb.net) in The Hague backed up by two secondary name servers:

  • switch: (scsnms.switch.ch)
  • surfnet: (ns.surfnet.nl)

For the DNS the following naming convention:

  • each europanet ip access module: <city><serial number>.empb.net (amsterdam1.empb.net)
  • each interface:<name>-if.<city><serial number>.empb.net
    surf-if.amsterdam4.empb.net

In addition to the DNS host the NMC runs a host which constantly monitors availability by means of PING tests.Alarms are generated on PING failure and PING reports are made per day to investigate stability and RTTs.

For troubleshooting and performance testing the hosts canparticipate in FTP and UDP tests.

Within the near future a new access method will be released. It will provide IP connectivity in the beginning and CLNP connectivity later via Ethernet or connectivity via serial line for IP, CLNP and X.25 from the outset. The IP, CLNP and X.25 routing is done in the Access Box, called the Magic Box.The Magic Box is managed by the NMC which can monitor,
troubleshoot, download software to and configure the Magic Box.

The Magic Box is of the same make as the EuropaNET nodes and connects to a EuropaNET node via the EuropaNET internal protocol. Hence the Magic Box will automatically perform rerouting if more access lines are used and one of the access lines are failing. This rerouting will take place without affecting the IP, CLNP and X.25 routing.

During the fourth quarter, 1993 BGP 4 will be deployed providing interworking with BGP 3 and EGP 2 with the possibility for route aggregation and selective deaggregation.

11.2. Status EUROPAnet/EBONE gateways (Erik-Jan Bos)

For 1993 the "DANTE Gateways" will serve as the connection between the EMPB IP Service and Ebone. The Amsterdam gateway is fully operational now at a speed of 512 kbit/s, there is work in progress on the London gateway. From an Ebone perspective these gateways are known as the DANTE RBS, from an EMPB IP perspective these gateways are the connection to the Internet at large.

Since the connection of the EMPB IP Service to the Internet there is work in progress on the rehoming of the old "IXI tunnels" to NIKHEF and JANET. EMPB IP is fully capable of handling the decapsulation of IP in X.25 internal to their network. All regionals still having tunnels to either NIKHEF or JANET have been contacted to migrate to the new situation.

The sheets of the presentation can be retrieved as:

  • ftp.ripe.net/ripe/presentations/ripe-m16-ejb-DANTE.ps.Z

12. Update on EBONE (Bernhard Stockman)

Bernhard Stockman outlined the plans for EBONE in the future. There was discussion over the organisational structure governing the GIX and distributed RBS's. Further information can be obtained from Bernhard Stockman.

13. Update on EUnet (Glenn Kowack)

EUnet has been operating since 1982. It connects over ten thousand sites and networks, with gateways to major commercial and research networks around the world including the Internet, the Commercial Internet Exchange Association and NSFnet. Services are provided in 27 European-region countries at 50 Points of Presence.

EUnet International Structure

EUnet services are provided in two layers. The centre of the system is EUnet's European Network Operations Centre (NOC) in Amsterdam, The Netherlands. This centre exchanges data between, and provides services and management, to each of the National EUnet Service Provider Networks located throughout the greater European region. Each National Service Provider has a connection to the European NOC.

National EUnet Service Providers

Each National Service Provider operates its own Network Operations Centre (National NOC), which provides EUnet services and user support in the local languages. Technical problems and requests for services at the national level should be addressed to postmaster@<country>.eu.net. Many EUnet service providers offer unique services.

Each national EUnet (through their national NOCs and various Points of Presence (EU-POPs)) acts as a point of concentration for all traffic. This traffic is then transmitted from each EUnet provider to the European NOC in Amsterdam for distribution to the other EUnet providers, peer networks, and intercontinentally. In some cases, EUnet providers connect to intervening EUnet providers, and from there to the European NOC.

The vast majority of EUnet traffic travels over EUnet's own infrastructure. From Amsterdam, EUnet connects to every major R & D network in Europe and, via EUnet's transatlantic digital line, to UUnet and the NSFnet in the United States.

EUnet is also a member of Ebone '93 (European Backbone), and The Commercial Internet Exchange (CIX) Association.

14. Update on SPRINT infrastructure support (Bob Collet/Peter Lothberg)

Bob Collet was unable to attend the meeting at the last minute and sent this apologies. Peter Lothberg gave a presentation in his place. Peter outlined the historical development of SPRINT and some of its more recent activities. Contact Bob Collet for further informationon SRINT.

15. RIPE European Internet Architecture WG-BOF Report

Chair: Bernhard Stockman
Minutes: Mike Norris

Bernhard Stockman had circulated a proposal for an European Internet Architecture (EIA) WG within RIPE, together with a draft charter. He developed some of the operational issues such as:

  • What is routing stability and how is this achieved?
  • Multiple ISPs (Internet Service Providers) providing full connectivity to the global Internet give needs for traffic interchanges.
  • Where should such interchange points be located and who should be allowed to connect?
  • Need for a management framework for such interchanges.

The technical issues need to be specified and timetabled. There was support for the idea of a EIA laboratory, so its needs would have to be determined, its tasks defined and resources specified. One possible task would be to participate in SDRP pilot.

In the general discussion, it was reported that there was support for the model of a distributed GIX (D-GIX). The D-GIX could be see as an interim solution awaiting a more full-fledged solution providing the necessary tools for multiple independent interchanges.

The immediate problem would have to be defined and an interim solution based on the separation of routing and payload traffic developed as outlined in the D-GIX model, presented earlier at this RIPE meeting. The solution would demand a fully populated routing registry. Aiming at full connectivity, it should not limit flexibility, but should make choices of connections possible.

It was agreed there should be an EIA WG within RIPE. There was some discussion over possible confusion arising from the suggested name for the group. A name was finally settled as European Engineering Planning Group (EEPG). It should be open and neutral. While focusing on the D-GIX now, it should be conscious of the need for development beyond this strategy. The WG should have formal liaison and reporting procedures with the IEPG, which was seen as the appropriate forum for the D-GIX activity. Bernhard
Stockman agreed to be the chairman for the new RIPE working group.

Action: 16.1 Bernhard Stockman
To define scope and work plan for the new RIPE working group.

16. Introduction of DANTE (Howard Davies)

Howard Davies, General Manager of DANTE, gave a presentation of the company, its current activities, and future plans. The mission statement for the DANTE organisation was distributed at the meeting. A summary of the presentation is as follows and is available by ftp from the presentations directory

  • ftp.ripe.net/ripe/presentations/ripe-m16-hd-DANTE.txt

Following extensive discussions within RARE, and with particular relation to the need to provide continuity of services established by the COSINE Project, the basic structure of a new organisation which would take responsibility for the provision and management of international network services for the academic and research community was proposed in a document towards a Single European Infrastructure , the Final Report RARE Task Force on the Establishment of the Operational Unit (commonly known as the Green Book) which was published in January 1992.

Following widespread agreement in principle with the proposals contained in the Green Book, a group of 12 European national research networks signed a Heads of Agreements which defined in outline the legal structure of a non-profit company in which all members of the group would be shareholders. A draft Shareholders Agreement has since been produced which specifies the internal procedures of the company in full detail.

Because the Shareholders Agreement is necessarily complex and has to be approved by many countries which have different legal systems, final agreement on its contents necessarily takes a long time. In order to make progress more quickly, RARE agreed to purchase an off-the-shelf UK company (which was named Operational Unit Limited) as an interim measure. The company name was subsequently changed to DANTE (Delivery of Advanced Network Technology to Europe Limited). DANTE is still wholly owned by
RARE but ownership will be transferred to the national networks as soon as the Shareholders agreement has been finalised.

DANTE was formally launched on 5 July 1993 in Cambridge, UK, where it has established its offices. As of 15 September 1993, DANTE has 4 employees. This number will increase to 8 by 15 October 93. The planned staff complement at the end of the first year of operation, i.e. in July 1994, is 12.

DANTE's Mission Statement is exactly as proposed in the Green Book. The full statement is provided as a separate paper available with the papers available for the RIPE meeting.

DANTE has taken over a number of Application Level services from COSINE, notably the MHS service and management of the PARADISE Project. There is also a software portfolio (EXPLODE, FORTRESS) which may be exploited.

The most important DANTE services are however the network level services. DANTE is taking responsibility for the EMPB service (operated by Unisource Business Systems) which has been operational for some time; the 2 Mbps native IP component of the service completed all aspects of its acceptance test on 2 September 1993.

DANTE will combine transatlantic connections and an interconnection with Ebone with EMPB as the European backbone to provide a packaged EuropaNET service which offers full connectivity with the global Internet. Interconnection with Ebone under an agreement valid until the end of 1993 provides intercontinental access at present. DANTE will have its own transatlantic capacity from the beginning of 1994 and expects to use the proposed distributed GIX as a means on interconnection with Ebone 2, EUnet and other services from mid-1994.

DANTE is examining a number of aspects of high speed service planning. The extension of the EMPB service to 4/8 Mbps would provide a short term increase in available capacity. Many new applications however require an order of magnitude increase in bandwidth and the possibility of introducing a 34 Mbps service is being examined. Several technologies are in principle available to support such services - native IP, ATM (with IP over ATM) and SMDS are all being considered - but the lack of availability of lines or other PTO services inhibits progress. Developments within programmes such as tenibc and the HPCN initiative will also be followed.

17. Update on networking with Russia (Rob Blokzijl)

Progress was reported on the following projects:

  • NASA: the NSI link to Moscow is expected to be installed in November this year. The link will be operated under the standard NSI AUP.
  • DoE: ESnet is progressing with the definition of their requirements for networking with Russia. First investigations on the possibility of combining their efforts with those of NASA are under way.
  • Novosibirsk: a new project has been identified to connect the Siberian branch of the Russian Academy of Sciences in Akademgorodok (Novosibirsk) to the Internet via a satellite link with the Institute of High Energy Physics at the University of Helsinki. The technical specifications are ready, some of the funding is still missing.
  • DESY/DFN - MSU: the remaining administrative obstacles have been removed. The link is expected to be installed in October 1993.
  • Gran Sasso - Dubna: this link is expected to be delivered by the end of 1993.
  • Moscow Backbone: the fiber backbone in Moscow has been progressed in the sense that all the necessary administrative work is accomplished. Installation is expected to be finished before the start of the winter season.
  • ISF Moscow: the first international links supported by the ISF are operational.
  • NATO: an introduction of NATO plans for support of networking was presented. NATO has initiated, together with RARE, the organisation of a networking seminar in April 1994 in Moscow. The aim is to get Russian policy makers around the table in order to ensure

18. Reports from the working group parallel sessions

The agendas of each of the working groups are in Appendix 3.

18.1. Local-ir Working Group (D Karrenberg)

Chair: Daniel Karrenberg
Scribe: Anne Lord, Daniel Karrenberg, Martijn Roos Lindgreen

The proposed agenda was accepted after extra points were added:

  • discuss needed documentation
  • discuss the procedure to set up new top level domains

Reports for information:

The DE-NIC will be shut down and moved to another place from the 15th of December. It will be funded by all the DE service providers.

A local-IR workshop was held on Wednesday 15th September in the morning. As it was an informal meeting no minutes were taken. The workshop was considered useful and will be held in conjunction with a RIPE meeting on a yearly basis. A more extensive reporting was asked for, but was considered inappropriate because of the informal nature of the workshop.

Proxy network entries:

Many participants felt that the network proxy entries should be avoided. After intensive discussion it was decided that a draft policy for this will be worked out by Duncan Rogerson and Daniel Karrenberg. This will not happen without input from those service providers who are in favour of the proxy entries.

Action: 16.2 Daniel Karrenberg/Duncan Rogerson
To draft policy on proxy network entries.

Autonomous Systems Database Template

The AS Database template was formally accepted.

Should we maintain a list of local IRs and publish it?

After intensive discussion it was decided that a list of Internet Registries will be maintained and published by the RIPE NCC. This list will be sorted by country and contain all local providerand non-provider registries. A draft of the list will be circulated on the local-ir list
by the NCC.

Action: 16.3 NCC
To publish a list of Internet Registries - draft list to be circulated on the local-ir list.

Input for the Activity Plan

It was suggested to add the following activity: Maintain and regularly publish the list of local Internet registries.

Action: 16.4 NCC
Propose to add to the new RIPE NCC Activity Plan - publishing and maintaining a list of local IRs

Another suggestion is to strengthen the local registry liaison with tutorials and workshops, but no decision was taken on how to implement this.

AoB

It was felt that more documentation is needed. The following volunteers were appointed to edit the documents:

Action: 16.5 Juliana Tamorri
FAQ on CIDR and subnetting.

Action: 16.6 Daniel Karrenberg
Why return unused IP address space and be a good network citizen.

The problem of finding registrars for new top level domains was raised; there was consensus that the RIPE NCC shall offer to serve as temporary registrar for top level domains in our region, until about a dozen subdomains have been registered.

Action: 16.7 NCC
To offer to serve as temporary registrar for top level domains in Europe. Contact IANA.

18.2. Database working group (Wilfried Woeber)

Chair: Wilfried Woeber
Scribe: Daniel Karrenberg

The proposed agenda was accepted.

The new Database Software

Marten Terpstra provided a detailed report on the current state of the DB-Software, both from a software point of view as well as from the deployment point of view. The slides for this presentation can be found in the presentations directory in the RIPE document store:

  • ftp.ripe.net/ripe/presentations/ripe-m16-marten-DBDETAILS.ps.Z

The new software is in production use since Friday September 10th and until now there have not been any major problems. During the discussion it was again stressed, that the current implementation is built to do syntax checks according to the object description and not according to common usage practice. The RIPE NCC welcomes suggestions as to where the syntax checking needs to be changed.

Currently those attributes marked illegal are deleted from the database, but not the objects as a whole.

One of the things discussed was how to avoid a possibly large number of bounced submissions. One way of doing this is to obtain (part of) the new software to do the checking locally. The betaversion of the software is available, although it probably makes more sense to wait for the official software distribution which will provide a dedicated syntax-checker.

A syntax checker daemon at the NCC was also suggested to remove the requirement to run the software locally. A template generator was suggested as well. This needs more discussion on the mailing list.

The NCC has run a syntax check on the whole database and was asked to make the syntax error output available.

Daniel Karrenberg gave an overview on the "Authorization and Notification of Changes in the RIPEDB" proposal. It was decided to implement it as proposed. Proposals on how to better support the distribution of the update process are very welcome.

The discussion of implementing "guarded attributes" revealed concern about the possibility to delete an object that has a guarded attribute. It was agreed that the implementation will not delete any object as long as guarded fields are present. This will force removal of guarded fields from the object before the delete operation is accepted. The database wil NOT keep track of "pending deletes", thus the delete request has to
be submitted again after removal of the guarded attribute(s). The NCC will look into ways to notify guardians of failed deletes. The originator of the delete request will of course be notified.

The procedure to convert existing information into guarded information (eg.aut-sys: for the network object) was agreed as follows:

  • the NCC moves the information from the database to the guardian files initially the NCC is the guardian
  • as soon as possible, responsibility for the files is transferred to the real guardian(s)

In instances of where two or more guardians want to set an attribute which can only have one value, the current state of the attribute will not be changed and all guardians concerned will be notified.

Example:

The aut-sys attribute of network 193.193.193.0 in the database is AS193. AS4711 adds this net work to his guardian file. At the next database cleanup all guardian files will be examined.

  • If the AS193 guardian file still contains 193.193.193.0 a conflict exists and the current database state prevails: AS193 will remain.
  • If 193.193.193.0 has been removed from the AS193 guardian file no conflict exists and AS193 will be replaced by AS4711.

Similarly the aut-sys attribute will remain undefined if it is undefined and two guardians add it simultaneously.

Since the cleanup runs every 24 hours guardians involved in a change should coordinate their changes such that they are done in the same 24 hour period.

18.2.1. Database (and Software) Documentation

The documentation will be structured to consist of:

  • object definitions and general background information, by Wilfried Woeber and NCC and available before the end of 1993
  • software documentation, provided by the NCC asap
  • maintainer's guide (for e.g. the Local-IRs)
  • additional input and support is expected from the Local-IRs and others
  • Secondary Server Guide

Additional input and support is expected from the Local-IRs and others. The Objects Definition and the SW-Documentation get priority, in the listed order.

18.2.2. Unique Person Handles

Given the growth of the database, it is urgent to distinguish person objects for people with the same name!

After another round of thorough discussion it was decided that RIPE suggests a global scheme to the InterNIC. One of the possible solutions is to reserve a sub-range of the NIC handle space for RIPE allocation, e.g. XY3000-XY5000. If this approach fails, then WW and the NCC will propose a unique identifier scheme for RIPE (aka "RIPE Handle").

18.2.3. Objects Review and Proposals

The proposed CLNS routing object (dom-prefix:) was presented by Henk Steenman and accepted. Some minor loose ends how to check for syntax and maybe semantics of the hexadecimal strings that are the CLNS address-prefixes have to be ironed out (Henk Steenman and Tony Bates). The longstanding proposal to build a "Resource Object" was formally withdrawn.

Then the discussion moved on to agree on how to make a smooth transition from ripe-60 to the ripe-81 format to describe the routing. The steps are as follows:

  • as soon as the guarded fields are implemented, ripe-60 entries will no longer be accepted.
  • ripe-60 information is converted to ripe-81 format.

when there are no longer any operational dependencies then all ripe-60 data will be removed from the database.

Jean-Michel Jouanigot is the focal point for the ripe-60 --> ripe-81 transition coordination.

Also the gateway: field for the network objects was confirmed to be obsolete and can be removed from the database.

18.2.4. DB Exchange format(s) and procedures

The circulated document about the agreed interchange format was briefly reviewed. Everything seems to be in place to actually start exchanges with the InterNIC. There was consensus that this has a very high priority. Currently the recommendation is not to try to get the various databases in sync manually.

18.2.5. DB usage conventions and recommendations

Quite some time was spent to discuss the connect: attribute of the network object. It was agreed that the only well-defined value is LOCAL. This attribute should eventually be obsoleted. Later it was noted that it is currently mandatory and should be made optional after one round of mailing-list discussion.

However, there is a need for the functionality, maybe the community: approach is the right way to go (e.g. create community NSF). Still there is concern that some of the approaches that are obvious for "old hands in networking" are not necessarily useful for the end-users. Maybe the tools coming out of the PRIDE project can help to solve this problem. NCC to start the discussion with a rough proposal before the next meeting.

18.2.6. whois++ by Peter Deutsch et.al.

The whois++ project was briefly mentioned, although the DB group had too little information to actually discuss the issue.

18.2.7. AOB

It was mentioned that there is a need for new tools to support the Local-IRs. This needs more discussion on the e-mail list.

Action-List:

Action: 16.8 NCC
Put together a consolidated distribution of the new DB software, including a separate syntax checker for objects.

Action: 16.9 Wilfried Woeber
Start discussion on the DB mailing list on new tools needed, e.g. template generator, syntax checker daemon at the NCC.

Action: 16.10 NCC
Make the error reports form the DB syntax check publicly available.

Action: 16.11 NCC
Implement changes to DB procedures according to the proposal "Authorization and Notification of Changes in the RIPE-DB" by Daniel Karrenberg.

Action: 16.12 NCC
Implement changes to DB procedures for the guarded attributes according to the agreement.

Action: 16.13 Wilfried Woeber and NCC
Produce documentation about "Background, History and Object Definitions" for the new database software before the end of 1993.

Action: 16.14 NCC
Produce "Software Documentation" for the new database software asap.

Action: 16.15 NCC
To approach the InterNIC to agree on the use of a subrange of the global NIC-Handle space for RIPE usage.

Action: 16.16 Henk Steenman and NCC (Tony Bates)
Implement the dom-prefix: object for CLNS routing, after tightening the syntax definition
and semantics of the CLNS-address hexadecimal string.

Action: 16.17 Jean-Michel Jouanigot
To coordinate the transition from ripe-60 to ripe-81 format for routing description.

Action: 16.18 NCC
Try to actually get the synchronisation of the various databases going, using the recently agreed DB Exchange Format.

Action: 16.19 NCC
Start discussion on the mailing list by providing a first proposal how the functionality of the badly defined connect: attribute could be replaced (with the target group of the end-user in mind!) by using e.g. community: and other forthcoming tools from the PRIDE project.

18.3. Connectivity (Milan Sterba)

18.3.1. ECE Connectivity Update

  • DFN announces a 64 kbit line between DFN office in Berlin and Riga Univ.
  • Albania has now a first MX entry in the DNS

Roman Adamiec: Polish connectivity

  • Warsaw is now a full dual homed RBS (2 MBit satellite connection to Stockholm paid by NASK, 128 kbit to Vienna)
  • a project of a Warsaw MAN based on ATM is under way (partners are not only academia and PTT's but also gov. and com. institutions)
  • plans to upgrade majority of intercity lines to 64 kbit (these lines do not bear an "academic" AUP)
  • major nodes are now being upgraded to professional routers

Balazs Martos: Hungarian connectivity

  • estimated need for connectivity to EBONE for 1994 is 128-192 kbit
  • Budapest has now a very meshed FDDI MAN operational
  • 6 major cities are now connected to HUNGARNET by 19.2 lines (upgrades to 64 kbits planned)
  • 300 institutions are connected over IP over public X25 (using mostly PC routers and cisco routers in concentration points)
  • the AUP on HUNGARNET allows only for R&D traffic (no matter whether private or public institution is connected)
  • the HEPnet line to CERN is subject to strong usage restrictions imposed on the hungarian side of the line (this is no longer a problem, the line is only 9.6 kbit
  • two ECE IXI lines running (to Bern at 64 kbit and to Prague at 9.6) (used for tunnelling IP/X25
  • problems mentioned on the London gateway to EBONE)

Tomaz Kalin: IXI

The contract covering ECE IXI has been modified as to cover also native IP access. ECE countries are now free to negotiate migration to native IP with the provider. EC financing for ECE "IXI" in 1994 is under negotiations

Petr Kral: Czech connectivity

  • CESNET now covers ten major academic cities with intercity connections migrating to 64 kbit. Other connections are planned for later this year
  • CESNET now has 64 kbit lines to Vienna and Bonn EBS's and an ECE IXI line to Amsterdam (upgraded to 64 kbit only recently) emphasis now given to user support and user services
  • the 19.2 line to Banska Bystrica carries an important part of the international traffic of Slovakia
  • FDDI MAN projects exist in Prague and Brno areas

Tomaz Kalin: Slovenian and Croatian connectivity

  • Zagreb has its own 19.2 line to Vienna
  • the line from Ljubljana to Vienna should be upgraded to 128 kbit
  • there is a 19.2 line between Zagreb and Ljubljana carrying IP and DECnet

Rob Blokzijl suggests to stop doing the ECE connectivity map and invite ECE countries to store their maps into the RIPE map store

Tomaz Kalin reports on joint government level networking workshops organized by RARE and NATO in Budapest in October and later planned for Moscow (April 1994?)

18.3.2. Connectivity Data Store

Final version of the CDS fact sheet guidelines will be produced including comments from RIPE members and stored as a RIPE draft

An umbrella hypertext document will be produced which will describe the CDS as a whole and rules for contribution and will contain pointers to fact sheets and maps of:

  • networks operating on international scale
  • countries and networks operating in one single country

Fact sheets and maps will be stored as they are submitted (unless they are not conforming to the CDS guidelines) and will stay under the responsibility of the contributor

The CDS is open for all contributions from networks operating in Europe. A first solicitation for contributions will be done to populate the CDS with first data.

Contributions will be sent to [email protected]

The technical maintenance of the CDS belongs to the NCC

The CDS should be accessible by WWW as a primary method but also by gopher, ftp and e-mail

Action: 16.20 Milan Sterba
Produce a revised version of CDS guidelines and submit it as a RIPE draft

Action: 16.21 Milan Sterba, Anne Lord
Produce the umbrella hypertext document for the CDS

Action: 16.22 Milan Sterba
Solicit first contributions to the CDS.

Action: 16.23 NCC
Create the [email protected] alias and establish procedures to integrate new CDS contributions and maps to the CDS.

18.4. DNS Working Group (Francis Dupont)

Chair: Francis Dupont
Scribe: Lars-Johan Liman

18.4.1. Opening

Francis Dupont opened the session. Lars-Johan Liman was appointed secretary.

18.4.2. Old Items Including a Second Name Server in Europe

The possible need for a second root name server in Europe was discussed. Of the 1.4 million hosts now registered, 400,000 are located in Europe. This ought to cause a lot of unnecessary traffic across the US lines. Suitable location for a second European root server was discussed, and suggestions were Paris (GIX pilot), Amsterdam (many IP providers join there), and Vienna (many connections to the fast growing Eastern Europe).

It was decided to contact the Connectivity WG to check if Vienna would be a suitable site, taking future plans for Eastern Europe into account, and if so, and if someone in Vienna is willing to host and tender a root name server, the WG would suggest Vienna for a second root name server in Europe replacing one of the existent US root servers.

18.4.3. IPng support

Discussions on IP Next Generation are taking place in the IETF, but no clear decisions were heard of, and therefore it seemed useless to get lost in discussions on software support for it.

18.4.4. Software and Tools

Experiences with the new versions of the name server kit (named) showed that it is not very stable. Version 4.9 is clearly broken in several places and should not be recommended for use anywhere. Version 4.9.1 is a BSD 4.4 Unix special version. 4.9.2 is much better than 4.9 but still not good. It should not be used for production in "unattended environments".

The question was raised whether there is a name server for the Microsoft Windows NT platform. No answer was found.

18.4.5. Input for Piet Beertema's Internet Draft on DNS (BIND) ConfigErrors

the paper was discussed in detail and approved unanimously. A note from Rob Elz on the subject of reverse mapping for the 127.0.0.1 local host address was circulated and approved to be incorporated in principal in the draft.

The WG would like RIPE to recommend that, if possible, local IP registry is performed by a nonpolitical 3rd party organisation, not a service provider. This to avoid any chance of political friction.

18.4.6. Closing

Francis Dupont thanked everyone for their contributions, and closed the meeting.

18.5. Routing Working Group (Jean-Michel Jouanigot)

Chair: Jean-Michel Jouanigot
Scribe: Gilles Farrache

Previous minutes; action list; agenda

Open action items comprise the following:

Action: 15.19 Peter Lothberg
To draft document on Inter-AS local information.

Action: 15.21 Daniel Karrenberg/Jean-Michel Jouanigot
To draft a document on colouring.

The Agenda was approved.

18.5.1. Ripe-81 status

Tony Bates (RIPE NCC) presented the RIPE-81 statistics. Among the 103 known ASes in Europe, only 49% are registered in the RIPE database, and among these 49%, only 60% are syntactically correct. The fact that some of the entries are syntactically incorrect is due to the lack of syntax checking in the previous version of the RIPE database software. The slides of this presentation are available from

  • ftp.ripe.net/ripe/presentations/ripe-m16-tony-RRSTATS.ps.Z

Service providers are urged:

  • For those having already registered their ASes, re-send their entries, so that all entries will be syntactically correct,
  • For all the others, send their entries in the RIPE-81 format.

It is extremely important that all ASes are registered as soon as possible. The PRIDE project and the GIX route server cannot be successful without this information.

Once the ASes are registered in the RIPE-81 format, the networks themselves will have to be tagged. This is not yet possible, but will be in the very near future (see database Working Group).

18.5.2. Guardians and procedures (brief)

Marten Terpstra gave a short introduction on the guardian mechanism for the 'aut-sys' and 'community' tags. This mechanism will be applied as soon as the Database working group agrees with it (see Database working group minutes). Three questions are addressed to this working group:

  • What will happen to the current 'aut-sys' tags already stored in the Ripe database?
  • How will a conflict between two guardians be resolved?
  • How will the database software react if somebody tries to delete a guarded network entry?

18.5.3. Use of Ripe-81; conversion of Ripe-60

Ripe-60 objects are no longer accepted. These objects have to be converted into the RIPE-81 format, but this should be straight forward. As soon as the NCC is able to tag networks with their AS number, the current users of Ripe-60 should convert to Ripe-81.

Action: 16.23 Jean-Michel Jouanigot
Coordinate this conversion from ripe-60 -> ripe-81.

18.5.4. Ripe-81 enhancements

DMZ

There was only positive comment on Daniel Karrenberg's proposal for DMZ networks attributes, that was sent to the list on May 93: "Description of Inter-AS Networks in the RIPE Routing Registry" (ptraceroute issue). This paper will therefore be included in the next revision of the paper.

18.5.5. Colouring

Several ideas were presented to increase the granularity of the policies expressed in RIPE-81. RIPE-81 only deals with ASes, but ASes may contain several "sub ASes", that have to be differentiated within another AS: colours. Colours are internal to an AS, but could be exported to another AS for its own purpose. An example of this could be that a network tagged with a special colour would mean "Please do not aggregate this network", in the CIDR context. The entries in the Ripe database would then look like:

  • aut-num: AS1111
  • as-in: AS1234 100 AS7890/<16 bits representing the colour>
    [...] and
  • netnum: 199.199.199.0
  • aut-sys: AS7890/<16 bits representing the colour>

BGP4 has the possibility to carry this 16 bits information.

Do to the lack of time, it was decided to go on with the discussion on the list. Action is still on JeanMichel Jouanigot & Daniel Karrenberg to write a draft on colouring (previously action 15.21)

Inter-AS Local Information

Due to the lack of time, this item was postponed and should be discussed on the list. Action remains on Peter Lothberg (previously action 15.19):

  • Multi-homed, multi-inter AS connection
  • Local inter-AS information.

CIDR

Introduction

The basic principles of CIDR were briefly presented. Services providers are encouraged to read the RFC 1467: "Status of CIDR Deployment in the Internet (Topolcic) Aug. 93".

Discussion

Stephan Biesbroeck sent a case study on the list on May 1993 and Duncan Rogerson presented and distributed a text explaining the impact of CIDR on their network.

A few remarks were made concerning the availability of CIDR capable code in the routers: this code should be widely available before any "real" route gets aggregated.

BGP4: What's new?

Peter Lothberg presented the BGP4 principles and emphasized the differences between BGP3 and BGP4. As an application example, he discussed the EBONE plans concerning BGP4 usage. The presentation is available from him.

18.6. NIDUS Working Group (Nandor Horvath)

Chairman: Nandor Horvath
Scribe: Anne Lord

Joyce Reynolds IETF User Services Area Report

The following fyi documents have been updated/issued:

  • fyi 2 - FYI on a Network Management Tool Catalog
  • fyi 19 - FYI on Introducing the Internet
  • fyi 20 - FYI on "What is the Internet?"
  • fyi 21 - A Survey of Advanced Usages of X.500

GARR on-line Network Resource Guide

Giuseppe Romano presented the results of the work done by GARR on this project and there followed a general discussion. The tool is built around extended WAIS searches. A document summary and access method to an actual document are the result of a search. It was noted that developing the project involved two particular areas of work which are
ongoing:

  • developing and refining the tool
  • completing the resource description templates

Currently, completing the templates is a manual process and labour intensive.

Future plans for this project were discussed and it was agreed to contact related IETF working groups (Jill Foster) and to draft a proposal outlining the project which would be submitted to the RARE RTC for evaluation. The draft proposal would be circulated to RIPE and the NIDUS working group for comments.

18.7. RIPE NCC Review and Activity Plan BOF (Rob Blokzijl)

Based on the outcome of the RIPE NCC review, a new Activity plan for the NCC has to be written. The results of a first round of discussions during two BOF sessions at this RIPE meeting identified the following elements for the new activity plan:

  • a detailed description of all technical and administrative activities currently undertaken by the NCC.
  • an important new element will be the involvement of the RIPE NCC in technical development work as defined by approved joint RIPE/RARE projects.
  • the lifetime of the Activity Plan must be clearly defined.
  • review procedures must be defined.
  • a mechanism for change control must be defined.
  • Mike Norris suggested that the final report should incorporate the old RIPE NCC Activity Plan (Doc ID: ripe-035).

A first draft of the activity plan will be written based upon the above conclusions, and circulated to RIPE for discussion. The aim is to finalise and approve the new plan during the next RIPE meeting.

Action: 16.24 Rob Blokzijl
To finalise the RIPE NCC Review draft report and document and send the reportto the ripe-list for approval.

Action: 16.25 Rob Blokzijl
Comments received will be incorporated into a first draft and circulated to the ripe-list for further comments. Deadline: next RIPE meeting in January 1994.

19. Next RIPE meetings

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

  • January 24-26th, 1994 - Amsterdam
  • May 16-18th, 1994 - Amsterdam

20. AOB

20.1. RARE CoA

The next CoA meeting is the last CoA to be attended by Rob Blokzijl representing the HEPnet community. He will be replaced by a consortium from EKFA.

20.2. RIPE meetings

Concern has been expressed that the size of RIPE meetings has grown too large for efficient work to be done any longer. Rob Blokzijl agreed to draft a document on possible ways to reorganise the meeting

Action: 16.26 Rob Blokzijl
Draft document with suggestions on how to reorganise RIPE meetings. Circulate to the RIPE list for discussion

21. Closing

Rob Blokzijl thanked the participants for attending and declared the16th RIPE meeting closed.