1.1. Welcome
Rob Blokzijl welcomed the participants to the 20th RIPE meet- ing 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
The agenda was approved. Note: some of the agenda items were rescheduled during the meeting but they are minuted as origi- nally scheduled.
The minutes of the 21st RIPE meeting were approved with no changes.
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"
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.*
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.*
Dante Services started with a new underlying network on Octo- ber 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 Back- bone (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 (Interna- tional Backbone Domain Name Service) is the new backbone man- aged 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 con- sists of 2Mbps lines.
A time frame of 4 months was set for connecting all EMPB net- works 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 fil- tering on each port.
At this point of Michaels talk, Someone in the audience brings up the question of the unreachability of American com- mercial 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 them- selves.
BT does the managing of routing and IBDNS and the regis- tration 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.
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 Stock- holm, 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
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.
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 cus- tomers. Meanwhile governments are trying to make the prac- tice 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 devel- opment of the IPv6 which has been designed in order to con- tain 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 glob- ally.
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 offer- ing 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 possi- bly 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 pro- viding 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 argu- ments in support of encryption, in order to organise a col- lective response.
Resp: Another delegate warned that governments would not settle for anything less than access to all encryption codes. He pro- posed 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 differ- ent 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.
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
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 modi- fied 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 meet- ing, 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 connec- tions to the LINX at lower rates than 256 kbit/s, sev- eral 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 ether- net".
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 con- trol of a single PTT and that the facility owners are not actors in the Internet service provider market.
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 connec- tions 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
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 sev- eral 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 financ- ing the interconnect capacity between the physical loca- tions 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.
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 esti- mate 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 mecha- nism 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 propaga- tion on external peers. At the time of the meeting this fea- ture was only available in "special" Cisco images, later ver- sions 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 cur- rently "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", "sec- ondary" 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 connec- tion 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.
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 typi- cally 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 partici- pants.
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 & oth- ers) 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 informa- tion (Wilfried Woeber & others) While this is true, the pages only give information on their own organisation. So an inde- pendent 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 Moscow9 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:
Additionally a further two more part-time junior hostmasters will start on 16th October:
It is estimated that by the end of the year with these addi- tional 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 con- tact 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 allo- cated 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 fin- ish updating ripe-104++ irrespective of the development of the rfc as the RIPE document is urgently required as a guide- line 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 circu- lated 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 infor- mation per registry is public information but the RIPE NCC commented that in the future they may be more active in sug- gesting, 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 volun- teers 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 docu- ment 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. Requests can be sent to . 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 organisa- tions 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 consider- ably. 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 audi- ence 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 implemen- tations (BIND prior to 4.9) as shipped my most of the ven- dors.
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 (nor- mal and reverse) and also to glue records. This leads to sit- uation 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 'john- doe.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 exist- ing 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 reliabil- ity 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 inter- vals.
During the plenary session someone remembered the existance of RFC1713 A. Romao, "Tools for DNS debugging", which is usu- ally 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]' con- taining 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 authenti- cation 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 avail- able by the end of 1995
12.3.4. Future developments of the name servers
It was reported that:
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 pres- sure 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 vol- unteered 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 bet- ter known in Europe and wants to participate in their development (see below) and immediately opened the discussion. The topics were:
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 imple- mentation 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 experi- ence 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 neces- sary to have strong authentication (or even cryptogra- phy). 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 diag- nostic tools in the PRIDE project. This effort should be extended not only on diagnose but also on tools for configu- ration 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 pro- ject 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 prior- ity, 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):
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 protec- tion 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 indi- cated 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 prior- ity 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 possi- bly 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 func- tionality 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 authentica- tion (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 accord- ingly
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, Mag- nus 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:
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: - mbone-eu-op list (full address: [email protected]) - inet-rtr:-object in the RIPE Data Base
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 avail- able.
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 avail- able 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 sta- tus 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 Mag- nus 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:
12.7. Closing
Magnus Danielson thanked all participants for their contribu- tion and closed the meeting.
12.8. Connectivity Working Group
Chair: Milan Sterba Scribe: Keith Mitchell
12.8.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.8.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.8.3. Who are the Absent ?
How do we encourage new providers to attend - discussion.
12.8.4. CDS Seminar
Connectivity Data Store - invitation to providers to add links to/from this.
12.8.5. Refocus - who we are, what we do.
Group's main important function is information exchange.
The scheduling of the next meetings was discussed and the following dates and locations were agreed:
None.
Rob Blokzijl thanked the participants for attending and NIKHEF for providing the room facilities and lunches, and declared the meeting closed.