Skip to main content

RIPE 14 Minutes

1. Opening

Rob Blokzijl welcomed the participants to the 14th RIPE meeting at the Czech Technical University in Prague, Czech Republic. The planned audio broadcast of the meeting was announced.

1.1. Approval of the agenda

The agenda was approved.

1.2. Papers tabled

  • Agenda for the 14th RIPE meeting
  • RIPE Quarterly Report, Issue 3, December (only 10 copies for viewing only)
  • Draft IP Network Number template proposed by JNT
  • Draft IP Network Number template proposed by RIPE NCC
  • RIPE NCC Report (slides available on ftp.ripe.net in file ~/ripe/presentations/ripe-m14-dfkNCCREP.ps.Z)
  • Working Group Agendas
  • Map of International IP connectivity in Central & Eastern Europe
  • RIPE Technical Presentations information sheet

2. Welcome (Prof J Hlavicka)

Professor J Hlavicka from the faculty of Electrical Engineering of the Czech Technical University welcomed the participants to the 14th RIPE meeting.

3. Minutes of the last meeting

3.1. Approval of the minutes

The minutes from the 13th RIPE meeting were approved.

3.2. Review of the action list

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

Action: 13.1 Bob Day and Daniel Karrenberg
Align the common explanatory document about IP number registration and the common template

Action: 13.2 Bob Day
Circulate draft of an explanatory document about IP number registration

Action: 13.3 Marten Terpstra
Changes in the database format. Coordination discussions with US counterparts are ongoing

Action: 13.4 Marten Terpstra
To progress GSI/Merit/RIPE NCC exchange format discussions

Action: 13.5 Milan Sterba and Geza Turchanyi
Evaluate and consider nature of information for NIDUS

Action: 13.6 NCC
To include the operational contact attribute in all object definitions besides persons

4. Global Internet Exchange - Progress Report (P Lothberg)

A proposal for a Global Internet Exchange (GIX) at the IEPG in Washington in November 1992 was made and accepted. The GIX is a point where IP service providers can exchange traffic and routing information. Consistent routing information will be provided by a
number of route servers. A route server for European destinations will start pilot operatoins shortly. The RIPE NCC will act as the focal point for the development and implementation of the European route server and the Routing Registry (see point 5.2).

What is Mae-East?

  • Metropolitan Area Ethernet (East Coast)
  • Basically a MAN based 10Mbps bridged ethernet
  • Managed by Metropolitan Fibre Systems (MFS), a Washington D.C. based company.
  • Provide Cheap cost-effective 10 Mbps attachment to customers in the D.C. area.
  • Several IP service providers have attachments to Mae-East
    • Alternet
    • Sprint / ICMnet (large European provider)
    • SURAnet
    • PSI
    • NSFNET/ANSnet (status unclear)
  • Essentially a "proto-type GIX"
  • Extremely useful in terms of the RIPE NCC Route Server project
  • Allows Europe to present a "fairly" consistent routing picture to large portion of the service providers across the Atlantic
  • Can get some operational experience
  • Partners on Mae-East very keen to participate
  • Next step
    • Add the European Route Server

5. RIPE and RARE Technical Program

5.1. RIPE Representation in the RTC (Rob Blokzijl)

There has been one RARE Technical Committee (RTC) meeting since the last RIPE meeting. A new representative from RIPE is needed on the RTC. A proposal was made by Rob Blokzijl for Milan Sterba to be the new RIPE representative on the RTC. The meeting unanimously agreed and Milan Sterba accepted.

The RTC decided in November that a joint RIPE/RARE action was needed to ensure better European participation in the IETF working groups discussing IPv7 proposals. As a conclusion, RIPE members are urged to become more involved in the work of the IETF and join the relevant working groups.

Furthermore there has been a request from C. Huitema for RIPE members to become involved in the SIP Pilot.

5.2. Joint Projects

5.2.1. Route Server Implementation (T. Bates)

Background

  • IEPG initiative
  • Common forum for Internet co-ordination, November 1991, Santa Fe. GIX idea evolved
  • March 1992, San Diego - consensus on ideas and concepts
  • June 1992, Tokyo - paper
  • Proposal for Global Internet Connectivity by Almes, Ford and Lothberg

Concepts

Three main components for the project

  • The physical "GIX" itself
  • The "Route Server"
  • The "Routing Registry"

Global Internet Exchange (GIX)

  • Neutral Interconnect
  • Anyone is free to bring their router to the neutral interconnect
  • Anyone is free to peer with anyone else.
  • The interconnect is most certainly AUP free
  • The interconnect media type can be anything that allows each router to talk to any other router directly
  • Designed to enhance access and connectivity
  • Basis for cost-effective transit
  • Problems arise from such an open interconnect point
  • GIX
  • The "N-squared" routing problem
  • Possible asymmetric routing
  • Sub-optimal routing
  • Even routing loops
  • Need Coordinating

Route Server

  • Task to produce consistent routing information for various Autonomous Systems (ASes) within its represented region.
  • This is done by peering with selected routers at the GIX and filtering in-bound routing announcements then re-distributing these derived routes to other routers at the GIX
  • Uses a database to interact with when building configuration files
  • Does not take part in any packet forwarding itself
  • Make use of third-party BGP routes (i.e. NEXT_HOP)
  • Cuts down much of the administration for the various providers at the GIX

Routing Registry

  • Neutral run registry
  • Would manage routes for a region or domain (model used - Geographic)
  • Registration of routing policy information
  • Network owners register the routes rather than service providers
  • Some guidelines will be needed when there is possible conflict
  • For Europe, the current RIPE document may need to be reviewed
  • Database and objects must be easily derived for use by the route server

Implementation Plan

Week 5

  • Produce final concept paper and distribute
  • Develop a procedure paper for service providers
  • Start to populate RIPE database with needed info

Week 8

  • Pilot an operational European Route Server at "Mae-East" in Washington D.C.
  • Develop tools needed for Route Server / Routing
  • Registry interaction.

Week 9

  • Start work on any needed enhancements
  • Start work on multiple route server interaction

Week 17

  • Amsterdam RIPE meeting - intermediate report

Week 26

  • Present final project report at Amsterdam IETF
  • Summarise and plan at any future work needed

5.2.2. Generic Internet Service Specification (T. Bates)

Background

  • Joint project between RARE TC/RIPE NCC
  • Close liaison between RTC and RIPE community. Bernhard Stockman appointed as liaison between RTC and RIPE
  • Open project
  • No Hidden agendas
  • Should not be seen in any way as a competitive / political document
  • Not just a paper exercise
  • Should be worthwhile

Introduction

  • Production of a document describing a 'useful' Internet service
  • Should cover all aspects of Internet networking (i.e. from Network to Application)
  • Needs to look at Internet services from both sides of the fence:
  • Document itself will be generic.
  • Make reference to publicly available documents
  • RFCs
  • Internet-Drafts
  • Other relevant material (Books, etc.)
  • Aimed at openess
  • Need input/information from service providers - without this the spec' will not be of maximum use

Motivation

  • Vast growth of the Global Internet
  • Increase in applications base
  • Increase in PD software
  • Raised user perception
  • Vast Increase in Internet service providers
  • Various types or "levels" of providers
  • Very little material addressing the issue
  • IETF Operations Area
  • Internet-Drafts ?
  • "Mid-Level Networks Potential Technical Services"
  • Always a need for improvements in any service

Goals

  • Create a service framework for service providers
  • Give guidance where needed
  • Act a checklist
  • Creation of some standard definitions of service
  • Creation of categories or levels of service
  • Production of a useful specification

Way Forward - Timescales

  • Week 3 - Gather ideas and comments from RIPE members
  • Week 4 - Produce first draft and mail out to RIPE list.
  • Weeks 5-9 - Fold in all comments and re-send draft
  • Weeks 9-11 - Complete Specification in liaison with RTC
  • In final stages of project - Possibly present at Columbus IETF, review, take in last comments, and submit as a Rare Technical Paper and possibly an Informational RFC.

5.3. IPv7 overview; European Involvement (T. Dixon)

Tim Dixon gave a short overview of the proposals for IPv7. The proposals comprise:

  • SIP
  • PIP
  • TUBA

At the next IETF to be held in Columbus in March it is planned that a decision on IPv7 will be made. Currently a draft document exists (RTC93) 004 comparing the 3 proposals. Major differences occur in the area of IP addressing, but also in Encoding and Migration.

The need for pilot testing both before and after the final decision on IPv7 was stressed. RIPE members were urged to get involved.

Action: 14.1 Tim Dixon
Circulate overview on IPv7

6. The Introduction of CIDR and BGP-4 in Europe (P Lothberg)

Peter Lothberg gave a brief introduction to CIDR and BGP-4 as described below.

Routing is the invisible burden of IP networks. Where the old ARPAnet attached individual hosts the EGP model has a single backbone with only reachability information propagated. Routing policy is set by the backbone.

The BGP model

  • is without a backbone
  • each region defines their own AUP
  • BGP propagates the topology of the path
  • Policy based routing based on AS tags
  • Providing admin information about origin
  • moves limitation to the next hop architecture
  • can be used as an IGP for transit regions
  • protocol is slow overhead
  • works today - and is used by large networks
  • does classless interdomain routing
  • using class C space would exhaust routing
  • a short term solution is needed

CIDR RFC 1338

  • is a 2 part solution
  • concentrates on geographical assignment of C blocks via IP service providers
  • leads to routing aggegation
  • aim is to slow down routing table growth and deploy CIDR routing capability

What is CIDR doing?

  • Traditional class assignment of class A, B and C networks
  • CIDR is Classless Interdomain Routing

Restrictions

  • CIDR is less efficient with multi-homed regions
  • CIDR wont work if you change provider

Advantages

  • CIDR dramatically reduces the size of routing tables
  • 1st June 1993 is CIDR day ???
  • There will not be a BGP-5
  • The BGP WG agreed on IDRP
  • Multi IDRP supports IP, CLNS, Novell, Appletalk etc.

BGP-4

  • is classless routing
  • aggregation of networks and AS paths
  • IBGP weights handling

IGP

  • supports classless routing
  • IBGP
  • IS-IS
  • OSPF

7. Introduction to Technical Demonstrations (M Sterba)

The technical demonstrations comprised demonstrations of low cost, PC based routing equipment developed at Masaryk University, CS in conjunction with INRIA, FR. The three demonstrations comprised PC based routers developed for the following platforms.

  • IP/PPP - 64K kbps
    Contact Ivos Cernovahlavek or Jiri Novotny for more information.
  • IP/X25 - 64 kbps
    Contact Jiri Kaspar for more information.
  • IP/LAPB 2.5 Mbps
    Contact Michal Meloun for more information.

8. The Internet - your local radio station (C Malamud)

This presentation at the 14th RIPE meeting marked the debut and thus the introduction of Europe to "Internet Talk Radio". It will create a new medium by combining the programming of radio with the worldwide reach of the Internet. Internet Talk Radio will go beyond the random data archives and low-signal news bulletins that now characterize much of the information on the Internet to provide a regular stream of professionally producted news and information.

The Internet is getting support for Multimedia. Support for the dissemination of sound in the Internet ranges from beleeding-edge techniques such as multicast-based videoconferencing to more traditional protocols such as anonymous ftp and the MIME extensions to SMTP mail.

It is intended that Internet Talk Radio will use pre-programmed audio streams, since the bandwidth requirements (16kbps-64kbps) of sound are well suited to the current state of the overall Internet architecture.

It will be distributed through the Internet using traditional file transfer protocols with UUNET acting as the initial staging point. Local and regional network managers will transfer the files to a local spool area, and the "play" the data using techniques such as sending the data out to the local network through multicast groups or by exporting
the audio files as NFS file systems. It will also where possible, use the Multicast Backbone (MBONE) as a distribution medium.

Future Programmes

"Geek of the Week " will be a weekly interview show featuring prominent members of the networking community. The content of the show will be technical, focussing on networks and interoperability. The show will highlight the accomplishments and personalities of some of the more notable members of the Internet community. "Geek of the Week "will be
made possible through the support of Sun Microsystems and O'Reilly Associates. It will be 30 minutes long and contain a variety of short features to balance the interview material.

Along with "Geek of the Week", Internet Talk Radio will also begin providing coverage of major industry events, such asthe IETF or RIPE task forces, the Coalition for NEtworked Information and conferences such as INTEROP.

9. Report (D Karrenberg)

The RIPE NCC status report was presented by Daniel Karrenberg. It was based on the activities reported in the December quarterly report (available on ftp.ripe.net in file ripe/docs/ripe-docs/ripe79) which was published prior to the RIPE meeting. PostScript versions of the slides are available in file ripe/docs/presentations/ripe-m14-dfk-NCCREP.ps.Z.

What follows is a summary of the presentation.

9.1. Activities Report

DNS

The hostcount is published monthly and can be found in the RIPE document store in the subdirectory ripe/hostcount. The December hostcount was over 284.000 hosts in Europe.

Internet Registry

Terms describing all those organisations involved in assigning network numbers were clarified.

  • Global IR (formerly the DDN-NIC - but soon to be the Internic)
  • Regional IR (of which the RIPE NCC is responsible for Europe)
  • Local IR which comprise non-provider registries and provider registries (the former existing for organisations currently without service providers).

Details of class B and class C assignments made since the last quarterly report can be found in the appendix B and C of the aforementioned quarterly report.

Registry Actions at the NCC for the last quarter were:

  • 178 applications were received
  • 86% of applications were completed in one day
  • 97.4% completed within one week
  • 30% answered via electronic mail
  • NCC answers via fax wherever possible
  • all mail/fax correspondence in full-text database
  • also an increasing number of telepone call enquiries were received
  • increasing number of applications are being made direct to the RIPE NCC
  • and an increasing number of applications are being made directly to local registires
  • Common application form for IP requests throughout Europe needed which will facilitate and simplify the passing of the applications between registries.

Database

  • A first version of the global exchange format has been done for databases between DDN NIC, MERIT (NSFnet) and the RIPE NCC which the NCC can generate automatically.
  • The DDN NIC cannot yet accept automatic assignments
  • European assignments take a long time to get into the NIC database which leads to problems with NSFnet connectivity which will be alleviated by a change in MERIT procedure.
  • the establishment of the new INTERNIC will hopefully improve the situation in the future.
  • The number of network objects has increased due to the increase in IP network number assignments and is expected to increase further due to the new routing information.
  • NCC processes approximately 240 updates per working day.
  • There has been a full release of the database software
  • secondary database servers are encouraged

193.in-addr.ARPA delegation

  • simplifies maintenance of reverse mapping information in DNS
  • principle agreed
  • now needs to be implemented

Document Store and Information Services

  • RIPE and Internet information are the most popular sections of the document store
  • Whois usage is by far the most popular of the NCC services. This was particularly high for December

Other Activities

  • Working group support
  • Meeting support
  • Preparation for new projects

Summary

  • General improvements in all activities
  • good decentralised structure helps - but is not without problems
  • activity plan for RIPE now needs revision

9.2. Future of the RIPE NCC (P Van Binst)

Paul Van Binst (RARE Treasurer) presented the RIPE NCC budget from 1.4.92-31.3.93.

At the RARE CoA in Bratislava in September it was agreed that:

  • the RIPE NCC should continue to exist in its current form
  • RARE members will finance the RIPE NCC until the end of December 1993
  • EARN members will also continue financing the RIPE NCC until December 1993
  • A new financing model is needed before the end of 1993 which draws from a broader range of sponsors

Paul V. Binst outlined the proposed funding budget (not yet approved) for the next financial period for the RIPE NCC from May 1st 1993 - December 31st,1993 (RARE doc FIN(92)039v2). Copies are available from Marieke Dekker. The contributions are based on 12% of the 1993 membership fee (itself based on a proportion of GNP). It must be noted however that RARE contribution fees have been increased by 33% from last year. The discussion was opened to the floor. Concerns were expressed that charging would discourage people from actually registering networks in the RIPE database.

In conclusion participants of the RIPE meeting were urged to participate and contribute to discussions between RIPE meetings as this is now a matter of some priority. The discussion will continue on the local-ir mailing list (see item 15 A.O.B for details of all working group lists).

10. Global Internet Traffic Measurement (D Karrenberg, W vd. Scheun)

10.1. Status Report (Daniel Karrenberg)

Prior to the meeting, Torben Nielsen sent a mail to the ripe-list, which contained his apologies for being unable to attend the meeting and an update on his Global Internet Traffic Measurement project. On his behalf Daniel Karrenberg reported on the status of the project.

Torben has collected 6 months of data which is stored on CD-ROMS. Due to operational problems (legality issues) and a lack of manpower, no analysis programs have yet been written. However, Torben will, subject to a data privacy agreement, make the data available to anyone who is interested in working on this project. Please contact Torben.

10.2. Report on EBONE Statistics Project (W vd. Scheun)

Willem Van der Scheun gave a short presentation on the current status of the EBONE Statistics Project.

EBS Operational Recommendations

A paper was written by T. Bates and is retrievable through anonymous ftp from ftp.ripe.net or nic.nordu.net. Filename is ~/ebone/docs/ebs-recom.ps.

From the report, the following should be noted:

  • Recommendation 4 - SNMP statistics should be stored in IETF OPSTAT format
  • Recommendation 5 - Each EBS should run ip accounting as soon as CSC/4 processors are fitted

IP accounting

Almost all EBS's now have CSC/4:

  • Amsterdam - EBS1
  • Cern - EBS1
  • Paris - EBS1
  • Paris - EBS2
  • London - EBS1
  • Stockholm - EBS1
  • Stockholm - EBS2

Test with gathering IP accounting has been done on January 20 and 21, but the results still have to be analysed and a decision must be made on how to proceed further.

Traffic Measurements - IETF OPSTAT format

  • currently there are no tools to store or to convert data to OPSTAT format
  • there are no tools to do aggregation
  • there are no tools to do get information from data into OPSTAT format
  • there are no tools to convert data in OPSTAT format for exisitng presentation tools

The paper is now an RFC 1404, so it is hoped that tools will follow shortly.

What data to gather, where and how was discussed at the EOT meeting on January 28th, 1993 Prague.

Basic metrics are planned, for example counting ifInOctets and ifOutOctets. Longer term counting will address questions like:

  • How much traffic is flowing on EBONE?
  • How much traffic is each regional delivering to and receiving from EBONE ?

At the next RIPE meeting more extensive reporting on the EBONE statistics gathering will be presented.

11. EBONE presentation (B Stockman)

11.1. Status Report (B Stockman)

Backbone

Short term upgrades

  • Stockholm-Ams T1
  • Amsterdam-CERN T1
  • CERN-Paris E1

EBONE 92-93 budget comprises extra contributions from Renater, SURFnet and NORDUnet to finance the above upgrades

US Lines

  • London - T1 (December '92)
  • Paris - T1 (Delivery expected February '93)
  • Geneva - T1
  • Stockholm - T1 (upgraded January '93)
  • Tokyo-Bonn-Washington expected (to be funded by MITI)

General Requirements for US lines

  • Integration in EBONE
  • Routing Scheme
  • Mae-East GIX

EBS Installations

  • Optimal 2 routers
  • Renater EBS moved to Paris. Thanks to France Telecom for a smooth installation
  • Bonn EBS installation is progressing
  • Stockholm and Geneva lines ordered

Routing

BGP-4 expected

  • Delivery March '93
  • Route server project started at RIPE NCC
  • Discussion on usage of non propagation IGP

Regional Issues

  • EMPB and EBONE connectivity still not yet decided
  • NIKHEF Gateway and London gateway operational
  • Vienna dual homed RBS installed 256K to CERN and 128 to Amsterdam
  • ECE countries signed a memorandum now stating that the Vienna RBS will be used for their EBONE connectivity
  • Spain have upgraded to 128 kbps
  • Ireland will connect to London
  • Portugal will connect to Paris
  • A request for connectivity has been received from Greece
  • Israel reconfiguring (satellite vs. terrestial)
  • PIPEX to London EBS

Operations and Reporting

  • IP accounting has been started
  • OPSTAT tools are needed to implement OPSTAT model as per rfc1404
  • EOT and ENOC and EBS responsible including ENOC skipper and mate

CLNS

  • Testing is ongoing
  • Encapsulation of CLNS in IP is suggested as a first step towards the introduction of CLNS on EBONE.
  • CLNS project - EBONE and RARE Cosine co-ordination is needed

12. EMPB IP Services

12.1. Status of the EMPB IP Services (Sven Moller Nielsen)

IP:

Access

  • HDLC (LAPB, ISO8880-3)
  • PPP (rfc 1171 & rfc 1172)
  • X.25 (rfc 887)
  • FR (CoreQ.922)
  • LAN ISO 8802-3/2 Ethernet (this year)
  • LAN ISO 8802-5 Token Ring (this year)
  • FDDI (next year)

Routing

  • EGP2 (rfc 904)
  • BGP3 (rfc 1267)
  • CIDR-BGP4 will follow (this year)
  • Will support future IP platform TUBA/SIP/PIP?

Status CLNP:

  • Access HDLC, X.25 and FR
  • Static routing - no exchange is planned.
  • LAN (future)
  • FDDI (future)
  • 2nd Qtr (1993) - IDRP/PPP
  • 3rd Qtr (1993) - ES-IS
  • 4th Qtr (1993) - IS-IS

Planned Circuits:

8 Mpbs (trunk circuits) - 1993 2nd Qtr

34 Mbps (trunk circuits) - 1994

Testing:

Internal tests were carried out in September 1992 and externally in October 1992.

Basic Performance Services Testing results

Both X.25 and IP were tested with the following results. The tests were carried out at Erlangen University, Germany.

+---------+----------+----------+---------+--------+
|         |         IP(*)       |        X.25      |
|         |   Duplex |  Simplex | Duplex | Simplex |
+---------+----------+----------+--------+---------+
| 64kbps  | 2005(**) | 1775(**) |   1920 |    1820 |
| 128kbps |     1800 |     1700 |   1740 |    1670 |
+---------+----------+----------+---------+--------+
* limited by test environment (lab tests showed 2000 packets/second Duplex)
** measured in the lab at 2000 packets/second

Service Performance of trunk bandwidth

  • With full utilisation of trunk bandwidth:Simplex 7000 packets/second, and Duplex 9000 packets/second
  • Switch may comprise 26 2Mbps ports to more than 200,000 Packets/sec per switch
  • Switch delay 0.7 milliseconds based on last-in-first-out tests

The results of the testing and implementation phase of the pilot will be reported at the next RIPE meeting.

12.1.1. EMPB topology

The EMPB are currently establishing host services with SPARC workstations offering FTP and email via JANET access. JANET will be used for testing and establishing networks and will act as the problem centre. Intercontinental connectivity is planned - it is not yet clear
whether an IP service is required or whether the existing infrastructure may be used.

12.2. Practical Experience with EMPB (Willi Porten)

12.2.1. History - the milestones

Using 64 Kbps IXI service:

  • 2 Feb 92. Tunnel GMD-ULCC using 64kbps IXI established ; first BGP tests
  • 21 Feb 92. BGP running fine; throughput about 20kbps; ULCC access point heavily loaded
  • 3 Apr 92. BGP propagation of DFN customer nets to JANET; access to JANET
  • 10 Jul 92. DFN routes injected via ULCC into EBONE; throughput 48kbps approx

Testing EMPB 2 Mbit

  • 24 Sep 92. Ptt telecom RC-Switches installed at DBP Telekom node Dusseldorf/Germany
  • 6 Oct 92. EMPB 1 Mbps connection up and running; unstable; 2nd BGP to ULCC; Cisco clock rate 819k
  • 12 Oct 92. Unstable connection result of X.25 routing problem. Problem solved; 4 SVCs;total 280 kbps
  • Oct 92. Upgrade London-Amsterdam to 2Mbps
  • 24 Nov 92. Configuration in Dusseldorf changed; Cisco clock rate changed to 2 Mbps; 1.3 Mbps throughput (CSC/3)

12.2.2. Problems

Temporary:

  • X.25 routing problem causes instability (6 Oct until 12 Oct 92)
  • low throughput < 64 kbps detected (Fri 27 Nov 93 until Mon 30 Nov 93)

General Problems:

  • No "one stop" shopping. DBP Telekom talks to EMPB operating
  • Impossible to detect origin of problem without consulting ptt-telecom, but test DTE at RCSwitches to perform some tests
  • No X.25 Traceroute!

12.2.3. Still to be investigated

  • CSC/3 limiting factor for packets < 512 bytes?
  • Measurements for CSC/4 in lab (Erlangen) shows 1560 pps (64 Byte packets) for IP/X.25
  • How does delay influence performance?
  • EMPB limits throughput?
  • fine tuning ...

13. Reports from the Working Groups

13.1. Local-ir (D. Karrenberg)

The Local Internet Registries (local-ir) working group was attended by 43 people. At the session the following was discussed.

13.1.1. European Internet Request template and documentation

Two proposals for the format of the European template were circulated and discussed. A vote was taken with the result in favour of the format which separated the actual template (which will be returned to the registries completed) from the explanations on how to fill out the document. The rationale behind this format is that it enables the returned templates to be easily passed between registries where necessary, the completed template is clear and succinct, and local language versions of the documentation can easily be prepared.

Action: 14.2 Anne Lord
To prepare draft of template with comments from the working group incorporated and send to the working group list

Further explanatory documentation was consequent on the content and format of the template and will be prepared by Bob Day, JNT (Action carried over).

13.1.2. RIPE Database Network Registration procedures

There was some discussion over the registration of network numbers and the following was agreed

  • specify algorithm for network names of individual networks
  • generation of Internet handles by local registries
  • acknowledgement messages to include "Subject" of the original message and use the "Reply-to" fields for acknowledgement messages

Action: 14.3 NCC
Specify algorithm for network names of individual networks

Action: 14.4 NCC
Generation of Internet handles by local registries

Action: 14.5 NCC
Acknowledgement messages to include "Subject" of the original message and use the "Reply-to" fields for acknowledgement messages

13.1.3. 193.in-addr.arpa delegation

It was agreed that the NCC will implement and maintain the primary name server for the 193.inaddr.arpa. The implication of this is that all reverse zone requests for any network within the 193.X.X.X address space will no longer need to be registered with the root (i.e. the NIC). A procedure will be published in due course. It is further planned that the 193 allocated blocks given to local registries could then be further allocated to local registries to run primary nameservers for their delegeted address space. The NCC would also act as an off-site secondary if requested.

13.1.4. Charging for Internet Registry Services

A charging model was identified as necessary before the end of 1993. Prior to this time however it was stressed and agreed that all local registries performing NIC functions should do so on a voluntary basis and no charges should be made to the customers. Clearly defining a charging model is a complex task and RIPE working group participants were urged to contribute to the discussions on the local-ir list. More discussion is needed on the local-ir mailing list.

13.2. Routing and Dababase Joint WG session

  • HEPnet presentation and pilot activity to register routing policies in accordance with the current proposal, ripe-60, "Policy based routing within RIPE" for all HEPnet based networks.
  • Presentation of proposed document, "Representation of IP Rouiting Policies within the RIPE Database" by T. Bates. Introduction of new database objects, "aut-num" and "community", seen as needed to document and express routing policy in todays Internet. Essentially an update of ripe-60 with some added clairity and guidence for network operators within RIPE.

13.3. Routing (J M Jouanigot)

The salient points concerning modifications to the proposed Routing Policy paper were as follows:

  • the principles and concepts of the paper were agreed
  • an AS is defined as a set of networks sharing the same routing policy
  • one particular IP network may belong to exactly one AS
  • aggregation and seggregation of AS's may be necessary
  • default routes, preference, backup, etc need to be defined
  • if a change of service provider takes place, then migration between new and old AS`s will be required
  • pilot sites will be small eg. NIKHEF, NCC

Action: 14.6 Tony Bates
Send redraft of Routing paper to the routing-wg mailing list so that the final draft can be ratified at the next RIPE meeting and work on implementation can start

To join the working group send a request to [email protected].

13.4. Connectivity (Milan Sterba)

Approximately 40-45 people attended the working group meeting. The following items were on the agenda and discussed.

13.4.1. Update of report CEEC Version 5

New connections to the Internet since the 13th RIPE meeting are:

  • Bulgaria: 9.6 EUnet IP/X25 from Varna to Amsterdam
  • Romania: 9.6 IP/SLIP leased line from Bucuresti to Vienna
  • DFN and DESY announced the coming of a 64kbits link to Moscow State University from DESY

A copy of the report can be found in the RIPE document store on ftp.ripe.net in file ripe/docs/ripedocs/ripe-74.ps. Ripe-75.ps is the accompanying map.

All the changes will be reported in version 6 of the CEEC report.

Action: 14.7 Milan Sterba
Version 6 of CEEC report update

13.4.2. IXI Pilot in Central and Eastern Europe

The WG discussed the problem of gatewaying between the IXI pilot lines in Central and Eastern Europe (namely EMPB nodes in Prague, Budapest) and the European IP infrastructure. A gateway will be provided by JANET with a 2 Mbit link capacity. Both CESNET and HUNGARNET anticipate using the IXI link mainly as a backup for their existing international IP connectivity.

13.4.3. Relationship between GISS and Connectivity working groups

It is anticipated that the work of the new Generic Internet Service Specification (GISS) working group will provide valuable input to connectivity working group - specifically in the region of criteria which can be used to evaluate the quality of Eastern European connectivity.

13.4.4. Status report of European networking

Status reports on connectivity problems and experiences were given by representatives from Austria, Czech Republic, Slovak Republic, Hungary, Poland, Bulgaria and Russian.

In particular representatives of Russian IP networks complained about being filtered on the NSFnet backbone, while their traffic is accepted by commercial USnetworks. RIPE cannot directly influence on this, but is identifying it as a connectivity problem.

13.4.5. JENC4 May 10-14 1993

It has been announced that a CEEC forum will be held at JENC4 in Trondheim where representatives of IP networks in Central and Eastern Europe are encouraged to participate.

13.4.6. Forthcoming RIPE meeting technical demonstration

Several cheap PC based IP routing solutions were presented in the RIPE technical program (IP/ X25 at 64 kbit/s, IP/PPP at 64 kbit/s and IP/LAPB at 2.5 Mbit/s).

A proposal was made by Daniel Kalchev to demonstrate solutions based on BSDI during the next RIPE meeting (Arpil 27-29, Amsterdam). At a meeting of the COPERNICUS project (aimed at those cheap IP routing solutions) this was discussed (held after the RIPE meeting).

13.5. Relationship between Academic, Educational & Commercial Networks (G Kowack)

The focus of the working group has been on defining the relationship between academic, educational and commercial networks. In this meeting, the group discussed 2 papers circulated by the chairman which attempted to describe the position of the RAEC wg with respect to the group task. It was agreed by the members of the group that given the
fundamental complexity of the wg charter, that the papers would reflect the consensus reached by the group.

Action: 14.8 Glenn Kowack, NCC
RAEC papers to become RIPE documents and stored in RIPE document store

13.5.1. Future of the group

It was proposed to dissolve the working group and in future to hold BOF sessions, where service providers will be invited to disseminate information concerning their experiences as "IP providers"

Action: 14.9 Glenn Kowack, NCC
Dissolve RAEC working group

Action: 14.10 Glenn Kowack
To organise BOF session at future RIPE meeting along theme of IP provider experiences

13.6. DNS (Francis Dupont)

13.6.1. Cookbook

O'Reilly & Associates have recently publishesd a book "DNS and BIND" by P. Albitz & C. Liu which provides good documentation about DNS and DNS administration for common (i.e. not top-level) domains:

DNS and BIN By Cricket Liu & Paul Albitz 418 pages, ISBN: 1-56592-010-4, $29.95 1st Edition October 1992

Detailed information can be obtained from gopher from gopher.ora.com.

13.6.2. New software

A beta version of the new 4.9 BIND software will be available soon.

Case of the day

European Parliament is a multinational organization, there were several proposals for its housing top-level domain(s):

  • .org: rejected because it is not a North American organization
  • .eu or .eec: asking for a top-level domain for Europe or EEC is not considered as a good thing
  • .int: workable but it is not a world wide organization
  • .fr, .lu and .be: this solution was proposed and accepted for ESA (European Space Agency) and should be again the best solution for this case

The name should be reserved in any EEC country. The two letter name EP is *not* recommended.

13.6.3. Any Other Business

  • a document describing the US domain has been published as RFC 1386.
  • DNS-WG recommended that first and sensible level domains are registered in the RIPE database
  • There is a draft RFC on DNS support for NSAP address RR (for CLNS and TUBA).
  • RIPE IPv7 groups should contact DNS-WG about support in DNS for TUBA/SIP/PIP

13.7. Mapping (D Bovio)

Twenty persons attended the Mapping wg. In summary, the following comments were made and points were agreed.

  • The mapping group is an important activity and should continue as a RIPE wg
  • One map to represent all networks is not possible, therefore maps of a regional networks should be available
  • It was not thought possible to draw maps using the new database routing AS information
  • Routing AS information could be extracted and used to define "borders" of the maps
  • The proposal for a RIPE Network-Related Maps repository of network maps at the NCC was accepted after slight modification
  • The structure of the objects (maps) to be stored in the repository will be published shortly.
  • A Disclaimer/Copyright will be added to the maps
  • The following was agreed concerning all maps submitted to the RIPE repository:
    • they will be accepted in any format but they should provide a legend
    • sample map and legend (template) will be in the README file
    • maps can be of 2 types: showing geographical and/or network topology
    • each map submitted should have the following set of tags: name, maintainer, description, as-numbers-description, source

Action: 14.11 NCC
Create maps directory in the RIPE document store

Action: 14.12 Daniele Bovio
Send a reminder to the ripe-list when the directory has been created

Action: 14.13 NCC
To update the INFO/README/INDEX file in the RIPE maps directory once agreed by the working group

Action: 14.14 NCC
To contact authors of maps on a timely basis when expiry date of map has been reached and archive out of date maps, fetch the files if the source tag is filled

The maps-wg wil reconvene at the 15th RIPE meeting in Amsterdam, where the success of the model will be discussed and a decision will be taken concerning the future of the group.

13.8. Generic Internet Service Specification BOF (T Bates)

The Generic Internet Service Specification (GISS) BOF was a productive session which generated a very open discussion. The following comments and observations were made:

  • the intended target audience for the paper must be carefully considered as this impacts on the content of the paper
  • the paper should focus on aspects of the service rather than the actual levels of service provided, and so provide a kind of "service profile"
  • consequently detailed service elements will act as a reference point for providers (and implicityly) customers
  • care must be taken to avoid "checklist mania" and not to get into too much detail
  • care must be taken not to forget innovation

In summary the action list:

Action: 14.15 Tony Bates
Distribute a "strawman" paper containing basic ideas of GISS

Action: 14.16 NCC
To create the basis for setting up a working group to be called GISS and to create a mailing list for the group

Thanks to all who participated and please continue to do so.

13.9. Database (W Woeber)

Due to parallelism with the routing working group, the database working group had only a brief meeting.

The following topics were discussed:

  • Persons allowed to submit database updates. Virtually everybody is allowed to submit updates, however the RIPE-NCC does carry out some sanity checking. In practice, there are only a few individuals submitting updates. So currently this is not perceived as a problem.
  • Uniqueness of Person Object: currently there is the risk of "overwriting" existing entries (only name is checked). Therefore the only solution is to use the NIC-Handle or (preferred) a future Internet-Handle.
  • Status of syntax-checking: syntax-checking is in use since 4..5 month - distribution of the DB: not really a problem, a few MBytes of information. Selective update is not yet available.
  • Discussion of the Resource-Object proposal (by Milan Sterba) was postponed.
  • Milan Sterba volunteered to track the US development of the Resource-Object description work and will report to the list.

Action: 14.17 Milan Sterba
Volunteered to track the US development of the Resource-Object description work and will report to the list

14. Date, place and time of next meeting

The location for the 15th RIPE meeting to be located in Amsterdam was agreed for 27-29th April 1993. At the 13th RIPE meeting it was reported that RIPE were invited to Lisbon for a future meeting. A date of January 1994 was suggested. Subsequently at the 14th RIPE meeting offers were received from representatives of Italy and Sweden as locations for future RIPE meetings.

Action: 14.18 Rob Blokzijl
To approach persons responsible for making meeting host offers and verify location of 16th RIPE meeting

15. A.O.B.

15.1. New FYI documents (Nandor Horvath)

There are 18 new FYI documents which may be of interest to the RIPE community (shadowed on the RIPE NCC server).

One particular FYI maybe of interest: "Connecting to the Internet; What Connecting Institutions Should Anticipate" (fyi-16). This document has an appendix which contains some 30 US service providers, and it would be useful if Europe gets mentioned in it too.

15.2. Working group mailing lists

To join any of the RIPE working groups, use the e-mail addresses below:

16. Closing

This meeting marked the first occasion that a RIPE meeting had been hosted in an Eastern European country. It was also the meeting with the highest number of participants recorded so far. The task, thus, of organising and supporting the meeting in progress was not insignificant. Very special thanks were therefore extended to the Faculty of Electrical Engineering at the Czech Technical University and to the local organisers Jan Guntograd and his colleagues for their excellent work and generosity in hosting the 14th RIPE meeting.

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

Appendix

List of Open Action Items

Action: 13.1 Bob Day and Daniel Karrenberg
Align the common explanatory document about IP number registration and the common template

Action: 13.2 Bob Day
Circulate draft of an explanatory document about IP number registration

Action: 13.3 Marten Terpstra
Changes in the database format. Coordination discussions with US counterparts are ongoing

Action: 13.4 Marten Terpstra
To progress GSI/Merit/RIPE NCC exchange format discussions

Action: 13.5 Milan Sterba and Geza Turchanyi
Evaluate and consider nature of information for NIDUS

Action: 13.6 NCC
To include the operational contact attribute in all object definitions besides persons

Action: 14.1 Tim Dixon
Circulate overview on IPv7

Action: 14.2 Anne Lord
To prepare draft of template with comments from the working group incorporated and send to the working group list

Action: 14.3 NCC
Specify algorithm for network names of individual networks

Action: 14.4 NCC
Generation of Internet handles by local registries

Action: 14.5 NCC
Acknowledgement messages to include "Subject" of the original message and use the "Reply-to" fields for acknowledgement messages

Action: 14.6 Tony Bates
Send redraft of Routing paper to the routing-wg mailing list so that the final draft can be ratified at the next RIPE meeting and work on implementation can start.

Action: 14.7 Milan Sterba
Version 6 of CEEC report update

Action: 14.8 Glenn Kowack, NCC
RAEC papers to become RIPE documents and stored in RIPE document store

Action: 14.9 Glenn Kowack and NCC
Dissolve RAEC working group

Action: 14.10 Glenn Kowack
To organise BOF session at future RIPE meeting along theme of IP Provider experiences

Action: 14.11 NCC
Create maps directory in the RIPE document store

Action: 14.12 Daniele Bovio
Send a reminder to the ripe-list when the directory has been created

Action: 14.13 NCC
To update the INFO/README/INDEX file in the RIPE maps directory once agreed by the working group

Action: 14.14 NCC
To contact authors of maps on a timely basis when expiry date of map has been reached and archive out of date maps, fetch the files if the source tag is filled.

Action: 14.15 Tony Bates
Distribute a "strawman" paper containing basic ideas of GISS

Action: 14.16 NCC
To create the basis for setting up a working group to be called GISS and to create a mailing list for the group

Action: 14.17 Milan Sterba
Track the US development of the Resource-Object description work and will report to the list

Action: 14.18 Rob Blokzijl
To approach persons responsible for making meeting host offers and verify location of 16th RIPE meeting