Upcoming RIPE Meetings
View all
Previous RIPE Meetings
More RIPE Meetings...

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 ?

o Metropolitan Area Ethernet (East Coast)

o Basically a MAN based 10Mbps bridged ethernet

o Managed by Metropolitan Fibre Systems (MFS), a Washington D.C. based
company.

o Provide Cheap cost-effective 10 Mbps attachment to customers in the
D.C. area.

o Several IP service providers have attachments to Mae-East

Alternet
Sprint / ICMnet (large European provider)
SURAnet
PSI
NSFNET/ANSnet (status unclear)

o Essentially a "proto-type GIX"

o Extremely useful in terms of the RIPE NCC Route Server project

o Allows Europe to present a "fairly" consistent routing picture to
large portion of the service providers across the Atlantic

o Can get some operational experience

o Partners on Mae-East very keen to participate

o 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

o IEPG initiative

o Common forum for Internet co-ordination, November 1991, Santa Fe. GIX
idea evolved

o March 1992, San Diego - consensus on ideas and concepts

o June 1992, Tokyo - paper

o Proposal for Global Internet Connectivity by Almes, Ford and Lothberg

Concepts

Three main components for the project

o The physical "GIX" itself

o The "Route Server"

o The "Routing Registry"

Global Internet Exchange (GIX)

o Neutral Interconnect

o Anyone is free to bring their router to the neutral interconnect

o Anyone is free to peer with anyone else.

o The interconnect is most certainly AUP free

o The interconnect media type can be anything that allows each router to
talk to any other router directly

o Designed to enhance access and connectivity

o Basis for cost-effective transit

o Problems arise from such an open interconnect point

o GIX

o The "N-squared" routing problem

o Possible asymmetric routing

o Sub-optimal routing

o Even routing loops

o Need Coordinating

o The "N-squared" routing problem

o Possible asymmetric routing.

o Sub-optimal routing

o Even routing loops

o Need Coordinating

Route Server

o Task to produce consistent routing information for various Autonomous
Systems (ASes) within its represented region.

o 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

o Uses a database to interact with when building configuration files

o Does not take part in any packet forwarding itself

o Make use of third-party BGP routes (i.e. NEXT_HOP)

o Cuts down much of the administration for the various providers at the
GIX

Routing Registry

o Neutral run registry

o Would manage routes for a region or domain (model used -Geographic)

o Registration of routing policy information

o Network owners register the routes rather than service providers

o Some guidelines will be needed when there is possible conflict

o For Europe, the current RIPE document may need to be reviewed

o Database and objects must be easily derived for use by the route
server

Implementation Plan

Week 5

o Produce final concept paper and distribute

o Develop a procedure paper for service providers

o Start to populate RIPE database with needed info

Week 8

o Pilot an operational European Route Server at "Mae-East" in Washington
D.C.

o Develop tools needed for Route Server / Routing

o Registry interaction.

Week 9

o Start work on any needed enhancements

o Start work on multiple route server interaction

Week 17

o Amsterdam RIPE meeting - intermediate report

Week 26

o Present final project report at Amsterdam IETF

o Summarise and plan at any future work needed

5.2.2. Generic Internet Service Specification (T. Bates)

Background

o Joint project between RARE TC/RIPE NCC

o Close liaison between RTC and RIPE community. Bernhard Stockman
appointed as liaison between RTC and RIPE

o Open project

o No Hidden agendas

o Should not be seen in any way as a competitive / political document

o Not just a paper exercise

o Should be worthwhile

Introduction

o Production of a document describing a `useful' Internet service

o Should cover all aspects of Internet networking (i.e. from Network to
Application)

o Needs to look at Internet services from both sides of the fence:

o Document itself will be generic.

o Make reference to publicly available documents

o RFCs

o Internet-Drafts

o Other relevant material (Books, etc.)

o Aimed at openess

o Need input/information from service providers -without this the
spec' will not be of maximum use

Motivation

o Vast growth of the Global Internet

o Increase in applications base

o Increase in PD software

o Raised user perception

o Vast Increase in Internet service providers

o Various types or "levels" of providers

o Very little material addressing the issue

o IETF Operations Area

o Internet-Drafts ?

o "Mid-Level Networks Potential Technical Services"

o Always a need for improvements in any service

Goals

o Create a service framework for service providers

o Give guidance where needed

o Act a checklist

o Creation of some standard definitions of service

o Creation of categories or levels of service

o Production of a useful specification

Way Forward - Timescales

o Week 3 - Gather ideas and comments from RIPE members

o Week 4 - Produce first draft and mail out to RIPE list.

o Weeks 5-9 - Fold in all comments and re-send draft

o Weeks 9-11 - Complete Specification in liaison with RTC

o 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:

o SIP

o PIP

o 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

o is without a backbone

o each region defines their own AUP

o BGP propagates the topology of the path

o Policy based routing based on AS tags

o Providing admin information about origin

o moves limitation to the next hop architecture

o can be used as an IGP for transit regions

o protocol is slow overhead

o works today - and is used by large networks

o does classless interdomain routing

o using class C space would exhaust routing

o a short term solution is needed

CIDR RFC 1338

o is a 2 part solution

o concentrates on geographical assignment of C blocks via IP service
providers

o leads to routing aggegation

o aim is to slow down routing table growth and deploy CIDR routing
capability

What is CIDR doing?

o Traditional class assignment of class A, B and C networks

o CIDR is Classless Interdomain Routing

Restrictions

o CIDR is less efficient with multi-homed regions

o CIDR wont work if you change provider

Advantages

o CIDR dramatically reduces the size of routing tables

o 1st June 1993 is CIDR day ???

o There will not be a BGP-5

o The BGP WG agreed on IDRP

o Multi IDRP supports IP, CLNS, Novell, Appletalk etc.

BGP-4

o is classless routing

o aggregation of networks and AS paths

o IBGP weights handling

IGP

o supports classless routing

o IBGP

o IS-IS

o 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.

o IP/PPP - 64K kbps

Contact Ivos Cernovahlavek <ivos _at_ rwen.ics.muni _dot_ cs> or Jiri Novotny
<novotny _at_ arwen.ics.muni _dot_ cs> for more information.

o IP/X25 - 64 kbps

Contact Jiri Kaspar for more information <kaspar _at_ cs.felk.cvut _dot_ cs>.

o IP/LAPB 2.5 Mbps

Contact Michal Meloun <meloun _at_ vision.felk.cvut _dot_ cs>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-ede
techniques such as multicast-based videoconferencing to more tra-
ditional 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.

o Global IR (formerly the DDN-NIC - but soon to be the Internic)

o Regional IR (of which the RIPE NCC is responsible for Europe)

o 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:

o 178 applications were received

o 86% of applications were completed in one day

o 97.4% completed within one week

o 30% answered via electronic mail

o NCC answers via fax wherever possible

o all mail/fax correspondence in full-text database

o also an increasing number of telepone call enquiries were received

o increasing number of applications are being made direct to the RIPE
NCC

o and an increasing number of applications are being made directly to
local registires

o Common application form for IP requests throughout Europe needed which
will facilitate and simplify the passing of the applications between
registries.

Database

o 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.

o The DDN NIC cannot yet accept automatic assignments

o 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.

o the establishment of the new INTERNIC will hopefully improve the
situation in the future.

o 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.

o NCC processes approximately 240 updates per working day.

o There has been a full release of the database software

o secondary database servers are encouraged

193.in-addr.ARPA delegation

o simplifies maintenance of reverse mapping information in DNS

o principle agreed

o now needs to be implemented

Document Store and Information Services

o RIPE and Internet information are the most popular sections of the
document store

o Whois usage is by far the most popular of the NCC services. This was
particularly high for December

Other Activities

o Working group support

o Meeting support

o Preparation for new projects

Summary

o General improvements in all activities

o good decentralised structure helps - but is not without problems

o 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:

o the RIPE NCC should continue to exist in its current form

o RARE members will finance the RIPE NCC until the end of December 1993

o EARN members will also continue financing the RIPE NCC until December
1993

o 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 (dekker _at_ rare _dot_ nl). 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
<torben _at_ Hawaii _dot_ Edu>.

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:

o Recommendation 4 - SNMP statistics should be stored in IETF OPSTAT
format

o 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:

o Amsterdam - EBS1

o Cern - EBS1

o Paris - EBS1

o Paris - EBS2

o London - EBS1

o Stockholm - EBS1

o 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

o currently there are no tools to store or to convert data to OPSTAT
format

o there are no tools to do aggregation

o there are no tools to do get information from data into OPSTAT format

o 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:

o How much traffic is flowing on EBONE?

o 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

o Stockholm-Ams T1

o Amsterdam-CERN T1

o CERN-Paris E1

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

US Lines

o London - T1 (December '92)

o Paris - T1 (Delivery expected February '93)

o Geneva - T1

o Stockholm - T1 (upgraded January '93)

o Tokyo-Bonn-Washington expected (to be funded by MITI)

General Requirements for US lines

o Integration in EBONE

o Routing Scheme

o Mae-East GIX

EBS Installations

o Optimal 2 routers

o Renater EBS moved to Paris. Thanks to France Telecom for a smooth
installation

o Bonn EBS installation is progressing

o Stockholm and Geneva lines ordered

Routing

BGP-4 expected

o Delivery March '93

o Route server project started at RIPE NCC

o Discussion on usage of non propagation IGP

Regional Issues

o EMPB and EBONE connectivity still not yet decided

o NIKHEF Gateway and London gateway operational

o Vienna dual homed RBS installed 256K to CERN and 128 to Amsterdam

o ECE countries signed a memorandum now stating that the Vienna RBS will
be used for their EBONE connectivity

o Spain have upgraded to 128 kbps

o Ireland will connect to London

o Portugal will connect to Paris

o A request for connectivity has been received from Greece

o Israel reconfiguring (satellite vs. terrestial)

o PIPEX to London EBS

Operations and Reporting

o IP accounting has been started

o OPSTAT tools are needed to implement OPSTAT model as per rfc1404

o EOT and ENOC and EBS responsible including ENOC skipper and mate

CLNS

o Testing is ongoing

o Encapsulation of CLNS in IP is suggested as a first step towards the
introduction of CLNS on EBONE.

o 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

o HDLC (LAPB, ISO8880-3)

o PPP (rfc 1171 & rfc 1172)

o X.25 (rfc 887)

o FR (CoreQ.922)

o LAN ISO 8802-3/2 Ethernet (this year)

o LAN ISO 8802-5 Token Ring (this year)

o FDDI (next year)

Routing

o EGP2 (rfc 904)

o BGP3 (rfc 1267)

o CIDR-BGP4 will follow (this year)

o Will support future IP platform TUBA/SIP/PIP?

Status CLNP:

o Access HDLC, X.25 and FR

o Static routing - no exchange is planned.

o LAN (future)

o FDDI (future)

o 2nd Qtr (1993) - IDRP/PPP

o 3rd Qtr (1993) - ES-IS

o 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.

X.25 IP*

Duplex Simplex Duplex Simplex

64kbps 2005** 1775** 1920 1820

128 kbps 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

o With full utilisation of trunk bandwidth:Simplex 7000 packets/second,
and Duplex 9000 packets/second

o Switch may comprise 26 2Mbps ports to more than 200,000 Packets/sec
per switch

o 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:

o 2 Feb 92. Tunnel GMD-ULCC using 64kbps IXI established ; first BGP
tests

o 21 Feb 92. BGP running fine; throughput about 20kbps; ULCC access
point heavily loaded

o 3 Apr 92. BGP propagation of DFN customer nets to JANET; access to
JANET

o 10 Jul 92. DFN routes injected via ULCC into EBONE; throughput 48kbps
approx

Testing EMPB 2 Mbit

o 24 Sep 92. Ptt telecom RC-Switches installed at DBP Telekom node
Dusseldorf/Germany

o 6 Oct 92. EMPB 1 Mbps connection up and running; unstable; 2nd BGP to
ULCC; Cisco clock rate 819k

o 12 Oct 92. Unstable connection result of X.25 routing problem.
Problem solved; 4 SVCs;total 280 kbps

o Oct 92. Upgrade London-Amsterdam to 2Mbps

o 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:

o X.25 routing problem causes instability (6 Oct until 12 Oct 92)

o low throughput < 64 kbps detected (Fri 27 Nov 93 until Mon 30 Nov 93)

General Problems:

o No "one stop" shopping. DBP Telekom talks to EMPB operating

o Impossible to detect origin of problem without consulting ptt-telecom,
but test DTE at RCSwitches to perform some tests

o No X.25 Traceroute!

12.2.3. Still to be investigated

o CSC/3 limiting factor for packets < 512 bytes?

o Measurements for CSC/4 in lab (Erlangen) shows 1560 pps (64 Byte
packets) for IP/X.25

o How does delay influence performance?

o EMPB limits throughput?

o 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

o specify algorithm for network names of individual networks

o generation of Internet handles by local registries

o 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

o 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.

o 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:

o the principles and concepts of the paper were agreed

o an AS is defined as a set of networks sharing the same routing policy

o one particular IP network may belong to exactly one AS

o aggregation and seggregation of AS's may be necessary

o default routes, preference, backup, etc need to be defined

o if a change of service provider takes place, then migration between
new and old AS`s will be required

o 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 routing-wg-request _at_ ripe _dot_ net.

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:

o Bulgaria: 9.6 EUnet IP/X25 from Varna to Amsterdam

o Romania: 9.6 IP/SLIP leased line from Bucuresti to Vienna

o 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 byJANET
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) :

o .org : rejected because it is not a North American organization

o .eu or .eec : asking for a top-level domain for Europe or EEC is not
considered as a good thing

o .int : workable but it is not a world wide organization

o .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

o a document describing the US domain has been published as RFC 1386.

o DNS-WG recommended that first and sensible level domains are
registered in the RIPE database

o There is a draft RFC on DNS support for NSAP address RR (for CLNS and
TUBA).

o 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.

o The mapping group is an important activity and should continue as a
RIPE wg

o One map to represent all networks is not possible, therefore maps of a
regional networks should be available

o It was not thought possible to draw maps using the new database
routing AS information

o Routing AS information could be extracted and used to define "borders"
of the maps

o The proposal for a RIPE Network-Related Maps repository of network
maps at the NCC was accepted after slight modification

o The structure of the objects (maps) to be stored in the repository
will be published shortly.

o A Disclaimer/Copyright will be added to the maps

o 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:

o the intended target audience for the paper must be carefully
considered as this impacts on the content of the paper

o 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"

o consequently detailed service elements will act as a reference point
for providers (and implicityly) customers

o care must be taken to avoid "checklist mania" and not to get into too
much detail

o 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:

o 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.

o 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.

o 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.

o Discussion of the Resource-Object proposal (by Milan Sterba) was
postponed.

o 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. Nandor Horvath

New FYI documents

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:

o Routing <routing-wg-request _at_ ripe _dot_ net>

o Database <db-wg-request _at_ ripe _dot_ net>

o Map <maps-wg-request _at_ ripe _dot_ net>

o Local-ir <local-ir-request _at_ ripe _dot_ net>

o NIDUS <nidus-wg-request _at_ ripe _dot_ net>

o DNS <dns-wg-request _at_ ripe _dot_ net>

o GISS <giss-wg-request _at_ ripe _dot_ net>

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

Mailing Lists

This mailing list is intended for RIPE-related general announcements and discussions. It should not be used for commercial purposes. To post a message to the list, email ripe-list@ripe.net. Please note that only subscribers can post messages.

Archives Subscribe