1. Opening
Apologies were received from the following persons who were unable to
attend the meeting:
o Jan Guntograd - Technical University, CZ
o Roland Acra - CISCO
o Stephan Biesbroeck - Leuven, BG
o Bob Collet - SPRINT
o Ljubomir Stefanov - Bulgarian Academy of Science
o Radoslav Dakov - Bulgarian Academy of Science
o Oliver Korfmacher - NetCS
o Clemens Schrimpe - NetCS
1.1. Welcome
Rob Blokzijl welcomed the participants to the 16th RIPE meeting hosted by
NIKHEF and held at WCW, Amsterdam
1.2. Approval of the agenda
The agenda was approved.
1.3. Papers tabled:
Papers:
- Agenda for the 16th RIPE meeting
- Working Group Agendas - one document
- Map of International IP connectivity in Central & Eastern Europe
- RIPE Connectivity Report - draft
- RIPE NCC Review - draft paper
- Decisions of the RARE/RIPE Coordination Meeting (CoA (93)052)
- Current version of DNS advice txt - P. Beertema
Presentation notes:
- DANTE Mission Statement
- GARR on-line Network Resource Guide
Publications:
- EUnet Infrastructure Map
- ACOnet 5th Network Seminar - Notice
- EARN Resource Discovery Pamphlets
2. Minutes of the last meeting.
2.1. Approval of the minutes
The minutes from the 15th RIPE meeting were approved. The action items
from the 15th RIPE meeting minutes were reviewed. The following list
comprises the ongoing action items only. All other action items were
closed.
Action: 15.4 Bob Day/NCC To fold in the comments of the working group on
the ripe-draft-hints-v1.txt, circulate the document to the wg list and
publish as a ripe document. It was confirmed that Bob Day was extremely
busy and that the action should be taken off him. Mike Norris volun-
teered to continue the work.
Action: 15.7 Marten Terpstra Fold in comments and republish amended
ripe-72.
Action: 15.10 Daniel Karrenberg To propose new tags "created" and
"assigned" to the database working group for consideration.
Action: 15.17 Glenn Kowack and Tony Bates Write a top level introduction
for the user as an add-on to the GISS paper once it has been written.
Action: 15.19 Peter Lothberg To draft document on Inter-AS local informa-
tion.
Action: 15.21 Daniel Karrenberg To draft document on colouring.
3. RIPE NCC Report (Daniel Karrenberg)
The RIPE NCC Report was given by Daniel Karrenberg and included a presen-
tation by Marten Terpstra on the new RIPE Network Management Database
software. Copies of both presentations can be found in the RIPE document
store in the presentations directory, files:
o ftp://ftp.ripe.net/ripe/presentations/ripe-m16-dfk-NCC-REPORT.ps.gz
o ftp://ftp.ripe.net/ripe/presentations/ripe-m16-marten-DBPLEN.ps.gz
4. Joint Projects Progress (Tony Bates)
Tony Bates reported on the status of the three Joint RARE/RIPE projects
carried out at the NCC. Copies of these presentations can be retrieved
via ftp from:
o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-tony-GISSREP.ps.Z
o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-tony-RSREP.ps.Z
o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-tony-PRIDE.ps.Z
5. RIPE NCC Review Board (Rob Blokzijl)
Rob extended thanks to all those who provided input to this activity -
especially Wilfried Woeber and Milan Sterba. A draft document has been
produced summarising the outcome of the review. This document was circu-
lated as a tabled paper at the meeting and can also be found in the RIPE
document store in the following directory in file:
o ftp:ftp.ripe.net:ripe/docs/ripe-drafts/ripe-draft-ncc-review.txt
The above draft was would be discussed further at this meeting (see
below) in two BOF sessions.
6. RIPE NCC Activity Plan (Rob Blokzijl)
One outcome of the NCC Review process will be a new Activity Plan for the
RIPE NCC. Further refinement of the draft RIPE NCC Review document and
further input to the new RIPE NCC activity plan was identified as immedi-
ately necessary. This RIPE meeting would be the forum to discuss these
agenda points further. The outcome of these discussions are reported
under item 18 of the agenda "Reports from the Working Groups/BOF's".
7. RIPE & RARE (Rob Blokzijl)
Rob Blokzijl reported on a coordination meeting that had taken place
between Kees Neggers (RARE President), Tomaz Kalin (RARE Secretary Gen-
eral) and himself. A write up of that meeting, produced by Kalin, was
distributed at the meeting.
The main conclusions of the meeting were that the following mode of
operations and coordination is still valid:
o RIPE and RARE are independent organisations.
o RARE has a technical program, but will not include IP coordination in
this program: it will rely on RIPE for all IP related matters.
o RIPE will not set up a technical program of its own, it will use the
mechanism of the RARE technical program for executing projects.
o To ensure close cooperation on the technical level, RIPE appoints a
representative on the RARE technical committee.
It was concluded that the Route-Server and GISD project was a good exam-
ple that this set of agreements is able to get good progress in organis-
ing new projects.
On a related subject, Rob Blokzijl mentioned that the RIPE NCC is still
mainly funded by RARE member organisations. An organised drive to get
funding contributions from non RARE member organisations is on the way;
results are coming in, but more is still needed.
8. Network Resource Discovery
8.1. GARR on-line network resource guide (Giuseppe Romano)
GARR presented the results of their On-Line Network Resource Discovery
work. The resource guide can be accessed via telnet:gopher.nis.garr.it
or gopher:gopher.nis.garr.it The presentation concluded that the RIPE
database, relating to network operations, was not an appropriate medium
for storing this kind of information. It was therefore suggested that
the results of this valuable work should be discussed further within the
NIDUS working group with a view to identifying future developmental work
and possible collaboration with related interest groups.
Photocopies of the presentation were distributed at the meeting. Further
information relating to this project can be obtained from Giuseppe
Romano, email <[email protected]>.
8.2. Guide to Network Resource Tools (Daniele Bovio)
Hard copies of the EARN Network Resource guides were distributed at the
meeting. The guides are intended to provide a service to end-users. It
is planned that these documents will eventually be available on line as
rfc's. Updated revisions to the guides will be forthcoming shortly.
9. How do we ensure a good working European Internet in 1995 (P. Loth-
berg)
Peter Lothberg presented his view of the technical developments necessary
to ensure a good European Internet operation in 1995. Contact Peter
Lothberg <[email protected]> for more details.
10. Update on the new JIPS services (Phil Jones)
The ASCII text of this presentation can be found in the ripe document
store in the presentations directory:
o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-pwj-JIPS.txt
10.1. Introduction
It seemed timely to have an update for RIPE on what was going on in
JANET. This relates substantially to IP. RIPE members had noted the
large and expanding number of DNS-named hosts in the United Kingdom. This
was by no means all JANET developments of course: there were commercial
providers in the United Kingdom, and the numbers of these were increas-
ing. However, there was much activity in the JANET community, and that
was the subject of the talk.
10.2. Requirements(1)
o the latest! ... audio, video, high speeds, etc.
o plus'more of the same', much more.
o connectivity: general, but with emphasis on'similar communities', i.e.
those around the world (as well as in the United Kingdom) involved in
research, academic work and education.
This much was probably as expected.
10.3. JANET - Status Quo
JANET was an X.25 network, with IP running as an optional service over
that. (The JANET IP Service, JIPS, offered a full routing service, with
connected institutions having to concern themselves with routing only in
so far as it was necessary for them to deal with it.) There were other
network level protocols run over the X.25 service too, e.g. CLNS. How-
ever, it was X.25 and IP that were the JNT-supported services. Over 75%
of the JANET traffic was IP-related, and this proportion was rising.
Of the 200 or so institutions connected to JANET, some 50 or so were con-
nected by leased lines at 2mbps, with the rest connected at 64kbps or
less.
JANET had international links via the US/UK `fatpipe', and via both Ebone
and Europanet.
10.4. Requirements Revisited - Network Services
These were:
o IP
o CLNS
o YBTS ("Yellow Book")
o CONS
o X.25 per se (e.g. for X.29)
o Proprietary methods
o + (later?) as required for `isochronous services'. (ATM?).
In summary, the major requirement was clearly IP, but the requirement of
users in the JANET community for X.25 needed to be catered for, and for
the indefinite future.
10.5. Plans and Developments
Higher Speeds (34mbps+) were required internationally. On a national
basis, the SuperJANET project was developing services at these speeds and
greater to add to the JANET profile of operational Network services and
to enhance JIPS.
To make JANET more efficient and effective, the `base' protocol on JANET
will change to IP. To cater for X.25, the JNT was seeking ways to run
X.25 over IP, and X.25 alongside IP (e.g. using frame relay).
10.6. SuperJANET
12+ PDH-connected institutions, 4*34mbps. (Later: SDH).45+ SMDS-
connected institutions, 10 mbps, including the above. SuperJANET will
provide IP connections at higher speeds to be incorporated within JIPS.
There was obvious (e.g. financial) pressure to remove leased lines from
institutions connected via SuperJANET.... and later, there was to be
ATM.
10.7. Special Issues
Name Ordering
There will be an announcement soon of a date after which the official
ordering will change to be consistent with the `international' order.
Phil would keep RIPE informed.
UK, GB, ISO3166 and all that:- There had been an effort to get ISO3166
changed so that 'UK' replaced 'GB'. This seemed to have failed. Changing
from UK to GB should be expected to cause much disruption and inconveni-
ence for users all over the world. RIPE might wish to consider pressing
for continued use of 'UK' as the abbreviation for 'The United Kingdom of
Great Britain and Northern Ireland' on the global IP Internet.
10.8. Documents
Documents (e.g. 'Network News') can be ordered care of the JANET LIAISON
Desk. In particular, there was a Network news 'special issue' on Super-
JANET last year.
[email protected] +44-235-445517 (voice) +44-235-446251 (fax)
11. Update on EMPB services
11.1. Status EUROPAnet (Svend Moeller Nielsen)
The slides of the presentation given at the RIPE meeting plenary can be
found in the document store in directory and file:
o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-EMPB-status.txt
The developments of the EuropaNET since the last RIPE meeting were
presented together with the near term enhancements.
The major activity was the execution of the IP Pilot which started March
1, 1993. It entered a preproduction phase June 16, 1993 and ended suc-
cessfully September 2, 1993.
6 regional networks had participated in the Pilot: SWITCH,JANET, GARR,
RCCN, DFN and SURFnet. All were using BGP3. Some connections were done
on 64 kbps running IP encapsulated inX.25 to a EuropaNET internal decap-
sulation point. Others were made on 1.5 and 2 Mbps lines using HDLC/LAPB
or PPP.Everyone had a back-up connection via X.25 to a decapsulation
point inside EuropaNET. In addition hereto a gateway was established by
DANTE between EuropaNET and EBONE to provide Internet connectivity. The
gateway which now is operational at512 kbps is managed by SURFnet. A
second gateway will be established shortly in London. It will be
operated by JANET.
During the Pilot basic connectivity was checked using PING, and trace
route and by running TCP and UDP based applications PING tests were
furthermore used to monitor availability and to measure round trip times,
RTTs. Average RTT between an IP host in Amsterdam and an IP host in Lon-
don, Dusseldorf or Zurich is 30 msecs. With a host in Madrid it is 70
msecs. This corresponds in practice to the propagation delay.
Different aspects of the routing protocols EGP 2 and BGP 3were investi-
gated, like distributing of routing information and timers to update and
to reconnect.
Throughput was tested at 2 Mbps between DFN and SWITCH by means of a UDP
based program implemented by DFN. For 64-byte packets the results were:
o switch -> dfn: 1736 pps
o dfn -> switch : 1781 pps
o For 1024-byte packets: 223 pps
This corresponds quite good to the lab-tests where a little more than
1800 pps was measured without the EuropaNET nodes being fully loaded. A
TTCP test carried out by SURFnet between DFN and SURFnet gave:
o 64 bytes packets : 898534 bps
o 1024 bytes packets : 941969 bps
The result is practically independent of the packet size and shows the
limitation of the TCP window in use. Tests were also done using TCPBLAST
for connections involving 64 kbps. Up to 57 kbps was achieved. Now the
service has entered the production phase. Connected are besides the
pilot participants, RED-Iris, BELnet, HEAnet and RESTENA.
In the coming weeks the X.25 tunnels will be moved from NIKHEF and JANET
to internal EuropaNET decapsulation points.
The EuropaNET NMC runs a primary name server: (dns1.empb.net) in The
Hague backed up by two secondary name servers:
o switch: (scsnms.switch.ch)
o surfnet: (ns.surfnet.nl)
For the DNS the following naming convention:
o each europanet ip access module: <city><serial number>.empb.net
(amsterdam1.empb.net)
o each interface:<name>-if.<city><serial number>.empb.net
surf-if.amsterdam4.empb.net
In addition to the DNS host the NMC runs a host which constantly monitors
availability by means of PING tests.Alarms are generated on PING failure
and PING reports are made per day to investigate stability and RTTs.
For troubleshooting and performance testing the hosts canparticipate in
FTP and UDP tests.
o Mail can be sent to the NMC: <[email protected]> or<[email protected]>.
Within the near future a new access method will be released. It will
provide IP connectivity in the beginning and CLNP connectivity later via
Ethernet or connectivity via serial line for IP, CLNP and X.25 from the
outset. The IP, CLNP and X.25 routing is done in the Access Box, called
the Magic Box.The Magic Box is managed by the NMC which can monitor,
troubleshoot, download software to and configure the Magic Box.
The Magic Box is of the same make as the EuropaNET nodes and connects to
a EuropaNET node via the EuropaNET internal protocol. Hence the Magic
Box will automatically perform rerouting if more access lines are used
and one of the access lines are failing. This rerouting will take place
without affecting the IP, CLNP and X.25 routing.
During the fourth quarter, 1993 BGP 4 will be deployed providing inter-
working with BGP 3 and EGP 2 with the possibility for route aggregation
and selective deaggregation.
11.2. Status EUROPAnet/EBONE gateways (Erik-Jan Bos)
For 1993 the "DANTE Gateways" will serve as the connection between the
EMPB IP Service and Ebone. The Amsterdam gateway is fully operational
now at a speed of 512 kbit/s, there is work in progress on the London
gateway. From an Ebone perspective these gateways are known as the DANTE
RBS, from an EMPB IP perspective these gateways are the connection to the
Internet at large.
Since the connection of the EMPB IP Service to the Internet there is work
in progress on the rehoming of the old "IXI tunnels" to NIKHEF and JANET.
EMPB IP is fully capable of handling the decapsulation of IP in X.25
internal to their network. All regionals still having tunnels to either
NIKHEF or JANET have been contacted to migrate to the new situation.
The sheets of the presentation can be retrieved as:
o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-ejb-DANTE.ps.Z
12. Update on EBONE (Bernhard Stockman)
Bernhard Stockman outlined the plans for EBONE in the future. There was
discussion over the organisational structure governing the GIX and dis-
tributed RBS`s. Further information can be obtained from Bernhard Stock-
man <[email protected]>.
13. Update on EUnet (Glenn Kowack)
EUnet has been operating since 1982. It connects over ten thousand sites
and networks, with gateways to major commercial and research networks
around the world including the Internet, the Commercial Internet Exchange
Association and NSFnet. Services are provided in 27 European-region
countries at 50 Points of Presence.
EUnet International Structure
EUnet services are provided in two layers. The centre of the system is
EUnet's European Network Operations Centre (NOC) in Amsterdam, The Neth-
erlands. This centre exchanges data between, and provides services and
management, to each of the National EUnet Service Provider Networks
located throughout the greater European region. Each National Service
Provider has a connection to the European NOC.
National EUnet Service Providers
Each National Service Provider operates its own Network Operations Centre
(National NOC), which provides EUnet services and user support in the
local languages. Technical problems and requests for services at the
national level should be addressed to postmaster@<country>.eu.net. Many
EUnet service providers offer unique services.
Each national EUnet (through their national NOCs and various Points of
Presence (EU-POPs)) acts as a point of concentration for all traffic.
This traffic is then transmitted from each EUnet provider to the European
NOC in Amsterdam for distribution to the other EUnet providers, peer net-
works, and intercontinentally. In some cases, EUnet providers connect to
intervening EUnet providers, and from there to the European NOC.
The vast majority of EUnet traffic travels over EUnet's own infrastruc-
ture. From Amsterdam, EUnet connects to every major R & D network in
Europe and, via EUnet's transatlantic digital line, to UUnet and the
NSFnet in the United States.
EUnet is also a member of Ebone '93 (European Backbone), and The Commer-
cial Internet Exchange (CIX) Association.
14. Update on SPRINT infrastructure support (Bob Collet/Peter Lothberg)
Bob Collet was unable to attend the meeting at the last minute and sent
this apologies. Peter Lothberg gave a presentation in his place. Peter
outlined the historical development of SPRINT and some of its more recent
activities. Contact Bob Collet <[email protected]> for further infor-
mationon SRINT.
15. RIPE European Internet Architecture WG-BOF Report
Chair: Bernhard Stockman Minutes: Mike Norris
Bernhard Stockman had circulated a proposal for an European Internet
Architecture (EIA) WG within RIPE, together with a draft charter. He
developed some of the operational issues such as:
o What is routing stability and how is this achieved?
o Multiple ISPs (Internet Service Providers) providing full connectivity
to the global Internet give needs for traffic interchanges.
o Where should such interchange points be located and who should be
allowed to connect?
o Need for a management framework for such interchanges.
The technical issues need to be specified and timetabled. There was sup-
port for the idea of a EIA laboratory, so its needs would have to be
determined, its tasks defined and resources specified. One possible task
would be to participate in SDRP pilot.
In the general discussion, it was reported that there was support for the
model of a distributed GIX (D-GIX). The D-GIX could be see as an interim
solution awaiting a more full-fledged solution providing the necessary
tools for multiple independent interchanges.
The immediate problem would have to be defined and an interim solution
based on the separation of routing and payload traffic developed as out-
lined in the D-GIX model, presented earlier at this RIPE meeting. The
solution would demand a fully populated routing registry. Aiming at full
connectivity, it should not limit flexibility, but should make choices of
connections possible.
It was agreed there should be an EIA WG within RIPE. There was some dis-
cussion over possible confusion arising from the suggested name for the
group. A name was finally settled as European Engineering Planning Group
(EEPG). It should be open and neutral. While focusing on the D-GIX now,
it should be conscious of the need for development beyond this strategy.
The WG should have formal liaison and reporting procedures with the IEPG,
which was seen as the appropriate forum for the D-GIX activity. Bernhard
Stockman agreed to be the chairman for the new RIPE working group.
Action: 16.1 Bernhard Stockman. To define scope and work plan for the new
RIPE working group.
16. Introduction of DANTE (Howard Davies)
Howard Davies, General Manager of DANTE, gave a presentation of the com-
pany, its current activities, and future plans. The mission statement
for the DANTE organisation was distributed at the meeting. A summary of
the presentation is as follows and is available by ftp from the presenta-
tions directory
o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-hd-DANTE.txt
Following extensive discussions within RARE, and with particular relation
to the need to provide continuity of services established by the COSINE
Project, the basic structure of a new organisation which would take
responsibility for the provision and management of international network
services for the academic and research community was proposed in a docu-
ment towards a Single European Infrastructure , the Final Report RARE
Task Force on the Establishment of the Operational Unit (commonly known
as the Green Book) which was published in January 1992.
Following widespread agreement in principle with the proposals contained
in the Green Book, a group of 12 European national research networks
signed a Heads of Agreements which defined in outline the legal structure
of a non-profit company in which all members of the group would be share-
holders. A draft Shareholders Agreement has since been produced which
specifies the internal procedures of the company in full detail.
Because the Shareholders Agreement is necessarily complex and has to be
approved by many countries which have different legal systems, final
agreement on its contents necessarily takes a long time. In order to
make progress more quickly, RARE agreed to purchase an off-the-shelf UK
company (which was named Operational Unit Limited) as an interim measure.
The company name was subsequently changed to DANTE (Delivery of Advanced
Network Technology to Europe Limited). DANTE is still wholly owned by
RARE but ownership will be transferred to the national networks as soon
as the Shareholders agreement has been finalised.
DANTE was formally launched on 5 July 1993 in Cambridge, UK, where it has
established its offices. As of 15 September 1993, DANTE has 4 employees.
This number will increase to 8 by 15 October 93. The planned staff com-
plement at the end of the first year of operation, i.e. in July 1994, is
12.
DANTE's Mission Statement is exactly as proposed in the Green Book. The
full statement is provided as a separate paper available with the papers
available for the RIPE meeting.
DANTE has taken over a number of Application Level services from COSINE,
notably the MHS service and management of the PARADISE Project. There is
also a software portfolio (EXPLODE, FORTRESS) which may be exploited.
The most important DANTE services are however the network level services.
DANTE is taking responsibility for the EMPB service (operated by
Unisource Business Systems) which has been operational for some time; the
2 Mbps native IP component of the service completed all aspects of its
acceptance test on 2 September 1993.
DANTE will combine transatlantic connections and an interconnection with
Ebone with EMPB as the European backbone to provide a packaged EuropaNET
service which offers full connectivity with the global Internet. Inter-
connection with Ebone under an agreement valid until the end of 1993 pro-
vides intercontinental access at present. DANTE will have its own tran-
satlantic capacity from the beginning of 1994 and expects to use the pro-
posed distributed GIX as a means on interconnection with Ebone 2, EUnet
and other services from mid-1994.
DANTE is examining a number of aspects of high speed service planning.
The extension of the EMPB service to 4/8 Mbps would provide a short term
increase in available capacity. Many new applications however require an
order of magnitude increase in bandwidth and the possibility of introduc-
ing a 34 Mbps service is being examined. Several technologies are in
principle available to support such services - native IP, ATM (with IP
over ATM) and SMDS are all being considered - but the lack of availabil-
ity of lines or other PTO services inhibits progress. Developments within
programmes such as tenibc and the HPCN initiative will also be followed.
17. Update on networking with Russia (Rob Blokzijl)
Progress was reported on the following projects:
o NASA: the NSI link to Moscow is expected to be installed in November
this year. The link will be operated under the standard NSI AUP.
o DoE: ESnet is progressing with the definition of their requirements
for networking with Russia. First investigations on the possibility
of combining their efforts with those of NASA are under way.
o Novosibirsk: a new project has been identified to connect the Siberian
branch of the Russian Academy of Sciences in Akademgorodok (Novosibirsk)
to the Internet via a satellite link with the Institute of High Energy
Physics at the University of Helsinki. The technical specifications
are ready, some of the funding is still missing.
o DESY/DFN - MSU: the remaining administrative obstacles have been
removed. The link is expected to be installed in October 1993.
o Gran Sasso - Dubna: this link is expected to be delivered by the end
of 1993.
o Moscow Backbone: the fiber backbone in Moscow has been progressed in
the sense that all the necessary administrative work is accomplished.
Installation is expected to be finished before the start of the winter
season.
o ISF Moscow: the first international links supported by the ISF are
operational.
o NATO: an introduction of NATO plans for support of networking was
presented. NATO has initiated, together with RARE, the organisation of
a networking seminar in April 1994 in Moscow. The aim is to get
Russian policy makers around the table in order to ensure
18. Reports from the working group parallel sessions
The agendas of each of the working groups are in Appendix 3.
18.1. Local-ir Working Group (D Karrenberg)
Chair: Daniel Karrenberg Scribe: Anne Lord, Daniel Karrenberg, Martijn
Roos Lindgreen
The proposed agenda was accepted after extra points were added:
o discuss needed documentation
o discuss the procedure to set up new top level domains
Reports for information:
The DE-NIC will be shut down and moved to another place from the 15th of
December. It will be funded by all the DE service providers.
A local-IR workshop was held on Wednesday 15th September in the morning.
As it was an informal meeting no minutes were taken. The workshop was
considered useful and will be held in conjunction with a RIPE meeting on
a yearly basis. A more extensive reporting was asked for, but was con-
sidered inappropriate because of the informal nature of the workshop.
Proxy network entries:
Many participants felt that the network proxy entries should be avoided.
After intensive discussion it was decided that a draft policy for this
will be worked out by Duncan Rogerson and Daniel Karrenberg. This will
not happen without input from those service providers who are in favour
of the proxy entries.
Action: 16.2 Daniel Karrenberg/Duncan Rogerson To draft policy on proxy
network entries.
Autonomous Systems Database Template
The AS Database template was formally accepted.
Should we maintain a list of local IRs and publish it?
After intensive discussion it was decided that a list of Internet Regis-
tries will be maintained and published by the RIPE NCC. This list will
be sorted by country and contain all local providerand non-provider
registries. A draft of the list will be circulated on the local-ir list
by the NCC.
Action: 16.3 NCC To publish a list of Internet Registries - draft list to
be circulated on the local-ir list.
Input for the Activity Plan
It was suggested to add the following activity: Maintain and regularly
publish the list of local Internet registries.
Action: 16.4 NCC Propose to add to the new RIPE NCC Activity Plan - pub-
lishing and maintaining a list of local IRs
Another suggestion is to strengthen the local registry liaison with
tutorials and workshops, but no decision was taken on how to implement
this.
AoB
It was felt that more documentation is needed. The following volunteers
were appointed to edit the documents:
Action: 16.5 Juliana Tamorri FAQ on CIDR and subnetting.
Action: 16.6 Daniel Karrenberg Why return unused IP address space and be
a good network citizen.
The problem of finding registrars for new top level domains was raised;
there was consensus that the RIPE NCC shall offer to serve as temporary
registrar for top level domains in our region, until about a dozen sub-
domains have been registered.
Action: 16.7 NCC To offer to serve as temporary registrar for top level
domains in Europe. Contact IANA.
18.2. Database working group (Wilfried Woeber)
Chair: Wilfried Woeber Scribe: Daniel Karrenberg
The proposed agenda was accepted.
The new Database Software
Marten Terpstra provided a detailed report on the current state of the
DB-Software, both from a software point of view as well as from the
deployment point of view. The slides for this presentation can be found
in the presentations directory in the RIPE document store:
o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-marten-DBDETAILS.ps.Z
The new software is in production use since Friday September 10th and
until now there have not been any major problems. During the discussion
it was again stressed, that the current implementation is built to do
syntax checks according to the object description and not according to
common usage practice. The RIPE NCC welcomes suggestions as to where the
syntax checking needs to be changed.
Currently those attributes marked illegal are deleted from the database,
but not the objects as a whole.
One of the things discussed was how to avoid a possibly large number of
bounced submissions. One way of doing this is to obtain (part of) the
new software to do the checking locally. The betaversion of the software
is available, although it probably makes more sense to wait for the offi-
cial software distribution which will provide a dedicated syntax-checker.
A syntax checker daemon at the NCC was also suggested to remove the
requirement to run the software locally. A template generator was sug-
gested as well. This needs more discussion on the mailing list.
The NCC has run a syntax check on the whole database and was asked to
make the syntax error output available.
Daniel Karrenberg gave an overview on the "Authorization and Notification
of Changes in the RIPEDB" proposal. It was decided to implement it as
proposed. Proposals on how to better support the distribution of the
update process are very welcome.
The discussion of implementing "guarded attributes" revealed concern
about the possibility to delete an object that has a guarded attribute.
It was agreed that the implementation will not delete any object as long
as guarded fields are present. This will force removal of guarded fields
from the object before the delete operation is accepted. The database
wil NOT keep track of "pending deletes", thus the delete request has to
be submitted again after removal of the guarded attribute(s). The NCC
will look into ways to notify guardians of failed deletes. The origina-
tor of the delete request will of course be notified.
The procedure to convert existing information into guarded information
(eg.aut-sys: for the network object) was agreed as follows:
o the NCC moves the information from the database to the guardian files
initially the NCC is the guardian
o as soon as possible, responsibility for the files is transferred to
the real guardian(s)
In instances of where two or more guardians want to set an attribute
which can only have one value, the current state of the attribute will
not be changed and all guardians concerned will be notified.
Example:
The aut-sys attribute of network 193.193.193.0 in the database is AS193.
AS4711 adds this net work to his guardian file. At the next database
cleanup all guardian files will be examined.
o If the AS193 guardian file still contains 193.193.193.0 a conflict
exists and the current database state prevails: AS193 will remain.
o If 193.193.193.0 has been removed from the AS193 guardian file no
conflict exists and AS193 will be replaced by AS4711.
Similarly the aut-sys attribute will remain undefined if it is undefined
and two guardians add it simultaneously.
Since the cleanup runs every 24 hours guardians involved in a change
should coordinate their changes such that they are done in the same 24
hour period.
18.2.1. Database (and Software) Documentation
The documentation will be structured to consist of:
o object definitions and general background information, by Wilfried
Woeber and NCC and available before the end of 1993
o software documentation, provided by the NCC asap
o maintainer's guide (for e.g. the Local-IRs)
o additional input and support is expected from the Local-IRs and others
o Secondary Server Guide
Additional input and support is expected from the Local-IRs and others.
The Objects Definition and the SW-Documentation get priority, in the
listed order.
18.2.2. Unique Person Handles
Given the growth of the database, it is urgent to distinguish person
objects for people with the same name!
After another round of thorough discussion it was decided that RIPE sug-
gests a global scheme to the InterNIC. One of the possible solutions is
to reserve a sub-range of the NIC handle space for RIPE allocation, e.g.
XY3000-XY5000. If this approach fails, then WW and the NCC will propose
a unique identifier scheme for RIPE (aka "RIPE Handle").
18.2.3. Objects Review and Proposals
The proposed CLNS routing object (dom-prefix:) was presented by Henk
Steenman and accepted. Some minor loose ends how to check for syntax and
maybe semantics of the hexadecimal strings that are the CLNS address-
prefixes have to be ironed out (Henk Steenman and Tony Bates). The long-
standing proposal to build a "Resource Object" was formally withdrawn.
Then the discussion moved on to agree on how to make a smooth transition
from ripe-60 to the ripe-81 format to describe the routing. The steps
are as follows:
o as soon as the guarded fields are implemented, ripe-60 entries will no
longer be accepted.
o ripe-60 information is converted to ripe-81 format.
when there are no longer any operational dependencies then all ripe-60
data will be removed from the database.
Jean-Michel Jouanigot is the focal point for the ripe-60 --> ripe-
81transition coordination.
Also the gateway: field for the network objects was confirmed to be
obsolete and can be removed from the database.
18.2.4. DB Exchange format(s) and procedures
The circulated document about the agreed interchange format was briefly
reviewed. Everything seems to be in place to actually start exchanges
with the InterNIC. There was consensus that this has a very high prior-
ity. Currently the recommendation is not to try to get the various
databases in sync manually.
18.2.5. DB usage conventions and recommendations
Quite some time was spent to discuss the connect: attribute of the net-
work object. It was agreed that the only well-defined value is LOCAL.
This attribute should eventually be obsoleted. Later it was noted that
it is currently mandatory and should be made optional after one round of
mailing-list discussion.
However, there is a need for the functionality, maybe the community:
approach is the right way to go (e.g. create community NSF). Still
there is concern that some of the approaches that are obvious for "old
hands in networking" are not necessarily useful for the end-users. Maybe
the tools coming out of the PRIDE project can help to solve this problem.
NCC to start the discussion with a rough proposal before the next meet-
ing.
18.2.6. whois++ by Peter Deutsch et.al.
The whois++ project was briefly mentioned, although the DB group had too
little information to actually discuss the issue.
18.2.7. AOB
It was mentioned that there is a need for new tools to support the
Local-IRs. This needs more discussion on the e-mail list.
Action-List:
Action: 16.8 NCC Put together a consolidated distribution of the new DB
software, including a separate syntax checker for objects.
Action: 16.9 Wilfried Woeber Start discussion on the DB mailing list on
new tools needed, e.g. template generator, syntax checker daemon at the
NCC.
Action: 16.10 NCC Make the error reports form the DB syntax check pub-
licly available.
Action: 16.11 NCC Implement changes to DB procedures according to the
proposal "Authorization and Notification of Changes in the RIPE-DB" by
Daniel Karrenberg.
Action: 16.12 NCC Implement changes to DB procedures for the guarded
attributes according to the agreement.
Action: 16.13 Wilfried Woeber and NCC Produce documentation about "Back-
ground, History and Object Definitions" for the new database software
before the end of 1993.
Action: 16.14 NCC Produce "Software Documentation" for the new database
software asap.
Action: 16.15 NCC To approach the InterNIC to agree on the use of a sub-
range of the global NIC-Handle space for RIPE usage.
Action: 16.16 Henk Steenman and NCC (Tony Bates) Implement the dom-
prefix: object for CLNS routing, after tightening the syntax defini- tion
and semantics of the CLNS-address hexadecimal string.
Action: 16.17 Jean-Michel Jouanigot To coordinate the transition from
ripe-60 to ripe-81 format for routing description.
Action: 16.18 NCC Try to actually get the synchronisation of the various
databases going, using the recently agreed DB Exchange Format.
Action: 16.19 NCC Start discussion on the mailing list by providing a
first proposal how the functionality of the badly defined connect: attri-
bute could be replaced (with the target group of the end-user in mind!)
by using e.g. community: and other forthcoming tools from the PRIDE pro-
ject.
18.3. Connectivity (Milan Sterba)
18.3.1. ECE Connectivity Update
o DFN announces a 64 kbit line between DFN office in Berlin and Riga
Univ.
o Albania has now a first MX entry in the DNS
Roman Adamiec : Polish connectivity
o Warsaw is now a full dual homed RBS (2 MBit satellite connection to
Stockholm paid by NASK, 128 kbit to Vienna)
o a project of a Warsaw MAN based on ATM is under way (partners are not
only academia and PTT's but also gov. and com. institutions)
o plans to upgrade majority of intercity lines to 64 kbit (these lines
do not bear an "academic" AUP)
o major nodes are now being upgraded to professional routers
Balazs Martos: Hungarian connectivity
o estimated need for connectivity to EBONE for 1994 is 128-192 kbit
o Budapest has now a very meshed FDDI MAN operational
o 6 major cities are now connected to HUNGARNET by 19.2 lines (upgrades
to 64 kbits planned)
o 300 institutions are connected over IP over public X25 (using mostly
PC routers and cisco routers in concentration points)
o the AUP on HUNGARNET allows only for R&D traffic (no matter whether
private or public institution is connected)
o the HEPnet line to CERN is subject to strong usage restrictions
imposed on the hungarian side of the line (this is no longer a problem,
the line is only 9.6 kbit/s)
o two ECE IXI lines running (to Bern at 64 kbit and to Prague at 9.6)
(used for tunnelling IP/X25
o problems mentioned on the London gateway to EBONE)
Tomaz Kalin: IXI
The contract covering ECE IXI has been modified as to cover also native
IP access. ECE countries are now free to negotiate migration to native
IP with the provider. EC financing for ECE "IXI" in 1994 is under
negotiations
Petr Kral: Czech connectivity
o CESNET now covers ten major academic cities with intercity connections
migrating to 64 kbit. Other connections are planned for later this year
o CESNET now has 64 kbit lines to Vienna and Bonn EBS's and an ECE IXI
line to Amsterdam (upgraded to 64 kbit only recently) emphasis now given
to user support and user services
o the 19.2 line to Banska Bystrica carries an important part of the
international traffic of Slovakia
o FDDI MAN projects exist in Prague and Brno areas
Tomaz Kalin: Slovenian and Croatian connectivity
o Zagreb has its own 19.2 line to Vienna
o the line from Ljubljana to Vienna should be upgraded to 128 kbit
o there is a 19.2 line between Zagreb and Ljubljana carrying IP and
DECnet
Rob Blokzijl suggests to stop doing the ECE connectivity map and invite
ECE countries to store their maps into the RIPE map store
Tomaz Kalin reports on joint government level networking workshops organ-
ized by RARE and NATO in Budapest in October and later planned for Moscow
(April 1994?)
18.3.2. Connectivity Data Store
Final version of the CDS fact sheet guidelines will be produced including
comments from RIPE members and stored as a RIPE draft
An umbrella hypertext document will be produced which will describe the
CDS as a whole and rules for contribution and will contain pointers to
fact sheets and maps of:
o networks operating on international scale
o countries and networks operating in one single country
Fact sheets and maps will be stored as they are submitted (unless they
are not conforming to the CDS guidelines) and will stay under the respon-
sibility of the contributor
The CDS is open for all contributions from networks operating in Europe.
A first solicitation for contributions will be done to populate the CDS
with first data.
Contributions will be sent to [email protected]
The technical maintenance of the CDS belongs to the NCC
The CDS should be accessible by WWW as a primary method but also by
gopher, ftp and e-mail
Action: 16.20 Milan Sterba Produce a revised version of CDS guidelines
and submit it as a RIPE draft
Action: 16.21 Milan Sterba, Anne Lord Produce the umbrella hypertext
document for the CDS
Action: 16.22 Milan Sterba Solicit first contributions to the CDS.
Action: 16.23 NCC Create the [email protected] alias and establish pro-
cedures to integrate new CDS contributions and maps to the CDS.
18.4. DNS Working Group (Francis Dupont)
Chair: Francis Dupont Scribe: Lars-Johan Liman
18.4.1. Opening
Francis Dupont opened the session. Lars-Johan Liman was appointed secre-
tary.
18.4.2. Old Items Including a Second Name Server in Europe
The possible need for a second root name server in Europe was discussed.
Of the 1.4 million hosts now registered, 400,000 are located in Europe.
This ought to cause a lot of unnecessary traffic across the US lines.
Suitable location for a second European root server was discussed, and
suggestions were Paris (GIX pilot), Amsterdam (many IP providers join
there), and Vienna (many connections to the fast growing Eastern Europe).
It was decided to contact the Connectivity WG to check if Vienna would be
a suitable site, taking future plans for Eastern Europe into account, and
if so, and if someone in Vienna is willing to host and tender a root name
server, the WG would suggest Vienna for a second root name server in
Europe replacing one of the existent US root servers.
18.4.3. IPng support
Discussions on IP Next Generation are taking place in the IETF, but no
clear decisions were heard of, and therefore it seemed useless to get
lost in discussions on software support for it.
18.4.4. Software and Tools
Experiences with the new versions of the name server kit (named) showed
that it is not very stable. Version 4.9 is clearly broken in several
places and should not be recommended for use anywhere. Version 4.9.1 is
a BSD 4.4 Unix special version. 4.9.2 is much better than 4.9 but still
not good. It should not be used for production in "unattended environ-
ments".
The question was raised whether there is a name server for the Microsoft
Windows NT platform. No answer was found.
18.4.5. Input for Piet Beertema's Internet Draft on DNS (BIND) ConfigEr-
rors.
the paper was discussed in detail and approved unanimously. A note from
Rob Elz <[email protected]> on the subject of reverse mapping for the
127.0.0.1 local host address was circulated and approved to be incor-
porated in principal in the draft.
The WG would like RIPE to recommend that, if possible, local IP registry
is performed by a nonpolitical 3rd party organisation, not a service pro-
vider. This to avoid any chance of political friction.
18.4.6. Closing
Francis Dupont thanked everyone for their contributions, and closed the
meeting.
18.5. Routing Working Group (Jean-Michel Jouanigot)
Chair:Jean-Michel Jouanigot Scribe:Gilles Farrache
Previous minutes; action list; agenda
Open action items comprise the following:
Action: 15.19 Peter Lothberg To draft document on Inter-AS local informa-
tion.
Action: 15.21 Daniel Karrenberg/ Jean-Michel Jouanigot To draft a docu-
ment on colouring.
The Agenda was approved.
18.5.1. Ripe-81 status
Tony Bates (RIPE NCC) presented the RIPE-81 statistics. Among the 103
known ASes in Europe, only 49% are registered in the RIPE database, and
among these 49%, only 60% are syntactically correct. The fact that some
of the entries are syntactically incorrect is due to the lack of syntax
checking in the previous version of the RIPE database software. The
slides of this presentation are available from
o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-tony-RRSTATS.ps.Z
Service providers are urged:
o For those having already registered their ASes, re-send their entries,
so that all entries will be syntactically correct,
o For all the others, send their entries in the RIPE-81format.
It is extremely important that all ASes are registered as soon as possi-
ble. The PRIDE project and the GIX route server cannot be successful
without this information.
Once the ASes are registered in the RIPE-81 format, the networks them-
selves will have to be tagged. This is not yet possible, but will be in
the very near future (see database Working Group).
18.5.2. Guardians and procedures (brief)
Marten Terpstra gave a short introduction on the guardian mechanism for
the 'aut-sys' and 'community' tags. This mechanism will be applied as
soon as the Database working group agrees with it (see Database working
group minutes). Three questions are addressed to this working group:
o What will happen to the current 'aut-sys' tags already stored in the
Ripe database?
o How will a conflict between two guardians be resolved?
o How will the database software react if somebody tries to delete a
guarded network entry?
18.5.3. Use of Ripe-81; conversion of Ripe-60
Ripe-60 objects are no longer accepted. These objects have to be con-
verted into the RIPE-81 format, but this should be straight forward. As
soon as the NCC is able to tag networks with their AS number, the current
users of Ripe-60 should convert to Ripe-81.
Action: 16.23 Jean-Michel Jouanigot coordinate this conversion from
ripe-60 -> ripe-81.
18.5.4. Ripe-81 enhancements
DMZ
There was only positive comment on Daniel Karrenberg's proposal for DMZ
networks attributes, that was sent to the list on May 93: "Description of
Inter-AS Networks in the RIPE Routing Registry" (ptraceroute issue). This
paper will therefore be included in the next revision of the paper.
18.5.5. Colouring
Several ideas were presented to increase the granularity of the policies
expressed in RIPE-81. RIPE-81 only deals with ASes, but ASes may contain
several "sub ASes", that have to be differentiated within another AS:
colours. Colours are internal to an AS, but could be exported to another
AS for its own purpose. An example of this could be that a network
tagged with a special colour would mean "Please do not aggregate this
network", in the CIDR context. The entries in the Ripe database would
then look like:
o aut-num: AS1111
o as-in: AS1234 100 AS7890/<16 bits representing the colour>
[...] and
o netnum: 199.199.199.0
o aut-sys: AS7890/<16 bits representing the colour>
BGP4 has the possibility to carry this 16 bits information.
Do to the lack of time, it was decided to go on with the discussion on
the list. Action is still on JeanMichel Jouanigot & Daniel Karrenberg to
write a draft on colouring (previously action 15.21)
Inter-AS Local Information
Due to the lack of time, this item was postponed and should be discussed
on the list. Action remains on Peter Lothberg (previously action 15.19):
o Multi-homed, multi-inter AS connection
o Local inter-AS information.
CIDR
Introduction
The basic principles of CIDR were briefly presented.Services providers
are encouraged to read the RFC 1467: "Status of CIDR Deployment in the
Internet (Topolcic) Aug. 93".
Discussion
Stephan Biesbroeck sent a case study on the list on May 1993 and Duncan
Rogerson presented and distributed a text explaining the impact of CIDR
on their network.
A few remarks were made concerning the availability of CIDR capable code
in the routers: this code should be widely available before any "real"
route gets aggregated.
BGP4: What's new?
Peter Lothberg presented the BGP4 principles and emphasized the differ-
ences between BGP3 and BGP4. As an application example, he discussed the
EBONE plans concerning BGP4 usage. The presentation is available from
him.
18.6. NIDUS Working Group (Nandor Horvath)
Chairman: Nandor Horvath Scribe: Anne Lord
Joyce Reynolds IETF User Services Area Report
The following fyi documents have been updated/issued:
o fyi 2 - FYI on a Network Management Tool Catalog
o fyi 19 - FYI on Introducing the Internet
o fyi 20 - FYI on "What is the Internet?"
o fyi 21 - A Survey of Advanced Usages of X.500
GARR on-line Network Resource Guide
Giuseppe Romano presented the results of the work done by GARR on this
project and there followed a general discussion. The tool is built
around extended WAIS searches. A document summary and access method to
an actual document are the result of a search. It was noted that
developing the project involved two particular areas of work which are
ongoing:
o developing and refining the tool
o completing the resource description templates
Currently, completing the templates is a manual process and labour inten-
sive.
Future plans for this project were discussed and it was agreed to contact
related IETF working groups (Jill Foster) and to draft a proposal outlin-
ing the project which would be submitted to the RARE RTC for evaluation.
The draft proposal would be circulated to RIPE and the NIDUS working
group for comments.
18.7. RIPE NCC Review and Activity Plan BOF (Rob Blokzijl)
Based on the outcome of the RIPE NCC review, a new Activity plan for the
NCC has to be written. The results of a first round of discussions dur-
ing two BOF sessions at this RIPE meeting identified the following ele-
ments for the new activity plan:
o a detailed description of all technical and administrative activities
currently undertaken by the NCC.
o an important new element will be the involvement of the RIPE NCC in
technical development work as defined by approved joint RIPE/RARE
projects.
o the lifetime of the Activity Plan must be clearly defined.
o review procedures must be defined.
o a mechanism for change control must be defined.
o Mike Norris suggested that the final report should incorporate the old
RIPE NCC Activity Plan (Doc ID: ripe-035).
A first draft of the activity plan will be written based upon the above
conclusions, and circulated to RIPE for discussion. The aim is to final-
ise and approve the new plan during the next RIPE meeting.
Action: 16.24 Rob Blokzijl To finalise the RIPE NCC Review draft report
and document and send the reportto the ripe-list for approval.
Action: 16.25 Rob Blokzijl Comments received will be incorporated into a
first draft and circulated to the ripe-list for further comments. Dead-
line: next RIPE meeting in January 1994.
19. Next RIPE meetings
The scheduling of the next two meetings was extensively discussed and the
following dates and locations were agreed:
o January 24-26th, 1994 - Amsterdam
o May 16-18th, 1994 - Amsterdam
20. AOB
20.1. RARE CoA
The next CoA meeting is the last CoA to be attended by Rob Blokzijl
representing the HEPnet community. He will be replaced by a consortium
from EKFA.
20.2. RIPE meetings
Concern has been expressed that the size of RIPE meetings has grown too
large for efficient work to be done any longer. Rob Blokzijl agreed to
draft a document on possible ways to reorganise the meeting
Action: 16.26 Rob Blokzijl Draft document with suggestions on how to
reorganise RIPE meetings. Circulate to the RIPE list for discussion
21. Closing
Rob Blokzijl thanked the participants for attending and declared the16th
RIPE meeting closed.