Skip to main content

RIPE 19 Minutes

1. Opening

1.1. Welcome

Rob Blokzijl welcomed the participants to the 19th RIPE meeting hosted by the Faculty of Science at the University of Lisbon, Portugal.

1.2. Apologies

Apologies were received from the following

  • Don Stikvoort
  • Daniele Vannozzi
  • Antonio Blasco Bonito
  • Dave Morton
  • Glenn Kowack

1.3. Papers tabled

  • Agenda for the 19th RIPE meeting
  • Working Group Agendas - one document
  • RIPE Database Transition Plan - DRAFT
  • RIPE NCC Report - Daniel Karrenberg

2. Welcome from the University of Lisbon

Professor Joao Corte-Real, Head of the Faculty of Science at the University of Lisbon, gave a short welcome speech to the participants of the 19th RIPE meeting.

3. Agenda

The agenda was approved. Note: some of the agenda items were rescheduled during the meeting but they are minuted as originally scheduled. A BOF was proposed by Stephan Biesbroeck on "Trouble Ticket Systems" for the morning of Tuesday 13th September.

4. Minutes of the last meeting

The minutes from the 18th RIPE meeting were approved with no changes.

5. Review of the action list of the last meeting

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

Action: 17.1 Glenn Kowack
Volunteered to write a paper for discussion which would focus on a funding model for the RIPE NCC.

Action: 17.7 Wilfried Woeber, NCC
To produce the necessary documentation for the new DB software - ongoing.

Action: 17.8 NCC
To update and re-circulate the RIPE-Handle proposal and then go ahead with the implementation - pending.

Action: 17.11 NCC
Investigate and propose a syntax-checking facility for the new database software. Volunteer needed.

Action: 17.20 Oleg Tabarovsky
To collect data on external lines and res- trictions applying to each line that will form part of the Russian backbone.

Action: 18.3 Geert Jan de Groot
Investigate monthly publication of error files on reverse zone files, similar to the host count error files.

Action: 18.5 Wilfried Woeber
Post the CEEnet Initiative maps to the RIPE FTP server.

Action: 18.16 Everyone in the Mbone WG
Send in your Mbone maps to Erik-Jan Bos.

6. RIPE NCC Report

Daniel Karrenberg presented the NCC Report. The report focused on the explosive growth of the Internet in Europe. Statistics showing the increase in the number of Internet hosts in Europe were presented as well as statistics relating to the growth of the Internet Registry function. The most surprising correlation was that of the growth of the DNS hosts and the parallel growth of the number of local registries. Giving support and guidance to new local registries now constitutes a considerable workload effort on the NCC (on the "hostmaster" role). This, combined with the growth in the number of incoming messages to hostmaster means that the situation is close to getting out of hand. The speed and impact of this growth was not fully anticipated. However the positive side to this, is that the RIPE NCC should receive more income from these new registries and additional income is needed now!

Previously reported was the shortage of personnel at the RIPE NCC and the consequent implications of this situation, curtailing services. This is now seen to be happening with several items of the RIPE NCC Activity Plan not being performed. Specifically, the last Quarterly, due in June was not produced, database documentation has not been done and there is no technical development work being done by RIPE NCC Core staff. From the audience the feeling was that the Quarterly reports were a valuable source of information and should not be curtailed. The NCC maintained that the format of the Quarterly reporting could be revised if that was felt necessary. It was noted that the audience of the reports could be widely differing - on the one hand - technical and on the other, management. The NCC took on an action to find out what the RIPE community felt necessary to be included in the reports.

Action: 19.1 NCC
To survey RIPE community on content of RIPE NCC Quarterly Reports.

Partially alleviating the staff shortage problem has been the appointment of Mirjam Kuehne, an MSc graduate from the University of Berlin in Computer Science. However, as previously documented a further engineer is required to work at the RIPE NCC on Core Services, but this position has not yet formally been approved. At least one further engineer is needed for 1995 growth. Furthermore, the PRIDE project ends in October 1994. Tony Bates is leaving RARE and RIPE at that time. It was proposed to the RIPE community to consider whether the routing registry should be maintained. If so, a further engineer will be required at the RIPE NCC to work on the maintenance of the registry.

There were a number of comments received from the audience on the staffing problem and on the growth of the Internet in general. There was a suggestion that temporary fixes to the NCC staff shortage problems could be found by "loaning" service provider engineers for temporary periods. In principle, this is a good idea, but the only problem is that experience has shown that the staff would need to be "on loan" for a minimum of 6 months.

Finally Daniel reported that an NCC Contributors meeting had been scheduled for 21st September to take place at the RARE offices, Amsterdam.

Copies of the presentation slides can be found in the RIPE document store in the presentations directory, file:

  • ftp://ftp.ripe.net/ripe/presentations/ripe-m-19-dfk-NCC-REPORT.ps

7. Joint Projects - Status and Progress

Tony Bates gave an update report on the status and progress of the PRIDE project. Since the last RIPE meeting the following progress can be reported:

The first PRIDE guide has been compiled and was used in conjunction with the first PRIDE course held at the RIPE NCC, Amsterdam. The guide is available by ftp from the following directory:

  • ftp://ftp.ripe.net/pride/docs/guide-1.0.ps.tar.Z

As a result of the large number of recent changes to RIPE-81++, a second updated version of the guide will be produced.

A large amount of effort has gone into the RIPE-81++ document as it now stands and it now incorporates many new database issues, dealing with for example, the new "inet-rtr" object, the transition of the database to classless and new authorisation procedures. Work has been done in conjunction with other Routing Registries.

PRIDE Tools

There have been several minor releases while the current release pride-tools-1.0.7 can be found in:

  • ftp://ftp.ripe.net/pride/tools/pride-tools-1.0.7.tar.Z

There have been lots of bug fixes. Recently added tools are:

  • "prpath" - AS-MACRO support
  • "maxpand" tool - will expand macros for you

PRIDE Course

First course was given in Amsterdam in May 1994. Formal written feedback from the participants of the course was collected in the form of an evaluation questionnaire. The results were compiled into a report which is available by ftp:

  • ftp://ftp.ripe.net:ripe/pride/report/pride-tools-1.0.7.tar.Z

More PRIDE courses are planned in the near future. There have been offers from potential hosts in Vienna, London and Pisa.

Copies of the presentation slides can be found in the RIPE document store in the presentations directory, file:

  • ftp://ftp.ripe.net/ripe/presentations/ripe-m-19-tony-PRIDE-ps.Z

8. RIPE NCC: Finance and Management RIPE NCC Management Committee

Rob Blokzijl reported on the initiative by RARE in organising a meeting of ISP's. Invitations have been sent out to all local Internet Registries in Europe to attend a meeting which will be held at the RARE offices on 21st September, 1994. This will be a meeting to discuss issues relating to the funding of the RIPE NCC and to charging for RIPE NCC services.

RIPE - Proposal for Legal Status

Rob Blokzijl suggested that the RIPE NCC now needed a legal status that was separate from RARE. It needed to be a legal entity of its own. Assistance will be sought from organisations like EBONE and EUnet who are familiar with some of the legal procedures. Under European Law it is now possible to set up a company which is "European". There has been an offer from EUnet to fund the legal costs associated with setting up this company. The legal implementation in each of the different European countries must be investigated and everyone in the audience was urged to research this in their country.

There were a number of comments from the audience concerning this proposal. Specifically there was concern over non-European countries membership of an organisation which is defined as "European". Rob replied that most countries have some agreement with the European Union which covers this, such as "Joint East-West" ventures. Daniele Bovio expressed concern about the overhead incurred by setting up an association. It was noted by Daniel Karrenberg that you would need someone to underwrite a budget of roughly half a million ECU.

Rob encouraged all participants present at the meeting to take the proposal to their home organisations, research how this proposal could be implemented and come to the next meeting with a concrete understanding of how it works.

9. RIPE: Restructuring the Organisation - I

Reported under agenda point 12.

10. European Operators Forum (EOF) Report

Peter Lothberg gave a brief introduction to the background of the European Operators Forum (EOF) and reported on the meeting held on September 12th at 9.00 am. The topics discussed at this meeting were:

  • Traffic exchange and routing between service providers -> a draft paper is being prepared
  • Exchange points in Europe presentations: status, terms and conditions
  • CIDR route flapping
  • MEP Routing problems
  • EOF charter
  • Mae East upgrade

The next meeting will be convened in the UK in November. There has been a suggested date of November 21st.

11. Reports from the Working Groups

11.1. Local-ir Working Group

Chair: Mike Norris
Scribe: Anne Lord

The agenda was agreed as previously circulated and Anne Lord agreed to act as scribe. The minutes from the last Local IR meeting had been circulated shortly after the 18th RIPE meeting, and were accepted.

11.1.1. European Registry report

RIPE NCC - Daniel Karrenberg

In the plenary session of the previous day DFK reported on the unexpected growth of the Internet. This has reflected itself in a significant increase in the number of new local registries and consequent workload in the NCC hostmaster role. The impact is such that the coordination task for the RIPE NCC with respect to the local IR's is close to getting out of hand. At some point in the near future there should be a task on the working group to review the method of registry operations.

Related to this, it was noted that there is a need for some formalisation and training for these new registries as well as offering support to existing registries. Mike Norris agreed to raise this as an action point at the next meeting.

Action: 19.2 Mike Norris
At the 20th meeting to raise the training of local IR's as a topic for discussion.

11.1.2. RFC 1597 - experience of use

After RFC 1597 was published an opposing RFC 1627 was written. It was noted at a recent IAB meeting it was decided that despite this, the address space assignments in RFC 1597 stand as published. Informally there has been a request to write a new document obsoleting both and clarifying the situation.

Daniel Karrenberg noted that current policy of the NCC and recommendation to local registries is to direct requests for large amounts of address space to read and consider using private address space. The trade-off is either: use private address space (with all the implications understood) or be subject to usual strict assignment criteria which apply when requesting large amounts of address space.

It was noted by the group that the existence of RFC 1597 had been useful in dealing with some large requests.

11.1.3. Funding of and charging for local IR services

This was a continuation of e-mail discussions raised by Hank Nussbacher. It was felt important to focus only on charging issues because of the disparity of local IR funding models.

In the course of the discussions it was noted that by charging you create a market and that the existence of one last resort IR per country could lead to monopoly charging.

The discussion was quite varied and fairly unstructured. Daniel suggested that a useful step forward would be to document some of the problems associated with charging. Daniel agreed to make an inventory document of the problems associated with charging for address space.

Action: 19.3 Daniel Karrenberg
To make an inventory document of the problems associated with charging for address space.

11.1.4. Granularity of assignments

Previously circulated some time ago was a proposal by Daniel Karrenberg advocating the use of private address space as a solution for dealing with the potential waste of address space incurred by very small enterprises (VSE's) not going to be connected to the Internet. Such organisations would be required to renumber once they connect to the Internet. The suggested cut-off point for a VSE is less than 32 hosts.

After some discussion there was consensus that this proposal should be revived again.

Action: 19.4 Daniel Karrenberg
To recirculate draft proposal on use of private address space for VSE's not connecting to the Internet. Circulate proposal to the WG mailing list.

It was also noted by Sabine Dolderer that an increasingly frequent type of request are those received from small companies whose parent organisation forces them to obtain a class C address where subnetting could be used.

11.1.5. Reports of significant events

It has been noted there is some disparity in the assignment criteria of the regional registries (RIPE NCC, INTERNIC and AP-NIC) and the IANA. A mailing list of regional registries has been created at the NCC to facilitate discussion. However there has been no participation from the INTERNIC to date. The next initiative is to organise a meeting with the regional registries, the IANA and some representatives of the RIPE local IR Working Group. The RIPE NCC agreed to organise a meeting between regional registries, with representatives from the RIPE Local IR working group.

Action: 19.5 RIPE NCC
To organise a meeting between regional registries, with representatives from the RIPE local-IR working group.

11.1.6. Reverse domains - counts and errors

Due to time constraints the action on Geert Jan to investigate reverse domain delegation errors was carried forward to the next meeting.

With the many new small provider emerging there was a question relating to who would administer reverse domains of partially delegated C blocks. Currently the NCC administers these domains and would continue to do so as there is a trade-off between address space saving and lame delegations.

Reverse delegation on non-octet boundaries is currently under consideration for the next revision of BIND.

11.1.7. Tools

Assignment status A tool has been developed by Willi Huber and Wilfried Woeber to check assignment status of networks. The tool was thought very useful and thanks were extended to the developers.

New attribute "status" Geert Jan de Groot proposed a new attribute to the inetnum object "status" to describe whether a network(s) is delegated, reserved or assigned. The proposal will be written up and circulated to the RIPE DB Working Group for review.

Action: 19.6 Geert Jan de Groot
To document new attribute "status" proposed to describe whether a network is delegated, reserved or assigned.

AOB ripe-115

Document expires end september. The next expiry date will be six months hence. It was noted that there should be more emphasis on contacting a service provider and the last resort registry should be "last resort". The revised document will be circulated to the list to further comments.

Action: 19.7 RIPE NCC
Circulate revised ripe-115 to the local-ir mailing list for comments.

List of service providers

There was consensus that there should be a list of service providers in some agreed format and that the RIPE NCC should house the list. The list will only be open to financial contributors of the RIPE NCC.

Action: 19.8 Daniel Karrenberg
To prepare specification for the format of the list of service providers.

Class A chopping

In the event of CIDR and classless addressing local registries were encouraged to chop up class A addresses and test whether routing equipment could handle the classless assignment. If not they were encouraged to contact their router manufacturers and complain.

11.2. Database working group

Chair: Wilfried Woeber
Scribe: Havard Eidnes

11.2.1. Opening

Havard Eidnes volunteered to take the minutes.

The proposed agenda item "review of DB-WG in the context of a changing RIPE" was moved to the end of the agenda. An item about "review of domain object for in-addr.arpa" was added.

11.2.2. The classless database

Marten Terpstra from the RIPE NCC gave an overview of what changes have been implemented and how this can be tested. The major changes are:

  • Change of representation of IP addresses and ranges in the database, as described in the documents:
    • ftp://ftp.ripe.net/ripe/drafts/ripe-clarep.{ps,txt} and
    • ftp://ftp.ripe.net/ripe/docs/ripe-inetnum.{ps,txt} documents.
  • There are two new notations, classless prefix such as 192.0.0.0/8 and classless range (currently proposed as e.g. 192.3.2.0 > 192.3.3.255, this covers two class C networks).
  • Lookups in the new database will return the exact match if it exists, or the first less specific object.

There are some options to control the matching:

  • -L return all less specific entries
  • -m return the direct more specific entry
  • -M return all the more specific entries

The database itself has been split into individual files for each object type. More new query options:

  • -t returns a template or form for the specified object type
  • -T return only objects of the specified type
  • -F do a "fast and raw" return of data, i.e. no post-processing or reference formats
  • -S do not add syntactic sugar (such as "accept", "from" etc in AS object)

A beta version of the database software is already up and running. It now consists of some 9000+ lines of Perl code. The software is still undergoing changes to accommodate the updated RIPE-81++ and to add authorization. There is a test server running at rijp.ripe.net which can be used to become familiar with the behaviour of the new code.

A proposal was made to allow objects to be submitted to this test database, and Marten Terpstra agreed to set it up. These submitted changes will be removed from the database on a daily basis, as the data from the production database is pulled in.

Action: 19.9 Marten Terpstra
To set up environment to allow objects to be sent to a "test database".

Current planning (as of the time of the RIPE meeting) calls for a move to using the new software in early October.

The draft documents "ripe-clarep" and "ripe-inetnum" were approved. Please note that since the meeting they have become fixed RIPE documents:

  • "ripe-clarep" has become ftp:/ftp.ripe.net/ripe/docs/ripe-121.{txt,ps}
  • "ripe-inetnum" has become ftp://ftp.ripe.net/ripe/docs/ripe-119.{txt,ps}

11.2.3. Authorization

Daniel Karrenberg from the RIPE NCC explained what changes are being proposed to improve (implement) authorization of updates in the RIPE database. This is being done by introducing:

"maintainer" object

"Maintainer" (mntner) object describing an entity responsible for a set of objects in the database, and where this maintainer wishes to secure his updates and prevent others from submitting changes to objects maintained by this maintainer going un-noticed.

Important attributes:

  • upd-to - send notifications of updates to this address
  • mnt-nfy - basically same as "notify"
  • auth - specifies authentication methods (in "mntner" object)

Authentication methods proposed:

  • NONE - no authentication (today's method:-)
  • MAIL-FROM update will only be accepted if mail containing a database update originates from an e-mail address matching the regular expression.
  • CRYPT-PW stores a crypted password, send a "password:" attribute (with the password in clear text) together with each update.

A single maintainer can register more than one authentication method. Any individual object can be linked to more than one maintainer entity.

The "password:" line(s) in update requests are not considered to be part of an object, thus no password will ever be forwarded by using the notify, mnt-nfy or similar attributes.

A question was raised how one could be notified of the creation of new objects in the database. Guardians of communities and ASes will be notified when components are added/changed/removed. Notification will also be given when multiple "route" objects are registered with same key but different origins. However, the addition of a more specific route with a different origin than the immediate less specific route registered, the maintainer/guardian of the AS where the less specific route originates would probably not be notified (this was asked for).

11.2.4. inet-rtr (Internet Router) object

There had been some recent input from the MBONE group; they wish to use this object to register details about IP multicast routers. However, the inet-rtr object is needed now by the PRIDE tools, so there was consensus that we should approve the document as it is. After some more discussions within the MBONE community a written proposal to extend the object is expected before the next RIPE meeting.

Action: 19.10 Erik Jan Bos, Wilfried Woeber
Written proposal to extend the "inet-rtr" object ready before RIPE 20.

11.2.5. Database transition

The RIPE NCC people summarized the transition issues when going from the old database to the new one. There will be changes in:

  • schema o procedures
  • user interface

The WHOIS interface and the output from queries will have some changes (e.g. the classless representation is used instead of the old one).

The guardian procedures will change; first there has to be an exact match between the entries in the guardian file and the entries in the database. The current database has been cross-checked with the current guardian files, and there are lots of conflicts in this area. When the new database software is put into production, the RIPE NCC will produce "problem" files in each guardian's home directory, and the guardians are strongly encouraged to clear these up before phase II of the database transition.

The transition will happen by two "big bangs": B1 and B2.

At B1:

  • the new classless database will be put into production
  • users of NLC will have to transition to using Merit's ALC program, as NLC will not be upgraded to support the new database. ALC functionality was described as being a superset of NLC.
  • Guarded objects can be updated under control of the new authorization i mechanisms o The RIPE NCC will create prototype "mntner" objects in each guardian's home directory
  • The RIPE NCC will prepare new "inetnum" and "route" objects in each guardian's home directory

Due to logistic concerns, between B1 and B2, updates for networks with allocation and routing information already split into separate objects (inetnum/route) will probably not be permitted.

At B2:

  • complete transition to the new database

Proposed time schedule:

  • B1: early october
  • B2: 4-6 weeks later

The issue of how queries posed in the "old style" would be interpreted ensued -- the question is whether e.g. 128.39.0.0 should be interpreted as 128.39.0.0/32 or 128.39.0.0/16. In most cases the end result will be the same, since the immediate less specific object will be returned, although some expressed the opinion that the latter of the two interpretations would cause less confusion. Marten Terpstra held the opinion that /32 should be used, but apparently this needs to be discussed more.

The database aspects of RIPE-81++ were approved (although the range notation may change). A proposal from the RIPE NCC to add "as-name" to the AS object was approved.

11.2.6. Domain object for in-addr.arpa

Concern was expressed that with the advent of the classless database we may end up registering duplicate information, since the in-addr.arpa delegation hierarchy can now be implemented "properly" by use of the "inetnum" object.

After a short discussion it was agreed that the RIPE NCC would review the opinions and come up with a new domain object proposal to cover this.

Action: 19.11 NCC
To propose new domain object for in-addr.arpa

11.2.7. Time stamps in the database

The people from Merit had expressed a desire to store more fine-grained time stamp information in the database, and had proposed to do this by adding hhmmss at the end of the "changed" attribute.

This was hotly debated and contested from some parties, but there was consensus that there is a need to ensure that older updates stuck in mail queues would not be released later and overwrite more recent update requests.

To solve this, it was decided to add an optional sequence number to the "changed" attribute after the date string.

This sequence number can, of course, be derived from local (at the origin of the update) hhmmss information. However, no time semantics of any form are implied.

The people from Merit also wished to use this in some situations to produce a "consistency snapshot" of the database at a given time (in retrospect). Again it was contested whether the proposed simple mechanism would solve that issue.

There will probably also be a separate new attribute called "stored" or "processed", which will record when the object was actually entered in the RIPE database (local time at the RIPE NCC).

Action: 19.12 Marten Terpstra
To write up the proposed "stored" /"processed" attribute.

11.2.8. RIPE handles

This activity has been put on hold due to RIPE NCC overload. RIPE handles can be assigned on a case-by-case basis as the need arises. There are however too little resources available to carry this through together with the imminent database transition.

11.2.9. Ownership of objects

This issue was overtaken by events, ref. the notify/maintainer changes.

11.2.10. Inverse recursion

A query for added functionality had been raised; the trigger is the ability to pose a query like the following one: "give me all the objects where person XX is registered as a contact person".

Marten Terpstra said this would probably take little time to add to the new database, and he would look into finding the extra time to do this.

11.2.11. Data exchange between IRs

This has also been put on hold by the RIPE NCC, due to the lack of RIPE handles (see point 11.2.8).

The advent of whois should improve this situation, and the entries for the blocks 193.* and 194.* will point at the InterNIC whois server at the RIPE NCC.

Otherwise a full merge of the databases (basically InterNIC and RIPE NCC) is difficult, since there are many conflicts between these databases outside of the 193.* and 194.* blocks, and who to "trust" in each case is uncertain.

11.2.12. CLNS routing registry

Put on hold since the need for this is unclear, and the RIPE NCC do not have many resources to put into activity.

There has also been a lack of input from the interested parties. Nevertheless, the functionality already implemented will be carried over to the new software and remain usable.

11.2.13. Review of DB-WG in the context of a changing RIPE

The DB WG chairman expressed a desire to have the possibility to arrange at least a single non-parallel session during each RIPE meeting dedicated to the DB issues, since much of the work in other WGs touch on the DB. This will be conveyed to the RIPE chair for the next meeting.

11.2.14. AOB

None. Meeting closed.

11.3. Connectivity

Chair: Milan Sterba
Scribe: Mike Newel

11.3.1. Chairman's introduction

Introduction of the participants. This working group is not a traditional working group in the sense that it serves as a forum for exchanging information rather than driving standards.

11.3.2. CEENet update by Jan Gruntorad (CEENet treasurer)

Connectivity

Not much news from the February '94 meeting. Next meeting is in October in Budapest. Goal of the CEENet is better coordination in the region.

First phase (PHARE 91) included 2.5M ECU, funded connectivity in the Czech Republic, Slovakia, Poland, Hungary, and Romania. Work was managed by a contractor for the EC and has been found unsatisfactory. The funding expired in June of 1994. Next goal is 4M ECU to extend connectivity to all countries in the region.

October meeting PHARE is to decide how to allocate funds. Technical groups are now forming. CEENet wants to be more actively implicated in the management of the project. Four groups have been approached (DFN, DANTE, INRIA and EUnet) No technical stuff is expected to be discussed in the October meeting.

Question: What is the relationship between the and CEENet and PHARE? It's different in each country. The PHARE representative is from some ministry, while the CEENet representative is from the network organization; in some cases this can be the same person.

Question: How are the funds allocated? They are 2 year funds distributed specifically to networking.

Question: Does the PHARE extend to Russia? No, it only extends to Ukraine and the Baltic States.

11.3.3. DANTE-Europanet extension to Central and Eastern Europe

Tim Streater from DANTE was present but felt he was not knowledgable enough to be 100% accurate. Referred to Chris Broomfield for information about this topic.

For funds allocated in 1991 equipment to support X.500 spreading in CEE was sent out in June 94. These delays between money allocation, project design and implementation phase cause serious problems and are CEENet's main concern.

Question: Several meetings ago the push for IXI extension to CEE without topological and technological coordination with other (namely local) networking initiatives was felt as a serious problem.

Has the problem with IXI coordination improved?

In the meantime IXI became Europanet, which presents considerably better performance and connectivity characteristics than IXI. Some CEE countries use Europanet as their principal international link (Czechia. Slovenia). Link to Hungary is also installed. Other planned connections are still pending.

11.3.4. Regional updates

RIPE now has a uniform way to publish connectivity info via the RIPE Connectivity Document Store. Please use this way to get information.

Bulgaria:

Nobody present. The chair noticed a large growth in number of connected hosts recently in Bulgaria.

Czech Republic:

  • The link established for INET (0.5Mb) is still in place connecting to Europanet in Amsterdam; the vendor is holding the line hoping for retro-funding in October. EU has been asked to contribute to keeping the line up.
  • There is a 128Kbs circuit between Prague and Vienna.
  • There is a 64Kbs SANET circuit from Banska Bystrica to Prague.

Question: How does CZ split traffic between EBONE and Europanet? The Czech academic network CESNET is artificially split into two AS's one nearer to Ebone and the other to Europanet. Routes are announced both sides except for sites which don't fit the Europanet AUP.

Hungary:

  • About 10 major cities are now or soon to be interconnected.
  • There are 4 64Kbs links out - 2 to EBONE in Vienna and 2 to Europanet.
  • They are asking for both links to be upgraded to 256Kbs.

Baltic States:

  • Estonia has a 128Kbs link to Helsinki and a 64Kbs satellite link to St. Petersburg.
  • Latvia has a 64Kbs circuit to Oslo
  • Latvia is connecting a direct link to Stockholm.
  • The BaltNet program expects to receive 4.5M Danish Kroner and support from ISF and plans to double connectivity.

Poland: Nobody present.

Romania: Nobody present.

Slovenia: Nobody present.

Slovakia:

  • Currently has 2 international lines to Prague and Vienna (19.2Kbs upgraded to 64Kbs). Both lines are currently overloaded.
  • They had hoped that for one link from PHARE project. They plan to upgrade these lines but first they need to upgrade their internal backbone.
  • The service on the present lines is good.
  • They want to remain connected to EBONE rather than Europanet (due to AUP)

Russia (and other xSU)

DESY Moscow/Radio MSU (reported by Dmitry Avdeyev)

  • Currently has a 256Kbs satellite link from DESY to MSU.
  • There is also a 64Kbs satellite to the Yerevan Physics Institute (NSK) Armenia. This link supports a single IP network (194.67.64.0) but can be used to provide other connectivity as needed.

There is a planned direct link from NSK to DESY to avoid two satellite hops.

Question: Are there plans to connect other sites? Yes.

Question: Are there plans to connect other states? Yes.

Question: Who is funding this? Armenia via the Armenian Foundation in the US.

Question: Other links planned? One from Italy and also one to Potsdam.

ISF (reported by Rob Blokzijl)

  • The Moscow Metropolitan Fibre is coming back on track. It will consist of a 100 Mbps FDDI ring.

Question: Will DESY carry traffic over ESNet? No. Transit traffic will use Europanet since ESNet won't carry transit traffic. ESNet will carry transit traffic to NSI.

  • ISF approved the project. They also approved a project in Ukraine (Kiev). Money has been allocated.
  • ISF has allocated money for a St. Petersburg project. One proposal consists of constructing a local network using fibre in conjunction with the local power company (Lenenergo).

Question: Has the Moscow fibre project progressed? Not since the last meeting.

There is a planned 64Kbs satellite link to Potsdam.

11.3.5. CDS update

CDS = Connectivity Document Store, a place to store information about your network, its functions, and its connectivity. You should send CDS entries to "[email protected]". The format was described in the last minutes. The documents are visible via WWW via the RIPE NOC (and other links), via ftp, gopher and even e-mail.

Participation is limited to organizations which support the NCC. Of the over 100 networks in RIPE, this comprises about 40 networks. So far only a few networks are participating: Bulgaria, the Czech Republic, France, Poland, and Slovakia.

If you don't contribute to the RIPE NCC you don't get to list yourself. (Much discussion about networks not participating because they feel they've already done this at least once (for the RIPE NOC) and in many cases more than once with their own local documentation.)

Conclusion: network providers can supply Hypertext links to include existing documentation. Concerning this, the chair agreed to send e-mail to the prospective contributors to the CDS directly. Establish HTTP links as needed.

Action: 19.13 Milan Sterba
Send e-mail to the prospective contributors to the CDS.

11.3.6. Stagnation in CEE networking?

Looking at absolute increases in service there was some concern expressed by the chair that CEE networking is stagnating. Milan Sterba had run some statistics, with (1) being countries with stable growth, (2) rapid growth, and (3) plateau (little or no growth.) Studies indicate group 1 contains Ukriane, the ex-Soviet Union, Slovenia, Romania, Latvia, and Hungary. Group 2 includes Bulgaria, Lithuania. Group 3 includes the Czech Republic, Poland, and Slovakia.

After further reflection the group felt that this was probably reasonable; Group 1 countries are just funding new circuits and getting new connectivity; Group 3 (the concern) have probably finished major projects and are now consolidating and using services.

11.3.7. Mission and future of the working group

Does this forum make sense? General consensus is that it does. Many participants feel that it provides an excellent forum for discussing connectivity between countries and "catching up" on what everyone is doing.

Mailing list: "[email protected]".

11.4. Routing

Chair: Jean-Michel Jouanigot
Scribe: Gilles Farrache

11.4.1. Previous minutes, agenda

The previous minutes and the agenda were approved. Gilles Farrache volunteered once again (?) as a scribe.

11.4.2. Ripe-81++ and companion documents

Reading:

  • ftp://ftp.ripe.net/ripe/drafts/ripe-81++.{txt,ps}

Please note that since the RIPE meeting this document has been published and is now fixed as:

  • ftp://ftp.ripe.net/ripe/docs/ripe-181.{txt,ps}
11.4.2.1. Summary of changes since last version of the draft

Reading:

  • ftp://ftp.ripe.net/ripe/drafts/ripe-81++.changes.{txt,ps}

Tony Bates presented the modifications added into the Ripe-81 draft document since the Working group meeting in Amsterdam:

  • Network lists have been added
  • More information on the default route generation
  • "sugar" added
  • as-reject is renamed as-exclude
  • line wrapping feature
  • 'Component' attribute is replaced by 'withdrawn' and 'hole'
  • A new router object has been created: inet-rtr
  • The evaluation of the various operators (OR, AND,...) has been clarified
  • An 'as-name' attribute has been added to the aut-num object (optional, for transition reasons, but will become mandatory)

The Working group unanimously agreed these modifications.

11.4.2.2. Outstanding issues

interas-in/out and as-in/out

The interas- in/out attribute in the aut-num object is needed to represent local policies between two ASes peering at several points.

The possibility to merge the as-in/out and interas-in/out attributes was rejected because of clarity and the fact that only the global policy (expressed in as-in/out) is relevant to other ASes.

To identify a peering, the local and remote ID routers are needed (ID means here the interface addresses, not the BGP router ID). A syntax was agreed for the interas-in/out attribute:

interas-in: [from] ASxxx

It was agreed that both and are mandatory. It was also noted that as-in/out attributes can be filled automatically if only the interas-in/out attributes are present. This is an implementation issue when registering and object, but the output of a database query MUST contain the corresponding as-in/out attribute when an interas-in/out attribute is present.

It was agreed that these decisions should be integrated into the current draft (or clarified when already present); this draft will be presented as the final document to RIPE, sent to the list, and hopefully agreed. Deadline for comments was fixed to Friday September 30th 1994. The final Ripe-81++ document will be renamed Ripe-181.

It also was proposed to publish this document more widely (as an Informational RFC) so that other routing registries may join the effort. Final decision will be taken when the final document is approved.

11.4.3. Router object

Reading:

  • ftp://ftp.ripe.net/ripe/drafts/inet-rtr.ps

Please note since the RIPE meeting this document is now fixed as a RIPE document and can be found in:

  • ftp://ftp.ripe.net/ripe/docs/ripe-122.{txt,ps}

The previous 'inetnum:' object used to have an 'ias-int' attribute to help the tools (i.e. prtraceroute) to determine which AS a router interface belongs to. In the new database model, a new object describing the internet routers has been created to register this information as well as peering relationships. The syntax is:

  • ifaddr:

It was also agreed that the list of routing protocols allowed in the peering information should be flexible, and that IGP was too generic. Using the name (and sometimes version) of the protocol helps in determining if the routing protocol is CIDR capable or not. The Working Group unanimously agreed that this object should not be used for the configuration of routers.

It was agree to propose these extensions to the Database Working group ask them to approve the changes urgently.

11.4.4. AOB

The chairman thanked the working group members for their active participation, Merit for their very valuable input and the PRIDE project for its essential contribution to this work. Jean Michel announced his intended resignation as chairman of the RIPE routing group and requested that anyone interested in chairing the group should contact him. And finally, the meeting thanked the chairman for all his very valuable time and effort in chairing the working group

A new charter for the group is to be proposed. Comments/suggestions should be sent to the list.

11.5. MBONE Working Group

Chair: Erik-jan Bos
Scribe: Tim Streater

Agenda:

  • Opening
  • Terms of Reference
  • European Mbone FAQ
  • European Mbone Topology
  • Protocol Independent Multicast - PIM
  • Relationship to MICE
  • AOB

11.5.1. Opening

Erik-Jan opened the meeting and welcomed everybody.

11.5.2. Terms of Reference

A few weeks ago, Erik-Jan sent mail to the list [email protected] which contained a URL pointing at the Terms of Reference. He hoped all had a chance to look at them. In addition, copies of the Terms of Reference were handed around. There were various paragraphs:

  • Why there is a working group.
  • Tunnel layout or topology.
  • New technologies.
  • Applications.
  • Organisation.

Erik-Jan advanced the view that the WG's purpose was to discuss the tunnel infrastructure, rather than applications which use it. A question was raised as to whether the WG should discuss every application which might use IP multicasting (such as News). The general feeling was that new applications can be regarded FYI inside the WG, but that no work on this issue should be started inside the WG. Peter Villemoes asked whether the WG recommends or implements, Erik-Jan responded by saying that it makes recommendations and says nothing about implementations.

11.5.3. European Mbone FAQ

Erik-Jan told the meeting that he had started this, which was considered to be useful. In Europe there is more incentive to conserve bandwidth than in the US. Geert Jan suggested it might be better to just add stuff to the already existing US FAQ. The question here is whether it is possible to add stuff to this FAQ. Milan Sterba suggested cross-pointers, Erik-Jan said there was already a pointer in his, to the US FAQ, he took it as an action item to get a pointer into the US FAQ to his. He felt that having a separate one was a good idea due to the size of it, such as a list of providers. Geert Jan worried about this being out of date, but it was pointed out that this applies to any database. The URL for the FAQ is:

  • http://surver.wind.surfnet.nl/ejb/mbone-faq.html

At the same site is mbone-tor.html for the Terms of Reference, and WG information in mbone-wg.html. In response to a question, Erik-Jan said that the FAQ points at three European Mbone maps.

11.5.4. European Mbone Topology

This item relates to keeping up to date, also contact people, and information about where the m-routers are. However, Erik-Jan's lists are not up to date. Geert Jan suggests using the RIPE database, the rtr element. Peter Lothberg pointed out that in a multicast world, the m-routers no longer exist. However, it was felt that this would be useful for managing the situation today. One could have various elements, such as:

  • inter-rtr
  • contact
  • tunnel - metrics
  • rendezvous points

Erik-Jan took it as an action item to write and distribute a couple of pages on how to use the rtr-obj in the RIPE db for this purpose.

Action: 19.14 Erik-Jan Bos
Write short document describing how to use the rtr-obj to describe location of m-routers.

11.5.5. Protocol Independent Multicast (PIM)

This is able to run in two modes. There is a dense mode where there are fat distribution trees which one prunes later. There is also a sparse mode, which assumes a more global picture. There are well-known rendezvous points via which connections are made initially. Then trees are built which in the end may not even involve the rendezvous points as the trees are optimised. The rendezvous points are somewhat independent, therefore, of multicast sources. PIM is documented in draft-ietf-idmr-pim-arch-00.ps, in draft-ietf-idmr-pim-sparse-spec-00.ps, and in draft-ietf-idmr-pim-dense-spec-00.ps. Today's Mbone is based on RFC 1075. The expectation is that these drafts will become RFCs at the next IETF. Cisco expects to have this in version 10.2, about in October 1994. Erik-Jan took it as an action item to find out about other vendors' implementations.

Action: 19.15 Erik-Jan Bos
Find out about other vendors' implementations of PIM.

11.5.6. Relationship to MICE

Erik-Jan reported on a phone conversation he had with Angela Sasse of UCL, one of the coordinators of the MICE Project. Angela asked about how to coordinate between MICE (dealing with applications on the Mbone) and the service providers (coordinating Mbone infrastructure inside the RIPE Mbone WG). Erik-Jan promised to raise this issue at the WG meeting (see Point 7, below).

11.5.7. AOB

Erik-Jan asked how we might coordinate problem solving within the Mbone, e.g. in case the MICE Project discovers any problem with the multicasting infrastructure). Peter Lothberg asked whether this was problems in or problems caused by the Mbone. Erik-Jan responded that this should cover both. Geert Jan suggested that the first thing to do in case of a problem is to try to contact the site, but in the end it might be necessary to ask the provider to cut the link. The whole issue is one of coordination, and he suggested using the ripe-ops list for this purpose, to coordinate Mbone real time actions in case of problems. The suggestion is also to revisit this at the next WG meeting to see how well this works. Peter Lothberg also pointed out that there is a strong need for professional tools in this area, as Mbone is starting to be considered as a service and these will be needed before multicast goes into production.

11.6. BOF Report - "Trouble Ticket Systems"

Convenor: Stephan Biesbroeck

11.6.1. "Trouble Ticket" systems

Joachim Schmitz of DFN-NOC had previously made a small surevey of existing public domain/commercial "Trouble Ticket" systems. Please contact him if you would like a copy of his report.

11.6.2. Exchange format of Tickets

There is no common format for Trouble Tickets currently in use across Europe. Many operators follow the recommendations as specified in the document "RIPE Recommendation on Operational Contacts" (ripe-063.txt). It was agreed that a revision of this document was now needed and this was proposed as a future work item for this group.

A further work item is to promote the use of this document as it does not appear to be in wide use.

11.6.3. ripe-op mailing list

It was noted that the mailing list is currently used for a mixture of tickets and messages. A "ticket only" mailing list was proposed.

More procedures between NOC's and "handover" tickets - more discussion is needed in this areas.

Action: 19.16 Stephan Biesbroeck
To ask RIPE NCC to create a trouble ticket only mailing list which is maintained by the RIPE NCC

12. RIPE Restructuring the Organisation - II

12.1. RIPE meeting format

There has previously been concern about the frequency and efficiency in the current structure of RIPE meetings. Daniel Karrenberg formally proposed to change the existing format of the RIPE meetings to the following:

  • day 0 Working Group meetings
    WG Convenors have the responsibility to organise working group sessions

Formal agenda of the RIPE meeting:

  • day 1 "Presentations" or reporting from the Working Groups RIPE Dinner in the evening
  • Day 2 "Consensus"

This proposal was accepted and would be implemented at the next RIPE meeting

There were some questions from the audience regarding the new format. Specifically, there were concerns over the parallelism of working groups and whether this 2 day format would actually encourage attendees not to attend the working group sessions. It was felt however, that this might encourage only those with a real interest to attend the working groups. The sessions might therefore be more productive.

13. Network Status Reports

13.1. EBONE (Wilfried Woeber)

There has been a major restructuring of EBONE since the last RIPE meeting (end of June 1994), which has actually resulted in the cessation of EBONE activity in some areas. As of September 1994 EBONE consists of 4 major configuration points:

  • Stockholm
  • CERN (Geneva)
  • Vienna
  • Paris

These sites (EBSs) connect the lines from the Ebone Partners. In addition to these connections EBONE has peering agreements with:

  • DESY (HEPnet community), EMPB, GARR in Geneva
  • NORDUNET (DGIX's model) in Stockholm

More peering agreements are to be expected in the future.

EBONE partners - recent changes:

  • Egypt: FRCU/EUN Cairo 64k to Paris
  • Paris: 2nd line to Washington (T1 and E1).
  • Cyprus: 64k to Prais scheduled
  • Slovenia: 64k Ljubljana to Vienna scheduled
  • Regional connections need to be upgraded.

There was a question regarding the stability of the current structure. Wilfried stated that the basic structure would now remain stable until beyond the end of 1994. There are plans however to get new partners.

13.2. Future EBONE plans (Peter Lothberg)

  • Upgrade plan on routers to support ATM on the backbone nodes.
  • multicast support plan inside EBONE. Trying to use the existing structure as efficiently as possible - dynamically rather than statically. There is work on the referral of multicast nodes downstream. Most of the current engineering resources are focused here. The PIM protocol is being used.
  • Work on Mae-East collaboration to ensure continued connectivity to the global Internet. o more bandwidth upgrades needed - this is a continual problem.
  • EBONE business moving in the direction of offering a "packaged service" There is a mutual backup agreement between EBONE and Nordunet for the transatlantic lines to the node in the USA.

13.3. London Internet Neutral exchange (Kevin Hoadley)

Otherwise known as the "LINX". It connects all main UK providers:

  • BT
  • Demon
  • EUnet GB
  • Janet o PIPEX

LINK will be in service by the end of September. It is purely a connection point and peer. There is no route server as yet. Each provider brings their own routers and connects to a common ethernet. Much of the current work is on creating a legal entity: so that there will be formal peering agreements and connections limited only to service providers. LINX is located at Telehouse, London docks. It is a financial management centre owned by Japanese Banks and 12% British Telecom. It has the following attractive features:

  • redundant power (and generators)
  • resilient connections to telephone companies
  • BOMB/earthquake proof
  • and is used also by SPRINT

14. Next RIPE meetings

The scheduling of the next two meetings was discussed and the following dates and locations were agreed subject to confirmation from the local hosts in Italy for the meeting in April/May 1995:

  • RIPE 20 January 25-27, 1995 - Amsterdam, The Netherlands
  • RIPE 21 end April/May 1995. Location and dates subject to discussions and availability. Offers have been received by GARR and by Juergen Rauschenbach for Berlin, Germany. The audience voted for Rome, Italy if the offer from GARR still stands. This will be investigated so a decision can be made as soon as possible.
  • RIPE 22 - September 1995 - Amsterdam, The Netherlands.

Following the pattern of 2 meetings a year in Amsterdam and one away, it was agreed that the Spring 1996 (April/May) meeting would be held in Berlin.

15. AOB

15.1. Renumbering of ns.ripe.net

Geert-Jan advised the audience that in the near future ns.ripe.net will be renumbered. This is important because it will affect all DNS reverse domain delegations. There will be an announcement to the ripe-list when the renumbering will take place.

16. Closing

Rob Blokzijl thanked the participants for attending and declared the 19th RIPE meeting closed. Sincere thanks are also extended to the local organisers: Pedro Amorim, Eugenia Graca and Graca Carvalho and to the sponsors of this RIPE Meeting who were:

  • European Commission
  • National Council for Research and Technology
  • FCCN