Skip to main content

RIPE 22 Minutes

1. Opening

1.1. Welcome

Rob Blokzijl welcomed the participants to the 20th RIPE meeting hosted by NIKHEF in Amsterdam, The Netherlands.

1.2. Papers tabled

  • Agenda for the 22nd RIPE meeting
  • Working Group Agendas
  • List of Participants of the 22nd RIPE meeting

2. Agenda

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

3. Minutes of the last meeting

The minutes of the 21st RIPE meeting were approved with no changes.

4. Review of the action list of the last meeting

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

Action 19.12 on Marten Terpstra (to be taken over by NCC)
To write up the proposed "stored"/"processed" attribute.

Action 20.5 on Daniel Karrenberg
To draft outline "applications document" to support the proposed plan on how to deal with address space requests from VSE's

Action 20.14 on Milan Sterba
To update the Connectivity Document Store home page

Action 20.22 on Francis Dupont
To send a pointer to PIM for BSD 4.4 as soon as it is available

Action 20.24 on Daniele Bovio
To set up the matrix to keep track of the RIPE meeting actions

Action 21.2 on Daniel Karrenberg
To put billing information in the database.

Action 21.3 on Daniel Karrenberg, Mike Norris
To draft a recommendation on charging by local IRs until September

Action 21.9 on Erik-Jan Bos (Wilfried Woeber)
To update the proposal "A Multicast Router in the Rout ing Registry"

5. RIPE NCC Report on the Contributors' Meeting

To be published later. The report or a pointer to it will be available from

  • ftp://ftp.ripe.net/ripe/presentations/ripe-m22-dfk-CC-MEETING.*

6. RIPE NCC Report

To be published later. The report or a pointer to it will be available from

  • ftp://ftp.ripe.net/ripe/presentations/ripe-m22-dfk-NCC-REPORT.*

7. Dante Services

Dante Services started with a new underlying network on October 7. Michael Behringer gives a presentation of how the migration to the new network and backbone took place. First a short history. During the last three years, Dante has used for its underlying network the European Multiprotocol Backbone (EMPB) managed by Unisource. The contract with Unisource expired in September 30, 1995. Unisource had no intention to renew the contract. In October '94, a call for tender for a new backbone went out. Closing date was December '94. Out of three serious candidates, BT (British Telecom) was finally chosen in March '95, although the decision was narrow. Three arguments motivated the choice:

  1. low price
  2. commitment to channel internet service in Europe
  3. intercontinental arrangements

The contract to BT was awarded in May '95. IBDNS (International Backbone Domain Name Service) is the new backbone managed by BT. Arrangements have been made to connect with Ebone in Switzerland. The backbone consists of IP leased lines. Due to internal politics in BT, there was no US connectivity at the beginning, but this has been settled now. There is a huge demand for US capacity. Two routers have been installed in NY. Sprint link will be cancelled and service will be given by ANS.

Germany has its own direct line via Aachen. The backbone consists of 2Mbps lines.

A time frame of 4 months was set for connecting all EMPB networks to the new backbone. All sites received, on a temporary basis, two lines: one to IBDNS and one to the old backbone. The last network to be migrated was Greece, this was done on Friday, October 4. On Monday, October 7, the EMPB network was switched off.

BT route filtering is based on the RIPE database. This means that if the route is not registered in the RIPE database, there is no route to IBDNS. Another condition is AS-path filtering on each port.

At this point of Michaels talk, Someone in the audience brings up the question of the unreachability of American commercial sites, there where US connectivity has not yet been arranged.

Michael continues his talk: although consistency checks were done before EMPB was finally switched off, problems can still occur. Michael instigates the audience to report any problem to the administrator of the information management database.

Michael finishes his talk by thanking Unisource for three years of commitment and very good service, BT for a lot of hard work to get IBDNS working on time, and the EuropaNET regionals for their support during the migration time.

Questions and remarks from the audience:

R: Antonio-Blasco Bonito mentions that there are still lines missing, such as the one Milano-Stockholm.
A: Michael declares that this line has been delivered by now.

Q: Why has Frame Relay to be avoided?
A: Frame Relay causes a higher delay. Frame Relay is useful when lots of people log in on peak times. With a steady traffic profile, Frame Relay makes no sense.

Q: Is there a technical, economical or other reason why E3 is not used?
A: We cannot get 32 Mbps lines, that is to say, it is too expensive for us. PNO is bound by the regulation that they have to sell for the same price to everyone. This is to prevent competitors to come in and sell international telephony, competing with the services of the PTT themselves.

BT does the managing of routing and IBDNS and the registration of traffic profile.

Q: What is the customer/client relationship between Dante and BT?
A: Reciprocal.

Q: Are you gong to publish statistics on network traffic?
A: Yes, to customers only.

8. Internet Exchanges

In addition to the reports that were held at the EOF meeting, (of which the minutes can be found later on,) there were two reports at the plenary session about Internet Exchange Points that had recently established or would exist soon. Various aspects were presented, like architecture, facilities and the participants joining in the project. First, Paolo Bevilacqua gave a presentation about NapRoma in Italy and next, Peter Lothberg talked about the Internet Exchange at KTH in Stockholm, Sweden.

Postscript files of Paolo's presentation, which give a clear and extensive overview of NapRoma, are available at:

  • ftp://ftp.ripe.net/ripe/presentations/ripe-m22-pab-romanap.ps.gz
  • ftp://ftp.ripe.net/ripe/presentations/ripe-m22-pab-romapres.ps.gz

9. Emerging 34-45 Mb International Services

Peter Lothberg went on with another presentation, explaining how a 34 Mb link from Sprint in the U.S.A. to KTH was installed. Among others, he discussed the problems that occurred, the different parties and people involved and the time schedule and future of the project.

10. Encryption policies on the European Internets

Rob Blokzijl introduced the subject explaining that there is a growing demand for encryption by various private companies and business in general. Service providers are under increasing pressure to provide this service for their customers. Meanwhile governments are trying to make the practice illegal (already done in France). He proposed that all European Service Providers should get together to decide how they will counter this threat as it will undoubtedly affect their businesses adversely. A further argument is the development of the IPv6 which has been designed in order to contain some encryption potential, if it is banned then part of this new IP will be redundant before it is even implemented. Rob concluded his opening remarks by issuing a challenge to the representatives of the SPs in the audience to think of some arguments to prevent encryption from being banned globally.

Qu: Is this not an end user problem?
Ans: End users need a SP so if one SP can't offer the service they want then they will surely go to another! Therefore it becomes the SP's problem again. Resp: If IPv6 is being offered by the SPs then they will be offering the possibility of encryption so this again puts the ball in their court.

Chair: I think that the politicians do not understand the technical issues and they are being very short sighted. They are possibly stopping many potential benefits and developments that will come out of this work. Resp: This comment is not useful as this is too negative. Forget the criminal stuff, try to build an argument based on the benefits of developing encryption. Resp: What about private networks? Ultimately the end user will suffer, we should not argue with the politicians directly but inform the EU of the threat.

In a summary Rob stated, that it seemed best to lobby both the SPs and the EUs. The main arguments of governments seem to be that it will be used by drugs cartels to talk to their suppliers and set up deals!

Resp: I think that all service providers should step forward now and protest before legislation is forced on them. Resp: SPs can also be seen as end users so I think they should get together and lobby hard now. Resp: Politicians should be lobbied with a positive message, they should not just be criticised. Some concessions on law and order may allow some encryption for SPs and EUs.

Another person added that they had seen some documents providing strong arguments in favour of encryption. he proposed that people went away and researched the issue and reported back with any new arguments. The chair asked for a volunteer to get together some arguments in support of encryption, in order to organise a collective response.

Resp: Another delegate warned that governments would not settle for anything less than access to all encryption codes. He proposed that the issue applies equally to all electronic media and that it was the press attention the internet was getting currently that is driving moves against encryption.

Resp: Proposed that RIPE could co-ordinate the efforts, if others would make suggestions and drive the protest.

Chair: Proposed setting up a mailing list for contributions.

Resp: Another comment was that at present there are so many different types of hardware/software in Europe that encryption is hard to standardise. He suggested that maybe there is a place for developing some kind of pan-european co-operative market for encryption hardware.

11. IETF Report

Joyce Reynolds held a long and clear talk about the last IETF meeting held in Danvers. She gave a comprehensive overview of the structure of the IETF and of changes and things happening in a large number of working groups. Joyce published excellent, ASCII text, sheets which probably give the best summary of her talk and can be found at the URL:

  • ftp://ftp.ripe.net/ripe/presentations/ripe-m22-jkrey-IETF.txt

12. Working Groups Reports

The chairs from the various working groups gave reports on the working group meetings that were held earlier. The min- utes made by each working group chair/scribe follow below. At the end of each minutes, questions may be found that were asked by the RIPE22 audience following the reports.

12.1. EOF meeting

Chair: Peter Lothberg (PL)
Scribe: Havard Eidnes (HE)

12.1.1. Welcome

PL welcomed everyone to the meeting.

12.1.2. Agenda bashing

A point on "national EOF-like organizations" was added under AOB.

12.1.3. Appointment of minute taker

HE volunteered to take the minutes.

12.1.4. Apologies

None received.

12.1.5. Previous minutes

The minutes had an unfortunate typo in them, two words were missing ("Republic of" ahead of "South Africa"). The modified minutes will be circulated. With this suggested change the minutes were approved.

12.1.6. Status of European Interconnect Points

(See also table at end of these minutes.)

LINX (London) There has been 2 LINX meetings since the last EOF meeting, and as a result there has been produced a new MOU and new procedures for the operation of the LINX. These documents are available at http://www.linx.net/linx.html. There are currently 13 members at the LINX, including IBM Advantis, Sprint International and Planet Online among the "international service providers". None of the providers have connections to the LINX at lower rates than 256 kbit/s, several of the members have multi-T1 connections there. So far this exchange point has been growing relatively quickly.

Currently the yearly fee for a connection to the LINX is at 5000 GBP, and there is an additional connection fee. This fee gives access to 8U of 19" rack space (approx. enough for a Cisco 7010). To connect to the LINX there is a requirement to have an independent connection to the US with appropriate transit agreements over that path.

The technology used is 2 x Cisco Catalyst connected via ethernet. FDDI is seen as the natural next step, while FDDI switches have so far been deemed too expensive, and the LINX is looking for equipment sponsorship in this area. A possible alternative technology is "fast ethernet".

The LINX is housed at Telehouse, a company specializing in facility management. It was clearly seen as an advantage that the facility was neither under the control of a single PTT and that the facility owners are not actors in the Internet service provider market.

  • F-GIX (Paris) The contact persons for this site did not show up at the meeting due to flight delays, so this item was dropped.
  • D-GIX (Stockholm) Currently has 15 members. There seems to be a new request for a connection each 4th day...

The rules for connecting is "bring your box and your own bandwidth". Technology used: FDDI or Ethernet with Eth- ernet switches). There is currently no housing fee, and the equipment used to implement the D-GIX is funded by the government. 24x7 coverage can be bought (but not from KTH). KTH is looking at housing servers (eg. WWW servers) as well, and will hopefully have a proposal ready before end 1995.

There is an initiative underway to make it possible to hook up to the D-GIX at other places in Stockholm as well, ie. to extend the D-GIX over dark fiber.

WWW access for further information: http://www.sunet.se/dgix/

Cern (Geneva) Denise Heagerty presented the CERN Internet exchange point (CIXP). It currently is an FDDI ring with connections to CERN (local access), EBONE (4Mbit/s), SWITCH (8Mbit/s), HEPnet and in addition an end of a connection to InternetMCI (managed by CERN, for use by other par- ticipants in this US line's consortium), the Geneva MAN (where Telecom'95 is connected over ATM) and the ATM Pilot (ATM connection via routers connected to the ring).

The details of terms and conditions have yet to be finalized, however the following was said: Cost-wise the intention is to cover the real cost (ie. not make a profit). The policy is "bring your box", rack space is available (8U?), there is 24x7 operator coverage and the installation *is* up and running during christmas as well (before 2 years ago this would not have been the case, but that is fixed now).

More information will be available at http://wwwcs.cern.ch/wwwcs/publicip/cixp.html

  • Amsterdam Erik-Jan Bos presented the Amsterdam Internet Exchange (AIE). This exchange point is currently implemented with a "yellow cable ethernet" spanning the buildings at CWI. Access is currently free.
  • upgrade the technology to switched FDDI - provide access at more than one physical location, provide interconnection between the FDDI switches initially at E3 rate (34 Mbit/s).

Ethernet connections will however continue to be available.

Possible locations for the extended AIE: Kruislaan (CWI) Drentestraat (PTT POP) Overschiestraat (BT POP)

The bandwidth to be used between these locations are planned purchased from "cheap sources", there are several options available.

Target date for installation of upgrade is Q1 1996. For more information see http://www.nic.surfnet.nl/surfnet/persons/bos/aie.html

The price for connections to the new exchange have not yet been decided on. When asked, the model for financing the interconnect capacity between the physical locations seemed a little unclear. There will however be a monthly fee.

Current connected parties:

  • CWI: EUnet, NLnet
  • NIKHEF: RIPE NCC, EBONE
  • SARA: DANTE, SURFnet

Possibly coming: Unisource Business Networks, AT&T.

SURFnet will try to produce traffic statistics in the style of the statistics from the MAE-East and MAE-West exchanges.

  • Italy There is an operational exchange point in Rome using shared ethernet and "bring your box" policy. The details will be presented during the RIPE plenary and were not further discussed at this meeting. For more info see http://black.uni.net/.
  • FICIX None present to talk about this. Do however see the table below for updated information received after the meeting. The FICIX medium was upgraded in August 1995 to switched ethernet, and they are looking for alternatives for faster technology as well. Traffic statistics are being collected, though it appears it's being collected with SNMP from the routers and not by "sniffing the wire." See http://www.eunet.fi/ipstats/ for statistics.
  • Portugal There is an operational exchange point in Portugal, "PIX", and it recently became operational (two days ago at the meeting). There are currently four parties connected:

RCCN EUnet PT IP Global Telepac (IP service)

Currently this is done as a 6 months experiment. The exchange is implemented using an ethernet switch, and the cost of the equipment is shared among the parties connected. The facility is housed at RCCN, and they do not have 24x7 operator coverage.

There are not being collected any traffic statistics at this exchange point.

Ireland Plans an exchange point (DINX - Data InterNet eXchange) based on the LINX model. Target date for installation is end 1995. Cost: simple cost recovery, GBP 1000-2000 / year / connection. Technology: shared ether -> switched ether -> FDDI. The policy will be "bring your box". There will be performed statistics gathering, presumably "summarized" before external consumption. They are thinking of "server housing" as part of this.

There has been a RFP out for getting housing for this facility, 7 proposals are in and the evaluation will start shortly.

Further info will be available at http://www.dinx.ie/dinx

12.1.7. Experience of BGP flap dampening

Earlier this year a severe problem was hitting "centrally placed" Cisco routers: there were too many route changes ("route flaps") for the 68k CPUs in Cisco 7000 routers to be able to process the routing updates in a timely manner, and CPU overload on these routers was a large concern. An estimate showed that approximately 10-16% of the Internet was made unreachable due to slow convergence of routes due to these flaps. Curtiz Villamizar of ANS had proposed a mechanism to deal with this problem, and Cisco has implemented a variant of this proposal. The proposal basically is to detect which prefixes (routes) are changing frequently, and dampen the propagation rate of new routing updates for these routes. This is enabled with

! router bgp xxx bgp dampen !

on Cisco routers. Note that this only dampens route propagation on external peers. At the time of the meeting this feature was only available in "special" Cisco images, later versions of 11.0 however now have this feature. Each flap entry consumes approximately 16 bytes memory, and there will be one entry for each flapping route. The CPU impact is "not much" (probably decreases CPU utilization overall due to the flap dampening).

12.1.8. Use of BGP DPA community for multihomed sites

Tony Bates and Enke Chen of MCI have drafted a proposal for a new BGP path attribute called "destination preference attribute" (DPA). The goal is to be able to avoid the currently "heavy" coordination needed to set up routing for multi-homed providers, so that a multi-homed provider can use the routing protocol mechanisms to specify "primary", "secondary" etc. paths to all downstream ASes.

The proposal calls for placing the evaluation of the DPA between MED and AS path length comparison in the BGP route selection process, ie. AS path length may be overridden by this attribute. Thus, to be able to use this an upgrade of the software of *all* transit service providers' routers is required (so that routing loops can be avoided).

Note, this is currently only a proposal, no code is available yet.

12.1.9. Report from NANOG

Dropped due to time constraints.

12.1.10. peering policy proposed for EBONE

The EBONE Management Committee has proposed a revised peering policy. The revised policy says essentially:

If you have 1 connection point to EBONE, you will be considered a customer of EBONE, and will have to pay the full price of a customer connection to set up peering.

If you have 2 connection points to EBONE, the fee for setting up peering will be 1/2 of the customer connection fee.

If you have 3 or more connection points to EBONE peering with EBONE can be established at no cost.

The time scale for implementing this policy is to start in 1996 with full implementation from 1997.

HE commented that this looks like it is intended to increase the "customer base" of EBONE. PL contested that and instead said that it was set up to easily and efficiently support the interconnection of EBONE with other international service providers in Europe.

12.1.11. European update

At this point lunch was fast approaching, so only short updates were given.

  • Dante Changed network service provider from Unisource to BT o EMPB Died, replaced with IBDNS provided by BT o EUnet A new trans-atlantic connection will come up FI-US (New York), partly with the connections to Russia in mind.
  • Ebone Still not dead, new EBS in Amsterdam connected with 4Mbit/s. Currently 35-40 customers and still growing.
  • BT Nothing to add (now operates IBDNS, see above).
  • Pipex Transatlantic capacity upgraded from 5.5Mbit/s to 6.3Mbit/s. Connection to Ghana up and running. New con- nections to CZ, HK, Malta, Macau. There is work going on to migrate backbone in Europe to a "shared infrastructure".
  • Unisource Operating in SE, CH, NL. Looking at alternatives for interconnection.

12.1.12. EOF marketing

PL expressed the view that the EOF should be more active in bringing startup Internet service providers on-board, and wanted input on how to achieve that. Since funds are typically strained in the startups, this could possibly be achieved through forming local (national?) EOF-like bodies. A remark was made that these need to be open for all participants.

12.1.13. AOB

DNS registration issues (eg. latest InterNIC action) pushed to DNS WG due to time constraints.

A remark was made that there is a need for distinguishing between "helpdesk" and "technical contact" in the RIPE database. It is becoming increasingly difficult to get past the "first-line defenses" of service providers to get timely action to solve real technical problems. This will be pushed to the RIPE DB WG.

12.1.14. Next meeting

Default: just ahead of the next RIPE meeting.

Meeting adjourned.

12.1.15. At the plenary after the presentation

Peter Lothberg presented a table of data on various Internet exchange points and asked the audience if they could provide more points to include in the table. (Yves Devillers & others) It is not really fair to compare the more professional exchange points with smaller ones from one ISP (PL) I'm just trying to inform people of what is available (YD) A look at the webpages of most exchange points provides better information (Wilfried Woeber & others) While this is true, the pages only give information on their own organisation. So an independent table is useful.

12.1.16. Table of european internet exchanges

Year conn. Web Tech Future Stats Bring own cost nets info impl tech Space v box? Location

London 5000GBP 13 Y Eth-S 100Mb/s 8U 19" N Yes FM Telehouse
Paris 50K FFR 4 N Ether Ether-S C-4000 N No FM FR Telecom
Cern Ask 4(3) Y FDDI Ask Y Yes FM Cern
Amsterdam Ask 6 Y Ether FDDI-S Ask Y Yes FM SARA/NIKHEF
Roma 0 5 Y Ether Ether-S Yes(?) Y Yes FM CASPUR
Helsinki 24k FIM 5 N Eth-S open 8U 19" Y Yes FM EUnet
Portugal Modest 4 N Eth-S 8U 19" N Yes FM RCCN
Dublin 1-2 KECU (6) Y Ask Y Yes FM nn
Stockholm 0 16 Y E-S/F-S TAXI 8U 19" N Yes FM KTH
Munich Ask 3 N Ether Ether-S Ask N Yes FM ECRC
Moscow 9 Ask 6 N Ether Ask ? Yes FM M9 PTT stn Pisa 0 3 N FDDI N Yes
Milan Ask 3 N Ether Ask N Yes FM Cilea

12.2. Local IR Working Group

Chair: Mike Norris
Scribe: Anne Lord

At this working group meeting there were 43 attenders.

12.2.1. Preliminaries

Anne Lord (auto) volunteered to take the minutes. The agenda was agreed as previously drafted to the working group mailing list. No additions to the agenda were made.

12.2.2. RIPE 21

As the draft minutes of the working group meeting from RIPE 21 had been circulated and no objections were raised, they were formally approved.

12.2.3. Reports from Registries

12.2.3.1. European Regional Registry (NCC)

Staff Developments: Since the last RIPE meeting, the RIPE NCC has appointed three new junior hostmasters:

  • Nick Reid (full time) from UK
  • Hatice Kuey (full time) from Turkey
  • Els Willems (part time) from The Netherlands

Additionally a further two more part-time junior hostmasters will start on 16th October:

  • John Crain from UK
  • Soodabeh Eshghi from Iran.

It is estimated that by the end of the year with these additional resources that local IR's will no longer experience hostmaster delays.

Request Tracking System: This is currently being implemented at the RIPE NCC. The tracking system has been described in RIPE document:

  • ftp://ftp.ripe.net/ripe/docs/ripe-183.txt

All new requests are issued a ticket number, which should be used in future related correspondence. Absolutely crucial to any dealings with the RIPE NCC hostmasters is your registry ID.

The RIPE NCC now deals with around 300 local IR's, and increase of around 60 since the last RIPE meeting.

12.2.3.2. Last Resort Registries

There are currently around 30 Last Resort Registries. In the context of previous discussions around Provider Independent and Provider Allocated address space (ripe-127) it has been agreed that Last Resort Registries should be phased out.

At the NCC contributors meeting it was decided that the last resort IR's should be charged like any other registry. This has had the desired impact of accelerating the number of Last Resort IR's wanting to close. Billing for 1996 will be issued in November. A question was raised as to how many last resort registries expect to continue operation after November and the answer was out of the 7 present, only 1 expected to continue.

A question was also raised regarding what to do with the remaining address space held by the last resort registry if they wished to close. The answer was to contact to discuss the procedures.

There was another question, regarding what to do with large companies who are requesting PI address space. They can contact the RIPE NCC to discuss becoming an enterprise registry. They can also receive PI address space but this will carry with it no guarantees of routability in the Global Internet. Local IR's can hold PI address space, but this will be allocated by the RIPE NCC probably from the remaining 192.x.x.x address space.

12.2.3.3. Other Registries

There were no comments from other registries.

12.2.4. Global Coordination

There has been minimal progress on rfc1466++ due to lack of time from all parties involved. The revision of ripe-104++ is dependent on this rfc being updated. It was proposed to finish updating ripe-104++ irrespective of the development of the rfc as the RIPE document is urgently required as a guideline document for the many new IR's coming on board. There were no objections to this proposal.

Action 22.1 on Mike Norris and RIPE NCC
To find volunteers from the Local IR working group to continue working on the revision of ripe-104++ without waiting for the publication of rfc1466++.

12.2.5. RIPE NCC Services

12.2.5.1. Charging model for 1996

At the RIPE NCC contributors committee meeting in September a charging scheme for 1996 was agreed (This scheme was circulated in the minutes of that meeting). The billing scheme is described at

  • ftp://ftp.ripe.net/ /new-registry/billing-96.txt

Bills will be issued in November, unless you contact to say that you would like to be billed in January 1996. So far, there have been no cancellations for RIPE NCC services from any registries.

It was also decided that the "time-permitting" service would be discontinued. The RIPE NCC hostmaster service is offered to contributing registries only.

12.2.5.2. Billing procedures

In summary, there are 4 categories and each registry decides which category they would like to be in. The category information per registry is public information but the RIPE NCC commented that in the future they may be more active in suggesting, movement between categories to established local IR's.

12.2.5.3. Charging by local IR's

This was not discussed (or I have no notes on this !)

12.2.5.4. Tracking and ticketing system (ripe-183)

Already discussed above.

12.2.5.4.1. Training

There have been 4 courses held. There are approximately 15 attendees per course, and this is the maximum number of attendees sought per course. There are two further courses planned for November, one in the UK and one in Norway. The dates are not yet fixed but there will be an announcement to the local IR mailing list.

Note should be made that the training courses are only open to local contributing local IR's. If any local IR is inter- ested to host a course, then the RIPE NCC would be happy to deliver a course in your country. Please contact to discuss the details further.

The slides from the training courses in Amsterdam and Munich are available in the RIPE document store in:

  • ftp://ftp.ripe.net/ripe/local-ir/training/*

12.2.6. Address Assignment

12.2.6.1. Procedures (ripe-104)

As discussed above the need for ripe-104++ documentation is now so great that it was suggested to form a group of volunteers from the local IR working group to actually progress this document asap. Ideally, this document should be ready before the next RIPE meeting in January. It was suggested to have the volunteers to come to the RIPE NCC for a day to meet to progress this work. The RIPE NCC would pay for travel and subsistence for those interested.

12.2.6.2. PI vs PA address space (ripe-127 upcoming rfc)

Ripe-127 is on track to become an rfc. Daniel Karrenberg was informed by the rfc editor that the publication of this document is on track. It was generally recommended to include in documentation to your customers a clarification over the PI and PA recommendations in ripe-127.

12.2.6.3. Reverse domains

The procedure for delegating reverse domains has now been automated. David Kessens gave a short presentation of this. In summary:

use 'inetnum' object with one nameserver per 'rev-svr' attribute or for block (/16) delegations, with one nameserver per 'nserver' attribute

Using the wrong attributes in the objects will not break the auto-delegation procedure.

The software for this tool is available in

  • ftp://ftp.ripe.net/tools/inaddrtool-950815.tar.gz

Note that the RIPE NCC only makes delegations for 194.x.x.x. and 193.x.x.x blocks of address space.

There was a question regarding delegations for > er than /24 prefixes. This is possible and there is a description of how to do this in the document store in:

  • ftp://ftp.ripe.net/internet-drafts/draft-degroot-classless-inaddr-00.txt
12.2.6.4. Status and use of rfc1597

The revision to rfc1597 is currently being discussed within the IETF CIDR-D working group. The revision will be reissued as a BCP - "Best Current Practices" rfc series.

It was again recommended to point not only large organisations with firewalls at this document, but also VSE 's < 50 hosts not wanting to connect to the internet.

It is hoped that this document will be out by the December IETF. The actual content of rfc1597 will be changed considerably. It is noted that the address space reserved and used for private address space still stand.

12.2.7. Tools

There were no other reported tools other than that circulated previously by Nigel Titley. The tool checks the status of the registrations in the RIPE database against another file in which records of registrations are held.

The source code is available from:

  • ftp://ftp.bt.net/networking/tools/tree/tree-2.1.1.tar.Z

12.2.8. Input from other working groups

12.2.8.1. Database

There was a request for clarification of the difference between the mail address and the . It was noted that the address contained some additional sanity checking for new objects, so that existing objects could not be clobbered. Further discussion over this was deferred to the database working group.

Additionally, there was a question over whether route objects, with no matching inetnum objects should be allowed or checked for. It was deferred to the database working group for potential discussion.

12.2.8.2. EOF

The EOF working group highlighted a need for a survey of domain procedures amongst different top level domains. This topic was taken up in the DNS working group.

12.2.9. AOB

There were no items discussed. The chair thanked the audience for their input.

12.3. DNS Working Group

Chair: Antonio Blasco Bonito (ABB)
Scribe: Benoit Grange (BG)

12.3.1. Preliminaries

Rob Blokzijl presented the apologies from the working group chairman, Leonid Yegoshin (LY), who had a visa problem and asked ABB to chair the group.

The agenda was reorganized and agreed.

12.3.2. Reports about DNS Failures

[This item should have been covered by LY, but because he was not there some of us reported current problems]

BG talked about the known problem with unnecessary glues that appear in zone transfers. This happens on most old implementations (BIND prior to 4.9) as shipped my most of the vendors.

DNS Operation suffers from old implementations that have known bugs and problems.

The usual suggestion is to install a recent version of BIND, which happens to be a beta version. It was noted that, although that effectively eliminates the problem, many DNS administrators are not willing to use a beta version.

The working group agreed to contact ISC about this.

Action 22.2 on Antonio-Blasco Bonito
To send a letter to the ISC to ask to put BIND 4.9.3 in final so that doubts about it are solved.

Many expressed concern about how delegation changes are done at the Internic.

Today Internic accepts any change to current delegation (normal and reverse) and also to glue records. This leads to situation where some bad data is introduced, either as an error, or as some malicious action.

Eg:

'ns.ripe.net' (193.0.0.193) is primary for 'ripe.net' and a lot of important zones. John Doe wants to create a 'johndoe.com' zone and submits a request to Internic mentioning both 'banana.johndoe.com' (198.1.2.3) as primary and 'ns.ripe.net' with a WRONG address 193.0.0.93 because of a typo.

Internic creates the 'johndoe.com' zone and CHANGES the glue record for 'ns.ripe.net'. All delegations to 'ns.ripe.net' are affected because Internic accepted unnecessary glue record from John Doe and blindly accepted to change an existing name server IP address.

The working group recommends that Internic is more careful with accepting glue records.

Action 22.3 on Geert Jan de Groot
To recommend to the Internic not to accept unnecessary glue records and to double checks any change to existing glue records

Some people do not watch their name servers: it happens that some name servers are left unattended and fail without anyone noticing. This has an impact on the performance and reliability of the overall name service.

People should watch their name servers and their zones on their primary and secondaries. At least the 'host' command can be used with the '-C' option to do this at regular intervals.

During the plenary session someone remembered the existance of RFC1713 A. Romao, "Tools for DNS debugging", which is usually referred to as the guide for DNS administrators and sug- gested to ask the author to include such recommendation.

Action 22.4 on Antonio-Blasco Bonito
To ask A. Romao to include a recommendation on regularly checking zones into RFC1713,

12.3.3. 'in-addr.arpa' automatic checking and delegation (D. Kessens)

David briefly talked about the tool he wrote which is being used at the RIPE NCC. This tool checks if the reverse zone is correctly configured as per RIPE requirements.

Usage: Send an e-mail message to '[email protected]' containing the 'inet-num' object with 'rev-srv:' attributes listing the desired name servers (1 name server per line). Send an empty message to get help.

The final editing of the zone file is still done manually and the operator also checks the author of the update.

After a short discussion the group agreed that some authentication mechanism be added in order to avoid malicious changes to current delegation, specially when the reverse delegation process will be completely automated.

Action 22.5 on RIPE NCC
To include some authentication mechanism into the auto- matic reverse delegation process.

This tool could also be used to check for normal delegations, but only after some rewriting because some of the checks are specific to reverse delegation or RIPE requirements.

Sources are on

  • ftp://ftp.ripe.net/tools/inaddrtool-VERSION

Another tool to check delegation exists under

  • http://www.nic.fr/ZoneCheck

Action 22.6 on Benoit Grange
To make the sources of the ZoneCheck tool freely available by the end of 1995

12.3.4. Future developments of the name servers

It was reported that:

  • Paul Vixie got RU-BIND and will somehow merge the two programs.
  • IBM has donated code to do dynamic updates, and an other source is available as well.

12.3.5. About the recent changes of the root name servers

All root name servers have been renamed as '.root-servers.net'.

If you want to know the "old name" of a name server, query for the TXT record associated with the name.

A new primary for the root zone will be created and managed directly from IANA, and the primary for the '.com', etc. zones will remain managed by Internic.

12.3.6. Charging for domain names, etc.

A European 'TLD' forum might be useful, and the first move should be to collect how TLD management is done over Europe.

Different countries have different policies, etc.

Some multinational company which wants to create a bunch of domains in different countries needs more information on how this can be done and who should be contacted.

The working group decided to set up a questionnaire and Guy Davies collected a lot of questions.

Action 22.7 on Guy Davies
To organise the TLD questionnaire, submit it to the list for review and later send it to the European TLD admins.

12.3.7. At the plenary after the presentation

There was a lively discussion about the proposal to ask ISC to release BIND 4.9.3 as a final version. Some people opposed this, as there is already a lot of pressure to release BIND 4.9.3 and sending the letter would not help much. If the release is delayed, there are reasons for it. Others argued that BIND 4.9.3 beta is better than any other available BIND version, and most ISPs are reluctant to use a beta version. Therefore 4.9.3 should be released as soon as possible, despite the bugs it may still have. No real consensus was reached except to communicate to all European operators that 4.9.3 beta is the best version to use at the moment, and to inform everyone as soon as possible when 4.9.3 final version is released.

Tomaz Kalin informed the audience of an announcement on the ISO board mailinglist about charging for domain names. At the moment this only applies to the '3-letter top level domains', but this may change. There will be a meeting to which RIPE, probably in the form of Daniel Karrenberg, will be invited. Tomaz proposed the European TLD maintainers to discuss and define a policy about charging, and give the results to the RIPE delegation that will be invited.

Antonio-Blasco Bonito noted that the RIPE NCC does not have anything directly to do with domain name registration. Rob Blokzijl commented that this is true, but still it is a good organisation to collect information from the TLD maintainers and present a policy to the ISO meeting. Daniel Karrenberg added that there has been no invitation to the meeting, but that the RIPE NCC is willing to do this when asked.

12.4. Routing Working Group

Chair: Rob Blokzijl
Scribe: Joachim Schmitz

Chairman Jan Willem van der Scheun was ill. Rob Blokzijl volunteered as temporary chairman for this specific session.

There was no draft agenda. It was set up on the fly with three topics:

  1. The RA Project a presentation by Brian Renaud (Merit)
  2. The RIPE Routing Registry an overview by Daniel Karrenberg (RIPE NCC)
  3. RIPE Routing Registry, R & D overview by Daniel Karrenberg (RIPE NCC)

There were no additions from the audience.

12.4.1. The Routing Arbiter Project

After filling in the historical background an overview was given of the transition from the old NSFNET PRDB to the new RADB and a description of the current situation including Route Servers and some current data from the present RADB.

Then the current initiatives were presented, e.g. continued clean-up of the database, generation of usage and analytical reports, support for RSPL extensions, and support for PGP authentication (with a trial setup running at the moment).

Afterwards, Brian Renaud gave a review of the tools recently developed at the RA Project. There are several tools which handle, e.g. - configuration from the database - policy generator from configuration - monitoring of running networks These tools are now not only developed for the Router Servers (which are Sun Workstations) but also for Cisco Routers. There are also various tools under development which among other things feature a GUI for selected tasks.

Brian Renaud wants input on the tools from anybody who wants to use them or has contributions/suggestions. Mail addresses are on the transparencies which are available at:

  • ftp://ftp.ra.net/routing.arbiter/radb/presentations/RIPE-22_renaud_routing.ps.gz
  • ftp://ftp.ripe.net/ripe/presentations/ripe-m22-renaud-routing.ps.gz

More information on the tools is available at: http://www.ra.net/~ra/tools

12.4.2. The RIPE Routing Registry

Daniel Karrenberg only had a few remarks:

  • The RIPE database is cleaned up from obsolete data. In most cases the responsible persons are directly contacted
  • The data in the registry are compared to the real world
  • Tools for the router configuration from the database are most valuable. The NCC wants to make the Merit tools better known in Europe and wants to participate in their development (see below) and immediately opened the discussion. The topics were:
    • How to handle changes with large numbers of objects (both RADB, RIPE)? They may be done using the automatic machine interface or by submission to the human interface by personal mail (especially for global changes).
    • Is the RADB publicly available like the RIPE database? It may be fetched via FTP from the Merit server. However, it may be made available on the RIPE server. They mirror it anyway.
    • What is the status of the advisory tag? The advisory is not yet obsolete. ANS still needs it for operation. For European ISPs advisories are only neces- sary in the RIPE database. There is no encouragement to register in more than one registry because of the planned GRR which is under construction.
  • Do ISPs register in the RIPE database? They do not only register but surprisingly many also maintain their data. This is enforced by the RIPE NCC a bit which makes registration of a routing policy mandatory when registering a new AS. There is a general feeling that many more will register and maintain data if proper tools exist to make it easier. Data on the database population will be made available again (as it was done in the PRIDE project). The quality of the data will be checked by RIPE NCC (whether data are updated, consistent, correct...)

Action 22.8 on RIPE NCC/Merit
To make the RADB publicly available on the the RIPE FTP server (if Merit concords)

Action 22.9 on RIPE NCC
To find a FINAL date together with ANS when to give up advisory tags.

There was some discussion on authentication, PGP, and cryptography, mostly related to the RADB as first implementation and future ideas for the RIPE database. PGP authentication by signature is formally a simple new value of the "auth"-tag in the maintainer object (RADB test suite). However, the PGP keys must be safely stored at the database site. There was some discussion on how to do this (in or out of the database). From the experience of both RIPE NCC and Merit there were only very few attempts to willingly change objects of other parties when not being allowed to. They were all detected through the notification facility (which is the same for RADB and RIPE database because the same database manager code is used). Therefore, it does not seem to be necessary to have strong authentication (or even cryptography). However, some organisations like PTTs have stronger security demands and ask for it. They would not register without.

12.4.3. RIPE Routing Registry, R & D

Rob Blokzijl points out that the RIPE NCC wants to enforce R & D again. Daniel Karrenberg states that the RA people do more for the progress than the RIPE NCC. The RIPE NCC and the Routing WG should/want to do more. A focus should be found to make information in the routing databases significantly more useful. A first step had been taken by development of diagnostic tools in the PRIDE project. This effort should be extended not only on diagnose but also on tools for configuration and real time analysis and monitoring. There are other fields which should be considered but these are the most important. More useful architectural work should be done and one area should be chosen to join the efforts of the RA project group.

The following discussion in the audience did not lead to a final conclusion on which area to chose. Therefore, two actions are placed on the RIPE NCC:

Action 22.10 on Daniel Karrenberg
To trigger the discussion on the mailing list of the Routing WG, which focus to choose for a future tool development project and to come to consensus on it.

Action 22.11 on Daniel Karrenberg
Based upon the focus found in the Routing WG to prepare a draft paper for the new project and to present it at the next RIPE meeting in January.

12.5. Database Working Group

Chair: Wilfried Woeber
Scribe: Hans Petter Holen

12.5.1. Administrative stuff

Hans Petter Holen, Oslonett AS, volunteered to take notes. 37 people subscribed to the circulated list of attenders. The proposed WG-agenda was accepted.

12.5.2. DB-SW review

David Kessens went through the Database Development Report, covering new functionality that is either being proposed or already in test. As usual the slides for this presentation are available at

  • ftp://ftp.ripe.net/ripe/presentations/ripe-m22-david-DB-REPORT.ps.gz

David reported that the NCC currently works towards making the RIPE-DB more reliable. On the hardware aspect the DB-machine is being fitted with a RAID system (to guard against single disk drives failures). At the same time a "shadow server" for the database is being implemented and tests have already begun.

Some problems with portability and scaling of the database software have been reported recently. It was pointed out that the RIPE-NCC version of the database software is tested and supported for Perl4. There is a couple of known (minor) problems in trying to port the software to Perl5 (and to Solaris). Resolving of these problems is not the top priority, but will be tackled as soon as possible. In order to avoid the scaling problems David recommended to *not* use the -P option of netdbm and to eventually move to the Berkeley db package. Tests are on-going.

New functionality worth noting (for a comprehensive list please refer to the presentation slides):

  • Hierarchical authorisation schemes to be implemented
  • Referral mechanisms to be implemented, first tests with domain: objects
  • -t option plus -v should give more elaborate descriptive text for objects
  • The NOC-Object to be implemented soon, according to proposal from Havard Eidnes, as circulated shortly after RIPE-21
  • "Synchronized DB" is running in test environment
  • There is a proposal to automate and inter-lock the assignment of RIPE-Handles. This should eventually remove the need to manually obtain unique handles (with the finger mechanism) and the potential race condition due to the delay between assignment of a handle and submitting/referencing the objects.
  • Inverse lookup, initially for person: objects The same functionality was requested for other object types during the discussion specifically to get better selection criteria for entries in the routing registry. While part of this functionality is available by access- ing the data through wais, this was seen as not really adequate. Still this method should be improved as much as possible!
  • Authentication and Security This is currently under active consideration. In particular both PGP and MD5 should be available. There are both legal/logistic issues (see below) as well as software issues. In particular we have to decide on the method for registering keys and whether to use a "standard package" or to move functionality into the database software itself. During the discussion it was suggested to stick with "standard packages" because things are not yet stable. (Merit is using the "standard package" as well.) The RIPE-NCC is probably following the same path.

12.5.3. User interface(s)

Encryption is probably going to be a legal problem in (at least) France. In addition to that there was a comment that part of the technology has recently been submitted for patent protection.

Probably the first thing to be available shall be PGP protection for signing messages. The details to guard against snooping and re-play of updates are currently be solved. (Detailed input has been received after the WG meeting).

A couple of WWW interfaces to the various databases have been made available recently. There is not yet consensus whether this is the right way to go, especially for submitting updates. The RIPE NCC thinks that the DB is not focussed toward the "end user" but towards ISPs. Other comments indicated that the WWW interface could be useful for all sorts of operational people as a well-known user interface.

Both Brian Renaud as well as Paolo Bevilacqua have recently made implementations available:

  • http://black.uni.net/cgi-bin/whois
  • http://www.ra.net/cgi-bin/ra/query-radb.pl

12.5.4. External interfaces

Exchange of data with the InterNIC is still not happening. All the necessary agreements and good intentions are in place, still the InterNIC seems to regard it as a low priority issue. European ISPs want this to work really soon and regard it as *urgent*. There is not much the NCC can do right now.

The different functionality of the auto-assign vs. auto-dbm mailboxes was briefly reviewed. The differences as not widely known, and the interlocks could be improved. The NCC thinks about moving towards vkeywords on the subject line, similar to "LONGACK".

12.5.5. Input from other WGs

  • MBone The expansion of the inet-rtr: object to cover multicast functionality is to be progressed now.
  • IPv6 There is a discussion going on how to handle and possibly abbreviate things for IPv6 (macros?). Input welcome.

There was a comment that similar ideas are being (or have been) discussed in the RPS environment.

12.5.6. AOB

None, thus the meeting was closed.

List of new actions

Action 22.12 on David Kessens
To work with A. Blasco Bonito to improve the WAIS functionality for access to the database information on info.ripe.net.

Action 22.13 on Geert-Jan de Groot
To try to follow up with the InterNIC about accepting person objects with RIPE-Handles.

Action 22.14 on RIPE NCC
To circulate a proposal how to progress the authentication (and encryption) method for the RIPE Database.

Action 22.15 on RIPE NCC
To analyze the merits of implementing special keywords for the subject line of update messages, like ADD, MOD, DELETE, to possibly replace the functionality of special mailbox names (e.g. auto-assign).

Action 22.16 on RIPE NCC
To follow up on and implement the NOC-Object.

12.5.7. Questions and remarks from the audience at the plenary

Christian Panigl: It would be a good idea to add the advisory attribute to AS templates. Since all routes from a given AS have the same advisory, it seems stupid to add an advisory line to every route object.

Havard Eidnes: Some would say it is stupid to use advisories at all.

Wilfried Woeber: We should not remove functionality from the software. However, the discussion about the validity of the advisory attributes is more for the routing working group.

NCC: Use of advisories is discouraged in the documentation. But we can add the advisory attribute without problems.

Action 22.17 on David Kessens
To add the advisory attribute to the AS template in the database software and change the documentation accordingly

12.6. MBONE Working Group

Chair: Magnus Danielson (KTH/IT)
Scribe: Erik-Jan Bos (SURFnet)

12.6.1. Opening

12.6.1.1. Welcome

Erik-Jan Bos, Chair of the Mbone WG until last October 1st, welcomed everybody present. He explained that due to busy work (in other fields) at his employer he did not have the time anymore to devote time to chairing this WG. Erik-Jan Bos introduced Magnus Danielson of KTH/IT and welcomed him as new chair of this WG, wishing him success and all the support he can get from the Working Group. After this introduction, Magnus Danielson took over chairing the Mbone WG.

12.6.1.2. Apologies

No apologies were received.

12.6.1.3. Minute taker

Erik-Jan Bos volunteered to act as scribe for this meeting.

12.6.1.4. Outstanding action items

The list of outstanding actions was reviewed:

Action 21.7 Done (and taken over by events).

Action 21.8 Done, information submitted to Joel Halpern, AD of the IETF Area on routing, by Peter Lothberg, during the last IETF.

Action 21.9 No progress yet, will be done.

Action 21.10 Done, Victor Reijs will try to be present at the next Mbone WG meeting in January 1996.

Action 21.11 Done.

12.6.2. Introduction New Chairman

Magnus Danielson introduced himself. He is working for KTH/IT in Stockholm, Sweden and he has a background in networking. His current tasks include extensive work on multicasting technology and multicasting applications at his employer.

12.6.3. Workplan for the next year

12.6.3.1. The workplan for 1996 was discussed

The item that were put on the list were:

  • Keep the maps of the multicast topology inside Europe and to the US up to date.
  • Progress the work on registering mrouters in the RIPE Data Base and make sure it gets implemented and used.

Wilfried Woeber asked whether it was a good idea to put the engineering of the coexistence of Mbone over IP and Mbone over IP-over-ATM in the workplan. Magnus Danielson explained that this is not a real problem, and business as usual. It is all Mbone over IP.

12.6.4. The Mbone topology in Europe (and to the US)

12.6.4.1. Strategy for transition into hierarchical routing scheme(s)

Magnus Danielson introduces the concept of Multicast Routing Domains (MRD). Europe (or better: The RIPE community) can be viewed as one MRD, with sub-MRDs below it.

Peter Lothberg explains that the technology for multicast routing still has (a lot of) flaws, one being the fact that RPF-checks in routers now can kill connectivity. The bottom line here is that unicast routing can take a different path then multicast routing.

Magnus Danielson explains that at the end of this year we might expect hierarchical routing in mrouted. Bill Fenner of Xeroc PARC is working on this.

12.6.4.2. Strategy for inter-domain (RIPE domain) topology layout

The basic question is how to set up multicast routing between domains, not only in Europe, but also between Europe and the US. Once you have something that is working the next question is how do you manage the multicast network. Havard Eidnes points out that multicast routing suffers from lack of tools for checking and debugging and that multicast routing suffers from lack of routing domains.

Judging from the lack of tools and domains we cannot state that the Mbone is a production service, but should be labeled "pilot" or "experimental". Kevin Hoadley states that UKERNA want to declare Mbone inside JANET a production service, but this is inside one domain.

12.6.4.3. Strategy for intradomain (RIPE domain) topology layout

Erik-Jan Bos states that inside SURFnet the using of pruning capable multicast routers is "highly recommended" and people wanting to connect to the Mbone inside SURFnet are explained why they need pruning. This has lead to the result of all- pruning-capable-router Mbone subnet in SURFnet. Kevin Hoadley explains that UKERNA more of less does the same.

Magnus Danielson proposes to come to the same "rule" for the RIPE community. Kevin Hoadley adds that "everybody should guard his own backyard".

Magnus Danielson also proposed that the mbone-connectivity could be cut to a troublesome machine. This was agreed upon as a WG policy.

Action 22.18 on Magnus Danielson To write up a statement which explains why a Multicast Routing Subdomain needs to be pruning-capable and to circulate this.

Action 22.19 on Magnus Danielson To gather information about which version of mrouted or the Cisco code to run in order to be pruning capable and to include this information in the Mbone EU FAQ.

Magnus Danielson proposes to work towards a situation in which a set of Mbone core routers in Europe managed by a core of people. The general feeling is that is it not feasible that root-passwords are given out for remote management, since in today's Mbone in Europe many mrouters do more than just mrouting. SNMP monitoring could be the way forward and it is suggested that this is further pursued.

The methods for management of the European part of Mbone are twofold to begin with:

12.6.4.4. Strategy for intradomain topology management

Although we are still missing (essential) tools for managing the Mbone, it was felt that it would be very useful to have some statistics on the usage of Mbone. SNMP could (and should) be the way forward.

Action 22.20 on Magnus Danielson
To come up with a proposal for monitoring (part of) the European Mbone through SNMP.

12.6.4.5. Software versions and global optimizations

The correct version to run for mrouted currently is version 3.6. The Cisco code still does not support pruning, but IOS 11.0(2) (or better) has fast switching for multicast available.

12.6.4.6. Maps

The current map is not up-to-date. Work needs to be done.

Action 22.21 on Magnus Danielson
To find a new volunteer for recreating (and keeping up to date) the Mbone map of Europe and its connection to the US.

12.6.4.7. Link description list/map

It is not on the WG's wish list to create yet another data base object. It is however on the wish list to have this information available. The way forward for this is the inet-rtr:-object in the database which will contain information about the links a specific mrouter has.

12.6.4.8. Machine description list

This will be covered to some extent by the work done by Erik-Jan Bos registering an mrouter in the RIPE Data Base.

12.6.5. Various issues

12.6.5.1. What is the production status of Mbone - really?

This item was discussed earlier during the meeting (see Item 4). The group reached consensus that we regard Mbone as a pilot service.

12.6.5.2. Updating of who-controls-which-machine list

There is a list of maintainers of core Mbone routers available on a SURFnet machine. The directory containing this information and other is:

  • ftp://ftp.nic.surfnet.nl/surfnet/net-management/ip/mbone/

Action 22.22 on Magnus Danielson
To include a pointer to a list of maintainers of core Mbone routers in the MBONE FAQ, until this information is in the RIPE Database.

12.6.5.3. The [email protected] list

Magnus Danielson announces that for operational matters regarding Mbone in Europe a new list is set up. The reason for creating this new list is that [email protected] is much too noisy to do a coordinated form of coordination on. The full address of the list is [email protected].

Erik-Jan Bos states that it is important for people to be on this list, when you are running a (core) mrouter, since if you are not you might miss important information on the status of Mbone which in turn might be harmful for your uni- and/or multicast routing.

12.6.5.4. Mbone EU FAQ and Web Pages - call for more info

The current FAQ was updated some time ago. It needs another update, but it also needs rehoming to a machine on which Magnus Danielson can easily manage the pages.

Everybody is encouraged to contributed to the information contained in the FAQ!

Action 22.23 on Magnus Danielson
To rehome the current FAQ to a machine close to his home institution on which the maintaining of the FAQ can be done.

12.6.6. Free forum

Several items are brought forward:

  • Antonio Blasco Bonito asks whether we need to do something about the fact that EMPB is not used any longer and that most regionals doing Mbone are now connected to IBDNS. The answer is yes, but we need a small group of people for this.
  • Wilfried Woeber asks how effective pruning is especially in backbones. Magnus Danielson answers that it is less effective than you might think, due to the fact that somebody will always be tuned in to a session, however it protects you from two users setting up a (high volume) session between each other over the Mbone. Pruning ensures that only the path between these two users carry the traffic.

12.6.7. Closing

Magnus Danielson thanked all participants for their contribution and closed the meeting.

12.7. Connectivity Working Group

Chair: Milan Sterba
Scribe: Keith Mitchell

12.7.1. Internet Demography in CEE

Table of CEE connectivity presented - hosts, telephones per capita etc statistics.

Poland and Czech Republic, then Hungary, have significantly highest host counts.

CEE hosts 4.6% of European.

Highest hosts per 1000 population CZ, EE. HU, SI - not far behind France. (High German figures queried.)

Hosts and phone lines per 1000 pop. figures compared - some countries have significant potential (BG, LV, LT).

Growth in (host count ?) - highest BG, SI, UA.

Another metric is hosts per SOA - range is ~20-100.

Number of SOAs - highest is Poland.

Hosts/GDP per capita (1991 figures).

Request for feedback/suggestions on usefulness/scope of fig- ures.

12.7.2. Per Country Updates

Armenia

  • 64k satellite to Moscow State Univ.

Bulgaria

  • connected to AConet in Vienna, and US (64k sat, 2x9.6k terrestrial)
  • 28k leased line Varna-Amsterdam, 64k being installed

Czechia

  • CESnet (DANTE Amsterdam, Ebone Vienna) 2x512k
  • EUnet CZ (256k)
  • IBM
  • PVT 64k to PIPEX by end 95.
  • SPT Telecom announcement.

Cyprus

  • 64k to Hellas On-Line and PIPEX

Hungary

  • IIF association (formerly SZTAKI)
  • HBONE: 128k DANTE, 256k Ebone - all traffic through Budapest
  • PTT Matav putting in 2M circuit to Vienna, 1M for HBONE, 1M for commercial resale
  • EUnet HU 64k
  • Datanet 128k to Sprint (sat)
  • iSYS 64k to PIPEX
  • Odin VSAT disconnected from PIPEX due to non-payment
  • Also Compuserve, IBM, MSN activity

Baltics

  • Plans for big NATO civilian programme to connect "co-operation partners" up for scientific projects
  • Looking for NATO country-based partners to help connect these countries.

Lebanon

  • X.25 connection to BTnet
  • Planned PIPEX connection
  • INCOnet to MCI via US ?

Malta

  • Planned 128k to PIPEX London

Poland

  • NASK is major provider: 2M to Stockholm, 256k Ebone Vienna, 64k FREEnet Moscow, 64k Luv Ukraine.
  • EUnet PL to Germany
  • Polish PTT, Telbank and ATM are NASK resellers.
  • Minsk in Belarus connecting to PTT (funding problem ?).
  • More info at www.nask.org.pl & info.fuw.edu.pl

Romania

  • DANTE 9.6k.
  • Ebone 64k satellite Vienna.
  • EUnet RO to Amsterdam
  • SIPEX 19.2k VSAT to PIPEX via BankNet in Budapest.

Russia

  • Two-tier hiercharchy emerging:
    • National ISPs - EUnet/Relcom, Demos, Sovam, Runnet.
    • Small regional ISPs - some connected to >1 national
  • International connectivity:
    • EUnet/Relcom 512k
    • Helsinki Demos 128k
    • Amsterdam RoSprint 64k
    • SprintLink (sat)
    • SOVAM 64k
    • BARRnet/BBN (sat)
    • Runnet 128k
    • RENATER Radio-MSU 512k
    • DFN FREEnet 64k
    • NASK and 64k MCI
    • RUSnet 64k
    • FUnet

RIPN group getting together to plan some kind of national backbone, RBnet. Interconnect point at Moscow 9 major tele- phone exchange "M9-IX" being set up. Idea is to set up simi- lar exchange points in other major cities and connect them.

Yugoslavia (former) = Serbia+Montenegro

  • Academic network YUnet currently not connected to Internet
  • 1200 hosts, 2 Class Bs
  • Analogue circuits between cities, 64k within Belgrade.

Slovakia

  • SANET academic network: 128k to CESnet, 128k to Ebone
  • EUnet SK: 64k to EUnet
  • 64k Bratislava to Vienna costs 9000DM/month for 60km (more than transatlantic circuit !).
  • More info at www.eunet.sk & www.sanet.sk
  • Inbound traffic only 1.5 times outbound traffic.

12.7.3. Who are the Absent ?

How do we encourage new providers to attend - discussion.

12.7.4. CDS Seminar

Connectivity Data Store - invitation to providers to add links to/from this.

12.7.5. Refocus - who we are, what we do.

Group's main important function is information exchange.

13. Next RIPE meetings

The scheduling of the next meetings was discussed and the following dates and locations were agreed:

  • RIPE 23 - January 29-31, 1996 - Amsterdam, Netherlands
  • RIPE 24 - May 1996 - Berlin, Germany
  • RIPE 25 - September 1996 - Amsterdam, Netherlands

14. AOB

None.

15. Closing

Rob Blokzijl thanked the participants for attending and NIKHEF for providing the room facilities and lunches, and declared the meeting closed.