Skip to main content

RIPE 4 Minutes

1. Opening

IBM apologised for not being able to attend the meeting but reconfirmed their support for the RIPE initiative.

2. Minutes of Last Meeting

A draft of the minutes was distributed and accepted after a number of corrections were made.

3. Progress Reports from the Task Forces

3.1. Task Force 1: Connectivity and Routing

Thomas Lenggenhager reported that he had updated the IP connectivity maps.

1-1: Inventory of International IP Connectivity. Bernhard Stockman and Anders Hillbo reported on the work they had done. This involved the continued collection of data and further work on the drawing of maps. The introduction of nameservers in Italy has made a lot more data available. At least fourty transatlantic lines have been found, mostly between ESA and NASA.

Maps have been made of most participating countries and are available for anonymous ftp from nordunic.nordunet.se French map has been improved and as yet nothing has been done for Germany. The intention is to present all the national maps and in conjunction with the international maps.

It was reported that some very interesting work had been done by MERIT. This has produced a set of tools for displaying geographical maps in conjunction with a network database. Tom Livit(**) of the "Technology Working Group" has said that these are working and available.

Some comments were made on the Topological Database in the US and the need for a common Database format. It was agreed that all the available maps would be distributed by the end of the meeting. Thomas Lenggenhager asked for further data to be sent to him so that additional map making could be done.

A need was expressed for information on the end points of the transatlantic entries in the US and also for the US-Japan links. The discussion concluded with the statement that there was now plenty of data but in a very raw format, and that tools will be needed to make it presentable.

1-2: Inventory of unconnected national IP infrastructures

1-3: Inter-continental interconnectivity. The state of BGP (Border Gateway Protocol) is currently subject to change and therefore cannot be used in RIPE at present. The wide variation in speed of transatlantic lines introduce problems in balancing load properly, this is further complicated by restrictions on the use of individual lines.

See Section 6 of the agenda for futher discussion of Routing protocols in RIPE.

1-4: International routing scheme design

1-5: Monitoring of Routing Coordination

3.2. Task Force 2: Network Management and Operations

2-1: 'whois' database. Daniel Karrenberg reported on the progress of the RIPE Database of networks and responsible people. The number of networks included was 478 and the number of people was 400. 276 of the networks were listed as local only with 202 RIPE networks. Some surprise was expressed at the size of the count. It was reported that there existed a number of inconsistencies between the CWI routing tables and the database. In addition a number of local networks were incorrectly marked as RIPE networks. There was general agreement that the database is a very useful management tool.

The proposed query by mail facility had not been implemented due to a lack of interest. There was some discusion on the format of the RIPE Database entries and a presentation of the changes made since the last meeting. James
Barr reported work done transferring the RIPE Database into X.500 format.

2-2: Operational contacts infrastructure. No progress.

2-3: Security notification procedure. No progress.

2-4: Common operations procedure. Only limited progress made in this area. More information is needed before routing can be done effectively.

2-5: Gathering of operational statistics. Bernhard Stockman gave a presentation on his collection of operating statistics. This seemed to be quite useful and the gathering could see a number of interesting events from the histograms presented. There was some comment made on the possible confusion of IP with DECnet traffic.

The latest CISCO software can provide a traffic matrix with byte and packet counts for traffic routed to specific interfaces. This is useful for tracking strange routing and spurious traffic by to broadcast addresses and root name servers.

A problem was reported with the V8.0(9) CISCO SNMP server software. GET NEXT requests would omit some variables randomly. Daniel Karrenberg reported that using SNMP to get the traffic matrix was also rather slow and reported developing some querying software that worked much more quickly by logging into the CISCO directly.

Marten Terpstra estimated that between 18 and 20 thousand hosts had been counted using the nameservers. 13000 had actually been seen, this did not include counts for Italy and Unido connected hosts. Italy now has nameservers and a more precise estimate is hoped for.

There was concern that the count was not representative and that the HINFO Records ought to be examined so that the different machine types could be classified. Unfortunately this seems impractical due to the number of entries with no such field and the effort required would be discouraging.

There was the question of how much traffic could be generated by the statistics gathering. The kind of problems suggested by this could be combatted by local measurements being collected and examined by a global coordinator.

2-6: European Network Information Centre.

2-7: Networking tool box. It was reported that the "NOC Tools Catalogue" would be made available by anonymous ftp from mcsun.eu.net in the RIPE directory.

2-8: Centres of expertise. Some advice was given on how to get help from CISCO.

3.3. Task Force 3: Domain Name System

3-1: Namespace administration database. Arnold Nipper reported writing to domain administrators asking for data. No response had yet been received from Germany, Italy, Switzerland and the UK.

3-2: Coordination of secondary name servers. No progress.

3-3: Framework for secondary name servers. A need was expressed for a dialogue with the US about the Coordination of network databases, a list of Route name servers and a list of recommended name server software.

A discussion ensued on the use of MX records in the Domain Name Server. It was thought that a policy must be developed because these cannot be given for everywhere. (**)

3-4: Recommended Domain Name Server Software

3-5: Mailrouting and MX Record Study

3.4. Task Force 4: Formal Coordination

4-1: Template for IP coordination agreements. There is a need for general and bilateral agreements. Olivier Martin was asked to have CERN lawyers look at the drafts.

4-2: Formal contact with CCIRN and FRICC. A decision on formal contact has been left until an agreement with RARE has been reached. It was reported that RARE has not made much progress in this area. Some contact had been made with the Federal Network Council (FNC), the successor to FRICC and now the US part of CCIRN.

4-3: Formal contact with other organisations. As for [4-2] above. Contact with the IETF was discussed under item 5 of the agenda.

4-4: Legal status of RIPE. Daniel Karrenberg volunteered to propose a clearer internal and external structure of RIPE under item 6 of the agenda.

4. RIPE and RARE, Status Report

Rob Blokzijl reported that he had been contacted by Kees Neggers the new vice chairman of RARE. RARE has delegated Kees Neggers and Christian Michan to coordinate the relationship between RIPE and RARE.

The basis for interworking will be that taken by the recommendations given in the "3 Wise Men" report. RARE hoped to have a workable solution ready by the second half of May. In this regard, it was decided that no further action will be taken by RIPE until then.

5. Mechanics of RIPE Coordination

Daniel Karrenberg gave a presentation dealing with the administartive needs of the RIPE organisation. A discussion followed on the what model should be used, either a centralised or a distributed framework. What became clear
from this was the need for some sort of formalised body for performing the functions of a NIC.

A fair concensus was reached on the needs expressed and Bernhard Stockman volunteered to present a formalised proposal by the next meeting.6 RIPE routing in view of IXI, EASInet, etc.

6.1. Proposal for Backbone

Anders Hillbo presented a framework for a RIPE backbone developed by a number of the participants. The basic model was a straight connection between KTH-CWI-CERN-IT, with connections to this backbone from the other participants. Each party will have one primary entry point with possible secondaries. It is necessary to increase the speed of parts of this backbone and in fact there are already advanced plans to do so. Specifically, Rob Blokzijl reported that the CWI - CERN part would be upgraded this year.

The idea of using EGP provoked some opposition because it is thought this would not make efficient use of existing lines. The possible use of CISCO's IGRP may mitigate this problem until BGP becomes available. It was commented that existing connectivity should not be compromised as this would be detrimental to the whole initiative. Hank Nussbacher mentioned that CISCO's could use more than one routing protocol and distributed a paper explaining how to manage this.

There was feeling that a more complex topology was needed which would include INRIA. This was provoked by the fear that some existing lines would become topologically useless.

The tables of the backbone routers would need to be syncronized and a filtering table from the RIPE database would be required. Knowledge of backup routes is also required. In addition the physical location of backup lines would have to be known and different from the primary. Mats Brunell said that there is a need to upgrade some of the lines to make efficient use of the proposed topology and that a document should be written to clearly illustrate the technical arguments.

Antonio Blasco Bonito proposed having a small group responsible for the routers.

The proposal for routing on this backbone did not cover the transatlantic links. This problem will probably require a reduction in the number of such links and an increase in speed of those remaining. Some comment was made on the possibility of more transatlantic fat pipes.

In conclusion, a Backbone Routing group was formed to draft a firm proposal, with the provision that no existing or future investment would be wasted, see table below.

6.2. IXI

A number of options were discussed for the place of IXI in RIPE. An overall policy towards its use would be hard to develop due to its unclear future, unknown reliability and unclear future financial costs. Some IP links over IXI were quite serious such as from EIRE to NORDUnet and RIPE to Vienna. A proposal was also made to use IXI as a set of temporary, non-critical backdoor links.

EARN users can make use of IXI lines for whatever purposes provided they have an additional alternative route and so IXI could not be used as a replacment. It was reported, however, that EARN may remove this restriction.

NORDUnet(Convener) Anders Hillbo CWI Daniel Karrenberg INRIA Francis Dupont CERN Olivier Martin GARR Antonio Blasco Bonito CMD Rudiger Volk

Table 1: The Backbone Routing Group

The policy taken was to treat IXI as a pilot and make clear that RIPE will take not responsibility for the failure of these lines. A message will be sent to IXI-CC by task force 4 with the purpose of clarifying the current RIPE point of view.

7. Cooperation with IETF Working Groups

Mats Brunell discussed the progress of the US collaboration. Although the relationship between RIPE and the US has not been formalised, the technical relationship seems to work well. The US will not make any statements until it knows more about the European situation and would prefer to talk to RARE.

His feeling was, that while their network operations was not entirely adequate, both the engineering and general coordination were good. There was a need for more information and contact exchanges. Although Europeans are welcome at IETF meetings a need was expressed to have the other side come to RIPE meetings.

A need for a European Network Information Centre (NIC) was stated.

The US would like a single European address allocator and preferably RARE should be responsible for it. Daniel Karrenberg and Rob Blokzijl had no objections to this but emphasised that RARE must agree to RIPE handling all IP related issues, should designate a RIPE support officer, pay for RIPE activities and supply secretarial support.

The RIPE/RARE relationship must not look like a competition. The current terms of reference present no problems in this respect but require an additional item on the relationship. In addition RARE must be aware that RIPE is also open to non-research networks.

7.1. RIPE Task Forces - IETF Groups

Bernhard Stockman presented his plan for developing a better alignment between the RIPE working groups and the Internet Engineering Task Force (IETF) groups. There is some scope for the IETF to set up groups to complement the RIPE task forces. In addition he made a proposal for a task force 5 that would help map RIPE groups to IETF groups. The advantage of this strategy would be to give direct links between people working on the same problems in both communities.

A number of comments were made about the relative sizes and scopes of the respective groups. One problem was the lack of an US equivalent to RIPE Task Force 4.

Daniel Karrenberg proposed having a person to act as a formal liason point between IETF and RIPE, someone who would be very up to date on the current situation. He also thought that the link between the external routing groups needed to be very close the other links would be secondary to this.

Bernhard Stockman also presented his proposal for a new task force to help map RIPE on to the IETF groups. This was given the title "Statistics and performance of RIPE backbones" and Bernhard Stockman volunteered as coordinator, see table below. He also volunteered to finalise the proposal, taking into consideration the comments made. The new group was accepted by the gathering.

Mats Brunell mentioned that the IETF had documented its activities and these were available for US$40.

Money to fund the transatlantic cooperation could be allocated by CCIRN. An opertunity to discuss this would be at the EURO-CCIRN meeting on the 26th of April.

Bernhard Stockman(Coordinator) 5-1 Tools for traffic data 5-2 Data analysis 5-3 Performance 5-4 Benchmarking 5-5 Advanced protocols for measurements of line occupancy

Table 2: Task Force 5: Statistics and performance of RIPE backbones for travel.

8. EARN NJE Over IP

A number of the EARN members present reported on the future of EARN and how its use of IP may develop. It was stated that their presence at the RIPE Meeting had much to do with deciding their own future.

EARN has plans to migrate to both OSI and IP, how these would compete or supplement each other was not yet clear. In addition a number of reasons exist for not migrating totally to IP. Firstly, EARN allows all protocols over its lines but only NJE and OSI are allowed over DIGITAL funded lines. In addition EARN will only use IP with those machines supporting it. There was a plan to run NJE over IP with IBM/VM machines. There was, however, no similar plan for IBM/MVS because there are so few people competent to port TCP/IP on to these machines.

The mixing of NJOSI, NJIP and NJE were thought to be very difficult. In addition there was the problem of having both OSI connection oriented and connectionless services.

It was mentioned that "joiners" JNET software will work over the two ypes of service and software was available from the Hebrew University.

To implement this, EARN plan to have CISCO connectivity rather than IP connectivity across Europe. This will be made possible by version 8.1 of the CISCO software which will support SNA. In addition EARN's current "national node" topology may not survive and would likely be replaced by a balanced arbitrary connectivity network.

Hank Nussbacher reported that the EARN requirement for members to have a 9.6 leased line had been dissolved.

There was the question of what EARN will eventually manage. There was the need to break the monopoly held by the PTT's by renting lines and managing their own technology. The distribution of services will be done nationally but not necessarily over dedicated lines.

The effects of changes in the COCOM rules on networking were discussed. It was pointed out that the rules had been weakened rather than removed and so the scope for expansion was still limited. Some present noted that the interpretation of the rules was difficult. For example the ban on interactive traffic may suggest that IP could not be used. There was also a feeling that many of the restrictions were in fact impractical.

The problem was one of "no knowledge transfer" and in practice this seemed to mean restricting access to Supercomputers. A number of those present expressed the opinion that the protection of Supercomputers was the responsibility of their operators and not the networks.

In addition the third class of COCOM countries suggests that one set of problems do not apply to countries like the GDR and Poland, that do apply to others such as the USSR.

It was reported that there will be a vote shortly for the EARN membership of Chech-slovakia, the USSR, Bulgaria and Poland. The current lack of infrastructure within these countries suggested that a coordinated effort to develop and share lines would be the most efficient approach.

It was reported that NORDUnet was preparing for links to the Baltic states. Germany had no plans on East European connections although a 4.8bps line to the GDR has existed since summer 1989, carrying interactive traffic.

Other difficulties included the ban on the transfer of hardware and soft ware. It was mentioned that many of the network protocols are in fact In ternational Standards and therefore restrictionless, thus interworking would be possible despite the limitations on product transfer.

10. Date, Place and Time of Next Meeting

The next RIPE meeting is planned for 18-19 june 1990, at CERN. The meeting will begin at 14:00 on the 18th.

11. A.O.B.

Glossary

  • BGP Border Gateway Protocol
  • CCIRN Coordinating Commitee for Continental Research Networks
  • DNS Domain Name System
  • EGP External Gateway Protocol
  • FNC Federal Network Council
  • FRICC Federal Research Internet Coordinating Commitee, now defunct and replaced by the FNC.
  • HINFO DNS Host Information Record
  • IETF Internet Engineering Task Force
  • IXI-CC IXI Coordinating Commitee
  • IGRP Intermediate Gateway Routing Protocol (CISCO specific)
  • MX Record DNS Mail eXchange record
  • MERIT NSFnet operators
  • NIC Network Information Centre
  • NJE Network Job Entry (EARN/BITNET network protocol)
  • NOC Network Operations Centre
  • RIPE Reseaux IP European
  • RARE Reseaux Associates pour la Researche European
  • SNMP Simple Network Management Protocol
  • SMTP Simple Mail Transfer Protocol
  • TWG Topology Working Group (IETF Working Group)