December 1996 - ripe-list - mailman.ripe.net

RIPE Meeting 26
by John LeRoy Crain 30 Dec '96

30 Dec '96

Dear Colleagues, Seasons greetings.. This is a short note to inform you about the upcoming RIPE meeting. The meeting will be held at the Nikhef building in Amsterdam from Monday January 20th to Wednesday January 22nd 1997. Unlike previous RIPE meetings there will be a participation fee payable by attendees. The exact details of this will be published with the official announcement in the begining of January. For those who wish to attend the RIPE meeting who will need a visa we would advise that you begin these procedures as soon as possible. The RIPE NCC will be able to send invitations on request to those requiring them. Kind regards, John Crain RIPE NCC

1 0

TF-CACHE: Next meeting - 23rd Jan 1997
by John Martin 23 Dec '96

23 Dec '96

All, As agreed in our last meeting, the next meeting of the caching task force will be on Thursday 23rd January 1997 at the TERENA Secretariat in Amsterdam. This is immediately following the RIPE meeting (also in Amsterdam between 20-22 Jan - see www.ripe.net for details). I will prepare a tentative agenda with Ingrid and send it out approximately two weeks before the meeting. As our meeting facilities are somewhat limited, I'd be grateful if you could respond to this message and let me know if you plan to attend - attendance is open to all but should numbers demand, we will have to limit attendance to one person per network operator. I look forward to seeing you in January - have a great Christmas and a happy New Year. Regards, John

1 0

SIRCE to be awarded to DANTE and UKERNA
by Daniel Karrenberg 20 Dec '96

20 Dec '96

Dear colleagues, we have just learned that the SIRCE pilot will be awarded to DANTE and UKERNA. For details see included message. It also contains contact information for those interested. Seasons greetings Daniel ------- Forwarded Message Date: Fri, 20 Dec 1996 13:26:33 +0100 From: Josefien.Bersee(a)dante.org.uk (Josefien Bersee) Sender: neworg-ga-request(a)terena.nl To: terena-ga(a)terena.nl, M2107(a)eurokom.ie, ceec(a)terena.nl, wg-all@terena. nl Subject: The Works of DANTE, No.18 _____________________________________________________________________ * * A bi-monthly electronic news bulletin * * reporting on the activities of DANTE, * the company that organises international * network services for the European THE WORKS OF D A N T E research community. No.18, December 1996 Editor: Josefien Bersee _____________________________________________________________________ DANTE/UKERNA PARTNERSHIP TO SET UP SIRCE SERVICE The TERENA Executive Committee has announced its intention to award the set-up of a pilot European Security Incident Response Coordination Service to a partnership consisting of DANTE and UKERNA. UKERNA is the UK organisation responsible for the operation and development of JANET and SuperJANET. The establishment of a European Security Incident Response Coordination Service was discussed and requested by the European IRTs (Incident Response Teams) to solve a number of coordination problems. These include dependence of European IRTs on the US funded CERT/CC, as well as those arising from cultural, legal and language differences, and different time zones. In consultation with its CERT Task Force, the TERENA Executive Committee set up a Technical Advisory Group (TAG) to advise TERENA on a suitable organization to lead a two and a half year pilot service. At the beginning of October 1996, TERENA issued a call for proposals to a limited number of organisations for the operation of the SIRCE (Security Incident Response Coordination for Europe) pilot. DANTE and UKERNA decided to respond to the call by establishing a partnership which brings together the complementary skills of the two organisations. UKERNA has the technical expertise of the well- established JANET-CERT, while DANTE has the commercial and administrative experience in the management of coordinated pan- European services. The pilot service is planned to be launched in the first quarter of 1997. DANTE and UKERNA, in consultation with TERENA, will immediately start preparing the service implementation, one element of which is the drafting of a detailed service specification. As required in the specification of the TERENA CERT Task Force the service will develop gradually. In the initial phase a coordination function will be offered, which includes organisation of meetings, help for the establishment of new IRTs, and the provision of information services. In the second phase of the pilot incident coordination will be included, and SIRCE will be involved in the process of responding to individual incidents. After the pilot phase it is intended that an operational service will provide full incident coordination, 24 hours/7 days a week. ... * * * * * * * and of course to all of you... * * * * * A VERY GOOD CHRISTMAS BREAK AND BEST WISHES FOR 1997! * * * * * ___________________________________________________________________ DANTE Tel +44 1223 302992 Francis House Fax +44 1223 303005 112 Hills Road E-mail dante(a)dante.org.uk Cambridge CB2 1PQ WWW http://www.dante.net ___________________________________________________________________ ------- End of Forwarded Message

1 0

APRICOT '97
by David R. Conrad 17 Dec '96

17 Dec '96

Hi, Apologies if inappropriate -- this is just to fill you in on some action in the "other" region, should you be interested. The Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT, http://www.apricot.net) is a conference and series of tutorials targetted primarily at people who run (or plan to run) large networks, particularly Internet Service Providers. This year, there are 13 tutorials ranging from DNS to Perl Programming and a 3 track conference consisting of 2 two day tracks on network operations and services & applications, and 2 one day tracks, one on legal and policy issues in cooperation with the Asia Pacific Policy and Legal (APPLe) Forum and the other, the Business of the Internet, in cooperation with the Asia Pacific Internet Association (APIA). For more information on the conference program and the tutorials, see http://www.apricot.net/program.html. To register for the conference, see the APRICOT registration page at http://www.apricot.net/registration.html (note that the web page uses SSL for secure transfers so you can safely send your credit card numbers over the Internet). If you do not have access to the web, please contact me and I'll send or fax an email form. Dates: APRICOT Tutorials: Jan 27 - 28 APRICOT Conference: Jan 29 - 30 APNIC Meeting: Jan 31 Fees: Conference Registration: US $275 Tutorials: US $275/tutorial If you have any questions, feel free to contact me or the organizing committee (apricot-oc(a)apricot.net) Regards, -drc

1 0

Re: Very fast IP, no ATM...
by Peter Lothberg 09 Dec '96

09 Dec '96

> Peter Lothberg writes: > > > > I don't undertsand, if ATM did create bandwith it would be great, but > > it does not. If ATM was needed to make packets move it would be great, > > but it's not. > > One issue on the above is that the ATM pipes have the history of going > a step faster than the wide area IP pipes at the same time. Like we're > now at STM4 for ATM and at STM1 for IP. Though this does not help too > much with the current routing gear, but at least you can feed your > backbone with a stack of STM1 ATM interfaces and actually move bits at > aggregate rates that go STM4 if not faster (I can put multiple STM4 > pipes in parallel in the backbone). 1. You need routers in and out of your cloud if your service is IP. STM-4 (packets) as router interfaces will be availiable when needed. > > It seems to be usable as aa replacement for X.25 and Frame-Relay, for > > those who buy bandwith and routers and build private networks, but, > > for a public infrastructure, I don't think so. > > > A close look at the Internet market shows a large set of products > aimed, in a way or another, for 'secure transmission of data over the > Internet'. Either terminal-connections, like SSH, or VPN's. I see that > as a clear demand for VPN services, at least for the area where > bandwidth is inexpensive and plenty. Like in our case in Finland and > Sweden. It does not take that much our of your pocket to pay the cell > tax if the amount you start from is not large. (remember this when you > fill in your tax forms, the "best way" to save in taxes is to earn > less :-) Cell-tax chart. POSIP ATM ether ip MAX POSIP SPE MAX cells ATM SPE size size POSIP goodput eff ATM per goodput eff (Bytes) (Bytes) pps (MB/sec) (%) pps packet (MB/sec) (%) ------ ------ ------- ---------- ---- ------- ---- ---------- ---- 64 46 353,207 16.2475 86.79 176,603 2 8.1237 43.39 128 110 160,000 17.6000 94.02 117,735 3 12.9509 69.18 256 238 76,408 18.1851 97.14 58,867 6 14.0103 74.84 512 494 37,365 18.4583 98.60 32,109 11 15.8618 84.73 1024 1006 18,479 18.5899 99.30 16,054 22 16.1503 86.27 1518 1500 12,422 18.6330 99.54 11,037 32 16.5555 88.44 (2048) 2030 9,189 18.6537 99.65 8,214 43 16.6744 89.07 (4352) 4334 4,312 18.6882 99.83 3,881 91 16.8202 89.85 (4488) 4470 4,181 18.6890 99.83 3,757 94 16.7938 89.71 Remember thaat long-haul bandwidth is a very scarse resource att the rate it will be consumed. > > As the service deleiverd at the endpoint is IP, we need to > > interconnect the various parts of IP moving clouds, so we will have to > > have IP-switches (called routers) that go damn fast anyway. > > > Definetly we do. The problem here is that we're a generation away from > routers that would go STM4. And maybe generation and half away from > routers that would maintain fairness and maybe even QoS across them at > the same time they go STM4 on a dozen interfaces. Go read the latest issues of the trade-press like communications week. > > So, explain what's the problem here, I just demostrated that you can > > run production IP traffic at 155Mbit without making a detour through > > an ATM switch. > > > Where the current POS pipe is, is a perfect place for 'ATM-less' > circuit. When you say that you're going to do the next circuit > locally, that makes me wonder of the benefits. If you would run the > STM4 halfway across the globe, I would understand the benefits of > being free of cell tax. It will take until 1998 before there will be cablesystsems along the path that can give me a oc12c/stm-4, but we will have inside Sweden. > > It has been more stable than any other international circiut we have, > > and the 'new' technology works great. > > > On which of the submarine cables it runs on, btw? tat12/13, rioja, odin, denmark, se-dk-17. --Peter

2 1

another correction :-( for .fr this time)
by Mirjam Kuehne 09 Dec '96

09 Dec '96

Hi all, This wasn't my month really: I have to send you another update, this time for .fr: CY SOA COUNTED DUPL REAL CHANGE ============================================================ fr 5601 230882 7874 223008 -4176 This changes the total figures to: ============================================================ 136510 3686719 248429 3438290 +85584 I have adjusted the files on the ftp site to reflect this change. Please not that I did not incorporate the corrected data for the UK from October (see my previous message) in the table. This would give a wrong picture of the growth. However, as announced in my previous mail, you can find the correct output and error files for the UK from October at the usual place (ftp://ftp.ripe.net/ripe/hostcount/) I am sorry for the confusion. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Re: Very fast IP, no ATM...
by Peter Lothberg 09 Dec '96

09 Dec '96

> Could anybody help me a bit with SONET/SDH technology: > what is the present state of - say STM4c vs STM4 etc.- > standardization. I think you are mixing Sonet and SDH terminology here, both SDH and Sonet are vell standardized upto 622. Speed SDH Sonet ----------------------------------------- 155M STM-1 OC3c 622M STM-4 OC12c > At Stuttgart we run some 20km dark fibre driven by FORE`s > ATM/STM4c boards (NEC SX4 32 - Cray T3E 512) - would > we buy e.g. NORTEL SDH equipment if this would be - > say 100km - and what about public European SDH? I can't answer, as you mix names. But, for the two speeds mentioned above, both Sonet and SDH transport equipment could be configured to carry either of. The tricky part is how to configure protection, and that's the same for both Sonet and SDH. > How is vBNS going to upgrade to 622Mbit/s ? (Not my department) but I think they use ATM switches. > What does the the below "Cisco's Native IP over SDH/VC4" > exactly say? Read the RFC on PPP over Sonet, but here is how it's stuffed into a container, and note I don't do PPP on the link we talked about, just cisco HDLC. |<--------------------------------------------------270 Bytes-------->| |<--------------9 Bytes------------>|<1B>|<---------260 Bytes-------->| -- +---------------------------------------------------------------------+ | A1| A1| A1| A2| A2| A2| J0| Z0| Z0||J1|| | |-----------------------------------||--|| + SOH | B1| | | E1| | | F1| | ||B3|| | +-----------------------------------||--|| HDLC byte stuffed + | D1| | | D2| | | D3| | ||C2|| inserted here | -- +-----------------------------------||--|| + -- +-----------------------------------||--|| Synchronous Payload + Point| H1| H1| H1| H2| H2| H2| H3| H3| H3||G1|| Envelope (SPE) | -- +-----------------------------------||--|| + -- +-----------------------------------||--|| + | B2| B2| B2| K1| | | K2| | ||F2|| ----------------------------||--|| + | D4| | | D5| | | D6| | ||H4|| | +-----------------------------------||--|| + LOH | D7| | | D8| | | D9| | ||Z3|| | +-----------------------------------||--|| + |D10| | |D11| | |D12| | ||Z4|| | +-----------------------------------||--|| + | S1| Z1| Z1| Z2| Z2| M1| E2| | ||Z5|| | -- +---------------------------------------------------------------------+ --Peter

1 0

SIRCE Developments (long)
by Daniel Karrenberg 09 Dec '96

09 Dec '96

Dear contributors, dear colleagues, the final state of commitments on December 2nd was just short of ECU 40k coming from 44 sources. Thank you all! Organisation name Person commit (ECU) pi.se AB Pontus Ekman 1000 ACONET Wilfried Woeber 1000 RedIRIS-CSIC Victor Castelo 1000 Academic Computer Centre, CYFRONET-KRAKO Karol Franczak 500 IPGlobal, Informatica e Telecomunicacoes Pedro Ramalho Carlos 500 Teleport C&S GmbH. Christoph Maerk 500 BT Public Internet Service Nigel Roy Titley 1000 Tele Greenland Michael Schultz 1000 SpaceNet GmbH Sebastian v. Bomhard 750 Unisource Business Networks Italy Mauro Magrassi 1000 Sontheimer Datentechnik GmbH Bernd Sontheimer 500 ECRC GmbH Dave Morton 1000 Tele2/SWIPnet Jorgen Ericsson 1000 Nacamar Klaus Landefeld 1000 SIBS - Sociedade Interbancaria de Servic Jose Eduardo Pina Mi 1000 LITNET Daiva Tamulioniene 500 INRIA Annie Renard 500 EUnet Communications Services BV Per Gregers Bilse 1500 HogiaNet Kenneth Hybner 1000 AT&T Internet Services Tankut Turhan, Henk 1000 CESNET Pavel Vachek 500 OTEnet S.A. Theodore Thanopoulos 1000 HEAnet John Hayden 1000 U-NET Limited Stuart Muckley 500 Telia AB J=F6rgen I Larsson 1000 GTN Andreas Baess 1000 INS GmbH Andreas Frackowiak 1000 NASK - Research and Academic Network in Krzysztof Silicki 500 Xlink Michael Rotert 1000 Entreprise des Postes et Telecommunicati Thierry Coutelier 500 HPT - Croatian Post and Telecomm, Teleco Ivan Sedinic 1000 Unisource Business Networks (Schweiz) AG Philip Bridge 1000 Clinet Heikki Suonsivu 1000 InComA Ltd. Gregory Dmitriev 1000 Internet ProLink Mickey Coggins 500 MAZ Internet Services Rainer Lillge 1000 IFS Daniel David 1000 Unisource Business Networks NL bv Rob Reitsma 1000 Global One Sweden Eric Malmstrom 1000 LF.net GmbH i.G. Kurt Jaeger 500 NLnet Services bv Aris Doelman 1000 Transpac France/Global One Bernard Malaval 2000 I.NET S.p.A Marco Negri 1000 Telecom Finland Pasi-Mikko Rautanen 1000 ----- Total: 39250 ===== This represents just 10% of the current contributors and about a quarter of the amount we considered necessary to justify the project as proposed in ripe-150. From this we have to conclude that at this time there is not enough interest in the service among our current constituency to justify such an ambitious pilot service carried out at the RIPE NCC. I have therefore withdrawn the NCC's proposal. Obviously there is some disappointment because we would have liked to do the job. On the other hand I am quite happy that we did not embark on this project with very short preparation only to find out then that the support was less than expected. We will let you know when TERENA has decided about the award of the SIRCE project. You can then consider supporting the particular effort TERENA will select. I'd also like to thank the 51 people who responded to the questionnaire. Here are the results: n % 51 100 Total 47 92 STI likes that NCC asks feedback this way 46 90 ST9 We are satisfied with current NCC services 44 86 STG questionanaire easy to understand 35 69 STA RIPE should start security coord WG 35 69 ST4 have looked at ripe-150 (proposal) 26 51 ST6 not enough time to consider 22 43 ST5 should have been discussed at RIPE meeting 11 22 STB do not contribute because too vague 11 22 ST2 SIRCE needed in a couple of years 9 18 STF TERENA involvement makes it too complicated 9 18 STE do not contribute because too expensive 7 14 STD do not contribute because we do not need it 6 12 STJ do not contribute until selctin process complete 4 8 ST1 SIRCE not needed at this time 3 6 STC do not contribute because NCC not the right place 3 6 ST8 NCC should not start new services 3 6 ST7 NCC should not do incident coordination 0 0 STH questionnaire took too much time 0 0 ST3 SIRCE not useful at all This further supports that the SIRCE service is currently not perceived as very urgent by many ISPs but that it may become more important in the future. A clear lesson I personally have learned from this is that the consensus building process within RIPE and the NCC contributors committee is a delicate one which takes time and careful consideration by all concerned. It is a good process which has served us very well so far. I will take great care to respect it better than I did in this particular matter. The NCC team and I will now do our best to increase the number of you who are saisfied with our current services from a good 90% to as near to 100% as we can make it. Regards D. Karrenberg

1 0

Re: Very fast IP, no ATM...
by huitema＠bellcore.com 05 Dec '96

05 Dec '96

Paul, You asked me to repeat that: if not the telephone system itself- would Christian prepare an analysis saying "a Internet of `appropriate` capacity with RSVP and IPng would allow for concurrent AUDIO (as Jon said) of phone quality for everybody ..." The only problem I have with this phrase is the mention of RSVP. I don't think there is actually any major problem for providing a best effort service dimensioned to fit the needs of 600Mio internauts (or 6 billions, for that matter). I am convinced that some policing will be needed to make sure that usage is proportionate to investments (and subscription rates). I am however definitely not convinced that RSVP is what we need there. RSVP is about giving special priviledges to a few flows; we need to provision sufficient resources so that the average flow has adequate capacity, which is a different problem. -- Christian Huitema

2 1

corrected UK figures for October
by Mirjam Kuehne 04 Dec '96

04 Dec '96

Dear all, I forgot to send the updated figures for the October count for the UK. The decrease of hosts that we saw in October was probably due to problems reaching the other TLD UK domains while the hostcount was running. The count was then repeated on Tue, 12 Nov 96 and showed the follwoing results: CY SOA COUNTED DUPL REAL CHANGE ============================================================ "wrong" count for October: uk 31468 697703 98605 599098 -49118 updated count for October: uk 32567 796010 101282 694728 +46512 Please note that this also changes the CHANGE column for the UK for November: uk 34363 815905 106068 709837 +15109 I copied the updated version of the UK hostcount to ftp://ftp.ripe.net/ripe/hostcount/uk.{output,error}-Oct.gz Kind Regards, Mirjam Kuehne RIPE NCC

1 0