Skip to main content

RIPE 18 Minutes

1. Opening

1.1. Welcome

Rob Blokzijl welcomed the participants to the 18th RIPE meeting hosted by NIKHEF and held at WCW, Amsterdam, The Netherlands.

1.2. Approval of the agenda

The agenda was approved. Note: some of the agenda items were rescheduled during the meeting but they are minuted as originally scheduled.

1.3. Papers tabled

  • Papers - Agenda for the 18th RIPE meeting
  • Working Group Agendas - one document
  • RIPE NCC Management Structure
  • RIPE NCC Financial Contributions
  • Representation of Complex Routing Policies of an Autonomous System
  • Representation of IP Routing Policies in the RIPE Routing Registry (RIPE 81++) DRAFT
  • Report on the RARE ATM Task Force
  • Support for Classless Internet Addresses in the RIPE database - DRAFT
  • RIPE Database Template for Networks and Persons - DRAFT
  • RIPE NCC Annual Report 1993 - Personnel Paper advertising new NCC position

2. Minutes of the last meeting

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

3. Review of the action list of the last meeting

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

Action: 15.10 Daniel Karrenberg
To propose new tags "created" and "assigned" to the database working group for consideration - pending.

Action: 16.6 Daniel Karrenberg
Why return unused IP address space and be a good network citizen. Daniel to find volunteer to continue the work.

Action: 16.18 NCC
Try to actually get the synchronisation of the various database going, using the recently agreed DB Exchange Format. Action is dependant on the NIC handle - pending.

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.

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.

Action: 17.15 NCC
Propose and implement a mechanism to properly keep track of individual updates of objects and automatic merge/modification operations.

Action: 17.17 Bernhard Stockman
Draft a new version of the EEPG Terms of Reference and distribute this on the mailing list ASAP.

Action: 17.18 Bernhard Stockman
Draft a new version of the EEPG Workplan and distribute this on the EEPG mailing list ASAP.

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

Action: 17.25 NCC, Juliana Tamorri
To make FAQ on CIDR by Juliana available in the RIPE document store.

4. RIPE NCC Report

Daniel Karrenberg presented the NCC Report. The report focused on the personnel shortage at the RIPE NCC. 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. Whilst the growth rate over the last two years for all the statistics presented had increased - indicating therefore a much higher workload for the RIPE NCC staff - there had been no increase in the NCC Core Staffing level at all since the inception of the RIPE NCC. This clearly illustrated the need for more staff to work on the "Core" activities at the RIPE NCC. One such administrative position has been approved and the job announcement was distributed as a paper at the meeting. One further technical engineer position is sought for the Autumn, but this position has not yet formally been approved. Copies of the presentation slides can be found in the RIPE document store in the presentations directory, file:

  • ftp.ripe.net/ripe/presentations/ripe-m18-dfk-NCC-REPORT.ps

5. Joint Projects - Status and Progress

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

  • many of the PRIDE tools have been improved
  • a draft PRIDE guide has been written
  • the PRIDE course has been announced to take place end of May (and is fully booked).
  • ripe-81 extended the Routing Registry at MERIT.
  • In general, the PRIDE project is behind schedule because of CIDR.
  • Much of the PRIDE effort has been on ripe-81++

The plans for PRIDE in the coming months are to:

  • announce more courses o release the PRIDE guide  adapt the tools to ripe-81++ specifications
  • develop more tools (prconfig)
  • extend the project for 2 month period (budget neutral)
  • propose a follow on (simulation, more tools)

Copies of this presentation can be found in the RIPE document store, file:

  • ftp.ripe.net/ripe/presentations/ripe-m18-dfk-PRIDE.ps

6. The MERIT Routing Registry

Elise Gerich introduced the background to the NSFnet Backbone Policy Routing Database (PRDB). The PRDB was devised to stabilise routing for the NSF regionals and has been in place for 6 years. There are some 93 routers and 72 ASes peered with. However the end of the NSFnet backbone is scheduled for November 94 (1st transition phase) and April 95 (a second transition phase). The new NSFnet program incorporates:

  1. VBNS (Very High Speed Backbone). The proposed awardee of this backbone is MCI but the award has been contested by SPRINT.
  2. NAPs (Network Access Points). The proposed awardees are AMERITECH (Chicago); MFS Datanet (Washington DC); Pacific Bell (San Francisco); SPRINT (NYC). The NAPS will no longer maintain an acceptable use policy.
  3. RA (Routing Arbiter). The proposed awardee is ISI (California) and MERIT.

Responsibilities of the RA:

maintain the route servers at NAP o provide a routing registry service o routing engineering (Merit Routing Registry). ISI are developing the route server.

Transition plans:

  • PRDB -> Merit Routing Registry
  • 93 Routers -> It is not known yet who the VBNS will be managed by
  • 72 ASes -> NSP's at NAPs (will be fewer)

The transition started on May 1st, 1994 and is scheduled to be completed by April 1995.

What is the MERIT Routing Registry?

  • Ported RIPE DB software
  • Added support for aggregates
  • Added support for network lists
  • Proposed new optional attributes
  • Collaboration with RIPE NCC on design of Distributed Registry Architecture
  • New attributes added.

Status of the MERIT Routing Registry

  • MERIT Routing Registry has 4 ASes registered: AS690, AS233, AS237 and AS1133.
  • Routing Policy Server (ALC) beta version is available.
  • New tools:
    • astrace - next generation prtraceroute beta v. available
    • aggrwalk - lists aggregates
    • netlist - generation of network lists in alpha text.

If you would like more information, rrdb.merit.edu/meritrr

There was one question from Tony Bates questioning the planned scope of the routing arbiter. The answer was that it would not be limited by the NSF funding body, therefore any network could be registered.

7. RIPE: Restructuring the Organisation

Rob Blokzijl introduced the BOF on "RIPE Restructuring" that would be held on the last day of the meeting. Prior to the meeting, a mailing list was set up and announced (apologies for the lateness of this) and several RIPE participants had already contributed to the discussions. The BOF held at this meeting progressed the discussions already held. A report of the discussions that took place at the BOF can be found under item 10. "Reports from the Working Groups". A draft document is scheduled for the next RIPE meeting, and a final document by the January 1995 meeting. Everyone is encouraged to particpate in the discussions. To do so you need to subscribe to the mailing list.

8. RIPE NCC - Finance and Management

Rob Blokzijl described the current arrangement for the funding of the RIPE NCC and introduced an arrangement for the funding of the RIPE NCC of the future as proposed by RARE. The current situation is that RARE members contribute a major part of the income of the RIPE NCC. Further income is contributed by the service providers. The "underwriting" of the NCC operations has been undertaken by RARE since the beginning of the RIPE NCC. This arrangement has worked successfully and will continue in the future. Tomaz Kalin assured the audience that the RARE Executive would recommend this and that it would be agreed at the RARE CoA meeting on Friday 18th May. However, the RARE Executive has also proposed that a more diirect management of the RIPE NCC by RARE will be necessary if RARE is to underwrite the naturally increasing financial risks of the RIPE NCC budget. Kees Neggers commented that it is not just a RARE issue, but there is a need for financial planning and "professionalism" which RARE feels qualified to undertake on behalf of the RIPE NCC. The RIPE NCC is a recognised valued service and a world leader. The financial control needs improving and restructuring to be consistent with this.

It was observed that if this proposed arrangement was not felt to be satisfactory, then the underwriting of the RIPE NCC needs to be supported by more than one organisation or more money needs to come from service providers. Stephan Biesbroeck commented that it should be more attrac- tive for non-members to contribute more money to the RIPE NCC budget.

9. Report - RARE ATM Working Group

The RARE ATM Task Force has been set up by RARE WG-LLT in the middle of 1993. At this moment, most European countries are taking part in this Task Force, which is, in turn, stimulating the international usage of ATM. This by means of:

  • trying to use the European PNO ATM pilot (an ATM test network installed by some 18 PNO's in Europe);
  • sharing experience on hard- and software;
  • coordinating international ATM networking;
  • coordinating international applications over ATM and
  • providing recommendations on ATM- and higher layers.

The applications this Task Force is coordinating at this moment are:

  • LAN/WAN interconnection
  • Desktop video and audio Conference room video-conferencing

In future, Cooperative Working, ATM-multicast, Quality of Service and Network Management will be covered.

One of the applications (LAN/WAN interconnection) is important in the area of IP. The Task Force would like to coordinate the work on IP over ATM in such a way that the operational IP services are not endangered. Already a few countries have shown their interest: CH, ES, FI, NL, NO and UK. Other organizations that are interested in taking part, should contact the chairman of the Task Force: Les Clyne. Important documents on IP over ATM are: RFC1483, RFC1577, RFC1293 and the Internet Draft on MTU sizes. Routing will be covered by the IETF working group "Routing over Large Clouds". The IETF distribution list on the IP over ATM subject is: [email protected]. The sheets of the presentation can be retrieved from the ftp-server of RIPE:

  • ftp.ripe.net/ripe/presentations/ripe-m18-reijs-atm.ps.Z

10. Reports from the Working Groups

10.1. Local-ir Working Group (D Karrenberg)

Chair: Daniel Karrenberg
Scribe: Mike Norris

10.1.1. Opening

The agenda as circulated beforehand was agreed. The minutes of the meeting held during RIPE-17 in January 1994 were agreed.

10.1.2. Election of New Chairman

Daniel Karrenberg explained why he had announced his resignation as chairman. The efficacy of the WG might be questioned given that the manager of the NCC presided over a group drawn from the membership of RIPE, which set the agenda of the NCC. In addition, the workload of the NCC was now so onerous that all other activities had to be reviewed. Following discussion, the meeting unanimously expressed its complete satisfaction in the chairmanship by Daniel of the Local IR Working Group. The Group had found the close linkage with the NCC to be of great benefit, and that this had never impeded its work nor imposed any limitations on its freedom of action. The meeting reluctantly accepted the resignation of the chairman. Mike Norris agreed to act as chairman, with effect from the end of the meeting.

10.1.3. European Registry Report by the NCC

Daniel Karrenberg reported that, from experience, it may be that enterprise networks, such as those belonging to large multi- or trans-national organisations, needed their own IP registries. As a rule, such organisations did not get delegated address space. However, coordination between local and regional registries was important.

10.1.4. Reports of Significant Events at Local Registries

Question: In light of renumbering caused by CIDR, what should be done with returned addresses? It was agreed that such addresses could be returned, and welcome, to any European IR. Such IRs would return addresses to the NCC. If the addresses could be aggregated, they would be re-used, otherwise they would be returned to IANA.

Question: Will someone write a paper on why it is a good idea to return unused addresses? Some discussion took place, but there were no takers. It was agreed that incidents of note should be reported to the list and to the NCC, and not reported only at WG meetings. Incidents were reported of applications being rejected in Europe but accepted on re-application to other regional registries. The group expressed concern at the disparity in the criteria applied by RIPE and InterNIC registries.

Action: 18.1 Daniel Karrenberg
Convey RIPE's concern at the disparity in criteria with respect to IP network number applications to the InterNIC.

10.1.5. Standard IP Application Form

There was a discussion of multiple applications to different registries by the same organisation, or by different components of the same organisation. It was agreed that the standard form should be revised to guard against such abuses. The following changes should be made:

  • Indicate that any statements made in the form could be used in consideration of future applications
  • Applicants should indicate their parent organisation and its assigned address space, if any
  • Applicants to state whether they had made any applications for IP addresses in Europe or elsewhere and also to indicate whether they had requests turned down in the past.

Action: 18.2 NCC
Draft new standard European Internet Network Number Application Form (formerly ripe-107) in light of recommendations from the working group.

10.1.6. Default Range of AS Numbers

D Karrenberg had asked IANA for a default range of AS numbers, but this had been refused. The previous request to take advantage of reserved networks and AS numbers had been partly honoured by the recently published RFC 1597 which allows 10.0.0.0/24, 172.16.0.0/20 192.168.0.0/16 to be used by networks that, by design, do not want to be connected to the Internet.

John Postel of IANA had rejected the request by RIPE that AS numbers 65530 through 65535 be reserved for similar uses (e.g. a corporate unconnected network consisting of many ASs), as when an AS number is required but not used (as in EGP, see overuse by RENATER with over 400 ASs allocated though never used). The reasons for refusal were:

  • the resource is not close to exhaustion (about 3000 ASs being currently allocated out of a total of 65535);
  • a robust argument was still required.

On the latter point, Daniel asked the audience for volunteers to write this up as a paper (he would give assistance with the writing. No volunteers came forward.

10.1.7. Report from Local IR Workshop

The workshop held before the start of RIPE-18 was well attended, the numbers exceeding those who had booked and the number of lunch equivalents.

RFC 1597, concerning the allocation of private IP addresses, was noted.

The use of the RIPE NCC developed stt tool was presented and anyone interested in using this tool locally was encouraged as welcome to do so. The presentation can be retrieved from the RIPE document store:

  • ftp.ripe.net/ripe/presentations/ripe-m18-dfk-stt.ps

Common errors with the administration of reverse DNS zones were summarised. Geert Jan de Groot gave a short presentation explaining some of these errors. A copy of his presentation can be retrieved from

  • ftp.ripe.net/ripe/presentations/ripe-m18-geertjan-COMM-INADDRARPA-PROB.ps.Z

Action: 18.3 NCC
Investigate monthly publication of error files on reverse zone files, similar to the host count error files.

10.1.8. Funding of and Charging for Local Registry Service

The meeting agreed that these were important issues and that the group should make recommendations as soon as possible.

Action: 18.4 Mike Norris
Initiate discussion w.r.t the funding and charging for the service of a Local IR on the Local-IR discussion list and aim to summarise the discussions by way of a draft recommendation.

10.1.9. Assignment Statistics

W Woeber and Willi Huber had suggested means of representing address space assignment status. This would be discussed on the list.

10.2. Database working group

Chair: Wilfried Woeber

Due to the importance and the length of discussions regarding the ripe-81++ proposal, the DB-WG had to meet once again in parallel with the routing group. Attendance was *very* small this time and the group did not feel to represent quorum. Thus no formal decisions of greater relevance were taken this time. The items treated worth noting for the minutes are as follows:

10.2.1. the "class-less database"

The NCC is going to implement the classless indexing stuff for the database software. This is first priority and is not directly affected by any decisions about external representations of address ranges.

10.2.2. Removal of retired attributes

These attributes are scheduled to disappear when the changes are implemented that split the current network object into the "new" inetnum: and the "route:" object. The functions currently provided by "connect: LOCAL" can be provided by "comm-list:" and "component:" attributes.

10.2.3. Review of the expected guardian procedure for the "route:" object

When discussing the guardian procedure for the "route:" object there was some concern that the registering of route objects could become out of synch with the up-load of the guardian files. One of the possible solutions proposed would cause registrations to become re-queued for evaluation after the next scheduled guardian update. This is for further study and discussion.

10.2.4. National characters in database objects

There was a common feeling that - given what we aim for with the database - the use of national special characters in database objects is not useful. It is thus strongly discouraged. However, objects currently registered will be kept and this recommendation shall not be enforced.

10.2.5. Shortage of personnel resources at the NCC

Again there was concern that many necessary activities cannot be pursued due to the shortage of personnel at the NCC (e.g. RIPE-Handles, RWhois,etc.). A.B.Bonito proposed to get external help for the NCC to work on well-defined short-term projects. It is expected that this help could and should be provided by staff from the individual NICs.

10.3. Connectivity

Chair: Milan Sterba
Scribe: Elise Gerich

10.3.1. Central and Eastern Europe - CEENet initiative

Wilfried Woeber presented an introduction to the CEEnet Initiative. This is an effort to plan for network infrastructure for the Eastern European countries with government endorsement. Two organizations are involved in planning this infrastructure: Europanet and EBONE. Wilfried indicated that a map detailing the proposed structure is available on the ACOnet file server.

10.3.2. Russia and former Soviet Union

Ilya Mafter presented a summary of ISF's activities in Russia and the Ukraine. He indicated that ISF (International Science Foundation) is a $100 million foundation of which $5 million is decided to improving the network infrastructure in the Former Soviet Union to support basic research scientists. The projects that ISF is currently working on are:

  • Moscow - fiber backbone project; no target time for delivery as of yet
  • Kiev - local backbone and connectivity to Moscow
  • Novosibirsk - project is under development; external satellite links

A new "megaproject" has been initiated which aims at a much larger user community (education, culture, religious communities etc.) promoting the creation of a new communication infrastructure for the "open society" at large. Alexey Platonov (RosNIIROS/RELARN director) drew a map of the proposed fiber backbone in Moscow and indicated that the project is now one year old. The status of the backbone project is:

  • fiber is in place between M9 and IKI
  • fiber is in place between KIAE and IASnet
  • termination equipment is still needed
  • Russian fiber has been used and there is a need to test single mode FDDI cards
  • a management plan is still under discussion

Platonov stated that the Moscow backbone would establish a MIX (Moscow Internet Exchange) for network service providers and that there is already connectivity between the MIX and St. Petersburg at 2Mb. The connectivity between Moscow and St. Petersburg is operated by Relcom.

Dimitry Burkov (Relcom R&D director) elaborated on the drawing of Platonov. He described a T1 microwave between KIAE and M9; E1 fiber between KIAE and DEMOS; 64K between DEMOS and Ostankino Tower; and a 64K satellite link to New York. The 64K to New York is in the process of being upgraded to 256K. In addition, from M9, there is an E1 microwave to St. Petersburg (not sure about where the E1 terminates), and then 256K terrestrial link to Helsinki (FUnet-EUnet). This provides Relcom in partnership with DEMOS connectivity to Europe and the United States.

Currently Relcom and Demos are in partnership on a new project to provide Japan, Russia, US connectivity. In addition, there is a 64K link between KIAE and ROSSprint with an agreement for mutual backup between Relcom and Sprint.

Dmitry Avdeyev (Moscow State University/DESY) presented the Radio-MSU activity which is based on microwave and terrestrial connectivity within Moscow and a satellite link to DESY, Hamburg, Germany. There is a 3.5m dish in Hamburg and a 4.8m dish in Moscow (Russian equipment) and DESY has a license to operate Russian satellite equipment in Germany. They are in the process of upgrading to a bigger dish in Germany, and plan to the upgrade the satellite capacity from 256k to 512K in September '94. Then in summer of 1995 the plan is to upgrade to 1M. Dimitry agreed to provide postscript versions of his slides.

Sam L. Musher (Novosibirsk - Academgorodok Internet Project) presented a picture of a star topology within Academgorodok with the centre of the star at COMCEN. From COMCEN there is high speed connectivity to INP, IAE, NSU, and Chemistry. The project proposes to install a 256K satel- lite link to Finland from INP. Currently the only connectivity from Academgorodok to Moscow is:

  • 4 leased lines at 14.4 to M9
  • an ISKRA line to ITEP
  • a 19.2 line to SOVAM teleport running IP over X.25

The current access to the Internet is too slow to permit interactive connections. E-mail is the extent of their connectivity.

The Academgorodok Internet Project plans two external connections: one to Radio-MSU and the MIX, and the second to the Northern Part of Finland (with connectivity to FUNET and KTH). Academgorodok hopes to fund this project with contributions from ISF, DOE and the Russian Academy of Science.

Misha Popov (Dubna) announced for the fourth year a 56k line from Dubna to GARR (Italy - Gran Sasso). (During the meeting itself and recently there have been connectivity problems - but the situation is now improved: all (98%) traffic is vai the GARR gateweay: ~2% at low speed link to Relcom; ~0% at Dubna-Potsdam 64K link.

10.3.3. Albania

Milan Sterba made a short report on activity to Albania. Greece (FORTH) works on email connectivity to Institute of Informatics, Tirana. In CNUCE - Italy there is an activity to set up an IP link to Tirana University.

10.3.4. RIPE Connectivity Document Store

Milan Sterba reported on the status of the RIPE CDS (Connectivity Document Store) which is now used as the main RIPE vehicle to publish information about connected networks in Europe. Because publishing information in the CDS means utilisation of RIPE NCC resources the CDS apply the policy of only publishing information about networks which contribute to the RIPE NCC budget. It has been stated that all known Eastern and Central European networks fill this criterion.

Eleven networks have answered the call for CDS fact-sheets up to now:

  • DANTE - Europanet
  • Unicom - B
  • Belnet
  • CESnet
  • SANET
  • HEAnet
  • NASK
  • EUnet (BG,CZ,FR,SK)

All others are encouraged to submit Fact Sheets for inclusion in the CDS. The CDS is currently accessible over WWW, gopher, ftp and e-mail. (for further information see http://www.ripe.net/ripe/cds.html).

The CDS fact-sheet layout described in: ftp.ripe.net/ripe/drafts/connectivity-report-plan.txt will be promoted to a regular ripe document.

Action Items

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

Action: 18.6 NCC
Set-up a mailing list for the connectivity WG.

10.4. Routing

Chair: Jean-Michel Jouanigot
Scribe: Gilles Farrache

10.4.1. Previous minutes, agenda

The previous minutes were approved. Gilles Farrache (volunteered?) as a scribe.

10.4.2. CIDR deployment status

CIDR development is progressing well. All the organizations that participated in this effort should be thanked and the networks that did not yet convert to CIDR should do it as soon as possible.

Tony Bates presented a few graphs on the evolution of the number of routes and paths in the Internet. The slides (and other useful data) are available from

  • ftp.ripe.net/cidr

Computations are made on an AS basis to estimate the routing table reduction if these ASes convert to CIDR. Everyone was encouraged to study these data.

We can observe a quite significant decrease of the number of routes (20400 down to 18400) and paths (53000 down to 50000), but this is probably not going to last very long.

Regular messages are sent by the Ripe NCC and list the first 10 Autonomous systems Internet wide that would really save a significant amount of routes if they convert to CIDR. If your AS is listed in there, you should definitely do something!

With the recent development of CIDR in the Internet, the current model for policy based routing has to be reviewed, since aggregates are not taken into account. Two proposals have been made: one from Tony Bates, Marten Terpstra and Daniel Karrenberg (RIPE NCC) and another one from Laurent Joncheray and Elise Gerich (Merit). Both proposals were presented first (see below), and then a general discussion took place with the aim to come to a general proposal to be used by both the RIPE and Merit RRs.

10.4.3. Ripe-81++ and related documents

Marten Terpstra presented a proposal for representing classless addresses in the database. For more details, please read the draft document 'ripe-clarep' available from ftp.ripe.net.

Examples:

  • classful address: 193.48.80.0
  • classful range: 193.48.80.0 - 193.48.85.0
  • prefix/length: 193.48.80.0/24 193.48.80.0/20
  • classless range: 191.1.1.0 > 192.1.1.255
    • Does not need to be aligned on a bit boundary.

Tony Bates then presented the enhanced version of Ripe-81 called Ripe-81++. This proposal introduces new concepts:

  • the allocation registry and the routing registry are now separate. The current 'inetnum' object is split into two new objects: a new obsolete information have been removed.
  • in the route object, the aut-sys tag is replaced by an 'origin' tag which indicates the AS number which injects this route in the Internet. The route is obviously classless, with a prefix/length representation.
  • There is no major modification on the routing policy description except that AS-MACROS and COMMUNITIES can now be used, and an

Transition issues:

  • The database software should be modified (classless indexing) and the various tools should understand both the old and the new structure.
  • The new objects should be supported by the end of the summer, and all the routing information moved to the new 'route' object by the end of fall.

Open issues:

The PRIDE tools have to be modified, and the exchange of routing information with other routing databases should be possible.

For more information, please read ripe-81++, available from:

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

10.4.4. Extensions proposed by Merit

Laurent Joncheray presented the work currently being done at Merit. The RIPE database software was used and modified to support classless addresses, but:

  • It should be possible to distribute the database (by design)
  • New extensions are needed to implement all the policies.

ALC is a new routing server developed by Merit. It makes the tools database syntax independent (ASCII protocol between client and server, the server computes the answers), and allows several ALC servers to exchange information.

An ALC server is already running at Merit, and gets information from three databases (Ripe, Prdb and NSFnet db). It is proposed to run such a server at the Ripe NCC and connect the two servers; a natural extension would then be to add more ALC servers to the system.

The current Ripe-81 syntax has been extended:

  • keywords have been added (from, accept,...) to make the policy descriptions more readable
  • list of networks are allowed
  • proposes a solution to represent serveral connections between two ASes (using router addresses)
  • possibility to use a database selector
  • optional metric in as-out
  • static routing support
  • as-default extension (default route generation)
  • new 'as-exclude' tag
  • new 'as-transit' tag

Some questions were raised concerning the distribution of the database and how some sort of security can be implemented. This point is for further study.

10.4.5. Discussions, conclusions

A long discussion took place to compare the two proposals and try to merge them. These minutes do not reflect each and every point discussed, but will report on the conclusions reached. The Reader is asked to consult Ripe-81++ and Merit's proposal for details.

Ripe-81++ will integrate the following extensions:

A. Network lists are accepted wherever a community can be used with the following syntax:

  • {36.0.0.0/8, 191.1.0.0/16}

B. The 'default' tag will now allow an optional field explaining how the default route is derived. The Merit 'as-default' tag extension is accepted, but will be called 'default'.

C. The need for a way to express 'local' policies when two ASes are con- nected through several links is agreed. There's still no agreement on the final syntax, except that this information should not be in the to the as-in and as-out attributes which describe the overal policy of the AS while they describe local policy between the AS and (some of) its direct neighbours. If the 'interas-in' or 'interas-out' tags are present, then there should be a mechanism to generate the corresponding information) to guarantee the integrity of the 'route' object. This should be done (on request, using a special keyword) by the software when registering the object.

D. The Merit syntax introduces keywords like accept, from,... It is agreed that this should be accepted when registering the objects, and that these keywords should be present when a query is performed "in verbose mode". Queries in "non verbose mode" is still possible. All keywords are in lower-class and a list of allowed keywords will be provided.

Action: 18.7 Elise Gerich
To supply a list of keywords allowed that can be used when querying the database.

E. The Merit syntax also proposes a way to "compress" the information like:

  • as-in: from AS690:1, AS701:2 accept AS237

This new syntax is not accepted because there was consensus that the additional functionality does not warrant the extra complexity in the descriptions. Many of those present expressed that they prefer a uniform description because it makes reading other people's policies easier.

F. Network numbers representation: It is agreed that the prefix/length syntax is the only representation accepted. Network numbers should contain 3 dots: 35.0.0.0/8

G. The classless range notation for the 'inetnum' object is not to be discussed in this group but in the database group. The 'route' object only accepts what is agreed on point F.

H. Optional as-out metric: this information has to be evaluated in the same way by the various neighbours, and is the only information of the proposal is rejected.

I. Static route support: Everybody agreed on the principle: static routing should be represented in the database. A metric should be associated with a static route, and this metric should be relative to the 'as-in' metric.

J. Ripe-81++ component tag in the route object: This tag is optional, and a better definition of the 'component' tag is needed, as well as a review of the definition of a 'HOLE'. In case of proxy-aggregate, Ripe-81++ should indicate that the listing of the components is mandatory. In case an aggregate is performed with as-set, and that all the networks aggregated are announced by the same AS, then this AS should appear as origin in the 'route' object. There's still a pending issue concerning the community list usage in the component tag: this needs to be better defined and how will this be guarded?

K. The key in the Ripe database used to be the network number. It will become 'route/origin'. Several route objects with the same 'route' fields but different 'origin' fields are accepted.

L. Even though host routes could perfectly be represented in the new database, it is strongly discouraged (ripe-81++ page 56).

M. Line splitting: the notation is accepted

  • as-in: AS1234 100 (AS-EBONE o as-in: AS1234 100 AS1234) AND NOT AS2345

N. as-reject and as-exclude: It is decided to rename as-reject in ripe-81++ into as-exclude (proposed from Merit). The keyword 'exclude' will be a reserve keyword.

O. 'as-transit' is included in Ripe-81++, but for experimental purposes. It was agreed that experimental additions should be moved a separate document which summarizes all experimental attributes and a pointer to this mechanism should be put into ripe-81++. The additions document should comprise all experimental additions being used a the time.

P. The database selector (Merit's proposal) needs to be better specified. In conclusions, there was a general consensus on most of the extensions and it is proposed to include all of these in the new version of the Ripe-81++ draft. This draft will be sent to the RIPE list for comments within two weeks, a final version being released in six weeks (June 28th).

Action: 18.8 NCC
Fold in comments from routing-wg to the ripe-81++ draft, send to the RIPE list and release final verison - June 28th, 1994.

10.4.6. Closing, AOB

The action on Jean-Michel Jouanigot to coordinate the migration from ripe-60 to ripe-81 is almost complete. Only three 'bdry-gw' are still present in the RIPE database: DESY, ACONET and INFN. The action is to be changed into 3 separate actions on these sites:

Action: 18.9 Christina Vistoli, Ewald Jenisch and and Michael Ernst (or Hans Frese)
To convert from ripe-60 to ripe-81 before July 1st, 1994.

[At the time of writing, ACONET bdry-gw seems to have been removed]

10.5. DNS Working Group

Chair: Francis Dupont
Scribe: Andreas Knocke

10.5.1. Opening

An agenda circulated beforehand was agreed. The minutes of the meeting held during RIPE-17 in January 1994 were agreed upon.

10.5.2. Workplan and Charter of the Group

The question of folding down this working group was discussed. It was stated by R Volk that the wide usage of the BIND implementations in Europe and the global development plans for new versions of BIND no longer require a standing working group. For these reasons (no technical development) the IETF DNS working group was finished at the last IEFT meeting. The working group is still useful for help and/or pressure then it should be kept but that a meeting will be held at the next RIPE meeting only if an agenda requires.

10.5.3. BIND status

The current status given by F Dupont [as quoted from his email to the dns-wg] was:

  • the last experimental release is BIND 4.9.3 alpha4 (join the mailing list [email protected] if you want to use/debug it). [there is a new op-guide, if interested you should read it]
  • the last official release is BIND 4.9.2 and final distribution can be found in gatekeeper.dec.com:[~ftp/]pub/misc/vixie/4.9.2-940221.tar.{Z,gz} and on several anonymous FTP servers.
  • known problems are negative caching and validating then switch OFF the options NCACHE and VALIDATE. Another problem is resolver library security with SunOS, use the SUNSECURITY switch. SIPP support has been done by Susan Thomson and can be found in: thumper.bellcore.com:[~ftp/]pub/pip/code/dns/feb94.tar.Z
  • NSAP support has been done by Paul Traina and can be found in ftp.cisco.com:[~ftp/]bind/4.9.2-beta5-nsap-diffs
    NSAP support for nslookup (i.e. easy way to find PTR for NSAP addresses) has been done by Richard Colella and is in osi.ncsl.nist.gov:[~ftp/]pub/ncsa_tuba/nslook_rev_nsap.tar (note: the reverse map root is nsap.int)

10.5.4. DNS security

This is done by an IETF WG, with RSA digital signatures as a possibility which has to be implemented in an exportable fashion to make it available outside the United States of America.

10.5.5. Review of the Domain object

Some attributes (zone-c, nserver, sub-dom) of the domain object were mandatory but had no meaning for some domains (for instance a MX only domain is not a zone then has no zone contact). So the domain object should be updated (or removed), definitions and status (mandatory or optional) of attibutes should be refined.

The registration of domains for different top level domains (TLDs) vary a lot in range and it was asked if the domain should be kept in the RIPE database or whether it would be better if this information was stored in the DNS (TXT RRs for the attributes). The need for high availability of addresses and phone numbers in case of misconfiguration makes it desirable to have it in the RIPE data base for all the subdomains of the national structure, i.e. first level subdomains for flat TLDs and the subdomains of co, ac,.. for TLDs following this model. The necessary information for these domains as seen by the Registrar for the domains SHOULD be mirrored in the RIPE data base.

Some changes to the domain object were discussed:

  • Putting the zone-c as another tech-c, she/he can be identified from the SOA-RR, don't make zone-c a mandatory attribute
  • make nserver optional, eventually marking it as obsolete for future releases of the domain object because this is already stored in the DNS tree in a probably more up to date fashion
  • this means rev-srv for the in-addr.arpa domain entries shall be regarded the same way, make it optional - it maybe obsoleted in due course.
  • sub-dom should also only be optional

Action: 18.10 Francis Dupont
Circulate a proposed new domain object with the list of attributes necessary, marking others optional, maybe obsolete them in the future. Update to RIPE-049.

10.5.6. Discussion about the document of A Romao

The document "Taking Care of your Domain" was welcomed by the participants and it was agreed to put it in the RIPE document store and to propose it as an informational RFC. The participants want to thank him for his work and ask for further input from 'old hands'.

Action: 18.11 NCC
Put A. Romao's paper "Taking Care of your Domain" into the RIPE document store as a RIPE document.

10.6. MBONE Working Group

Chair: Erik-Jan Bos
Scribe: Michael Behringer

Mailing lists:

10.6.1. Agenda

The agenda was presented, and agreed by the participants.

10.6.2. Workplan

Currently there is no WG for Mbone under the auspices of RIPE. EJB proposed that such a WG should be set up, which was agreed generally. Next step then is that there is a Terms of Reference and a Workplan to be agreed. EJB wants to set them up, as well as a Euro-FAQ, and will send them to the list, for discussion. At the next RIPE meeting these documents should be agreed then.

Action: 18.12 Erik-Jan Bos
Set up Workplan, Terms of Reference and Euro-FAQ, to be send to the mailing list. Tony Bates said he could help EJB on the FAQ.

10.6.3. Mbone in Europe Status

There are two PS'es available that show the European Mbone topology:

- ftp.nic.surfnet.nl:ftp/surfnet/net-management/mbone/mbone-eu.ps (EJB picture)
- aun.uninett.no:pub/misc/ipmulti/mbone-eu.ps (picture from Havard)

These pictures represent the current Mbone situation in Europe. Maintenance has to be done permanently, as the topology probably will face frequent changes. This is an ongoing action on the authors of the pictures. There is also a worldwide PS picture on Mbone tunnels available, which gives on overview about the worldwide situation. EJB asked Havard to maintain his picture as *the* Mbone picture for Europe.

Action: 18.13 Erik-Jan Bos
Send to the mailing list query on where to find the worldwide PS file (done through these minutes).

10.6.4. Short Term Work items

10.6.4.1. Email lists

In some countries there are local fan-out lists are available. There should be a list for each country, so that local matters are not to be discussed on international lists.

Action: 18.14 All members of the Mbone WG
See if there is a local Mbone mailing list in your country, if not, create one and add this list to the European list, so that European information is passed on.

10.6.4.2. Central FTP server

There is a central FTP server needed, containing not only the picture of the Mbone topology in Europe, but also the latest versions of the software.

Action: 18.15 Erik-Jan Bos
Start up a central European Mbone FTP server.

10.6.4.3. Discussion on the topological structure

Currently there are Mbone tunnels on the CERN T1, Stockholm line, Paris line. There is no feed on the Amsterdam E1. Havard mentioned the overload of the Paris E1. He would also consider it a matter of fairness to Ebone, which was supplying most parts of Europe with Mbone so far, for DANTE providing this feed now on the Amsterdam E1.

Michael Behringer stated on behalf of DANTE that there is no concern about having a Mbone feed on the Amsterdam E1 as part of the accounted traffic of a regional network like e.g. SURFnet. But supplying a feed as a part of the general service would involve additional overhead costs, so that this kind of agreement has to be considered carefully, it is however open for suggestions.

EJB could provide some statistical figures on that. In march 94 the Amsterdam Mbone server sent 32 Gbyte per tunnel, which makes 100 kbit/s on average in a month. But if there is a Mbone connection running, it uses 512 kbit/s permanently.

At the moment some participants have quite high costs for bandwidth consumption, that are not shared at all. Given that Mbone traffic is likely to rise in the near future, this problem should be addressed soon, as long as it is not a problem.

The group did neither come to a conclusion on a possible funding model for Mbone, nor if the financial problem should be discussed at all in this WG. The comment was made that users are seeing Mbone as a service already, and are complaining if this service fails. On that the question was raised if people should consider Mbone as experimental, or if it has come to a production state already. There was general agreement that users should be aware that due to non-technical issues the Mbone topology might change quite rapidly. But the question if Mbone can be considered a production service could not be answered clearly. Kevin Hoadley stated on behalf of Janet that a Mbone feed is seen as part of the service there.

10.6.4.4. INET setup (presentation by John Martin)

Current tunnels available to Prague: NMS.CESNET.CZ (NMS.CVUT.CS) Mrouter on Czech Technical University Prague

Planned for the conference is 1 video, 1 audio stream, appr. 10 hours on June 14-17th.

INET line setup: 2 Mbit MCI line via London to Washington. 512k line to EMPB. Tunnels proposed for INET:

The proposal was made to route the EMPB tunnel not via Amsterdam, but directly to London Tests for this setup are due 7-13th June. John also presented some pictures on the physical setup of the Prague configuration. These can be obtained via him.

10.6.4.5. Local setups

Regionals are encouraged to store maps of their local Mbone setups. Kevin Hoadley volunteered to present the JANET setup during the next RIPE meeting.

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

10.7. RIPE Restructuring BOF Report

Rob Blokzijl chaired the BOF session. On the recently announced mailing list there had been some contributions to the topic. Willem van de Scheun briefly presented his ideas as sent to the list. This together with the RIPE Terms of Reference document (ripe-001) was the starting point for the discussion.

Some discussion took place over the "openness of RIPE" and the overly academic focus of the organisations represented. Glenn Kowack suggested there was a need for more aggressive publicity to attract more service providers and operators to RIPE (especially new and existing commercial providers who are currently under-represented). Reference was made a UK "DGix co-ordination meeting" that was planned to attract just the people that RIPE is lacking. It was suggested by Glenn Kowack that RIPE as an organisation needs to adapt to the changing infrastructure of the Global Internet.

There was a further suggestion that the "non-formal" structure of RIPE as it currently stands is a deterrent for some organisations to become involved. It was suggested that RIPE needed to take action to become a legal entity.

In conclusion the BOF session agreed on the following actions:

Action: 18.17 RIPE Chairs
Promote a more aggressive "outreach" programme to introduce and encourage new service providers to join RIPE.

Action: 18.18 RIPE Chairs
Continue the RIPE restructuring discussions on the mailing list focusing on restructuring the technical work of RIPE.

Action: 18.19 RIPE Chairs
Develop a draft model for "new-RIPE" by the next RIPE meeting in September, with the final report ready by January meeting in 1995.

11. 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 Portugal for the meeting in September:

  • RIPE 19 September 12-14, 1994 - Lisbon, Portugal
  • RIPE 20 January 25-27, 1995 - Amsterdam, The Netherlands
  • RIPE 21 end April/May 1995. Location to be discussed. Offers have been received by GARR and by Juergen Rauschenbach for Berlin, Germany.
  • RIPE 22 - was not discussed.

12. AOB

There was no business reported under this agenda point.

13. Closing

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