From kurtis at kurtis.pp.se Sun Jun 1 19:20:14 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sun, 1 Jun 2003 19:20:14 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030529093219.GA30097@cprm.net> Message-ID: <4EEC07DB-9455-11D7-8FD0-000393A638B2@kurtis.pp.se> >>> - If the primary ISP (the one that announces the /32) dies. The site >>> is >>> dead as well. This is the #1 reason why organizations do multihome: >>> they >>> want to be up even if their primary ISP tanks. >> >> You mean if /48s where filtered? So don't filter ;-) That was the >> original idea with the proposal... >> > > You mean, ask google.com upstream provider to not filter you ? Or your > provider's provider to not filter google ? :) > Well, the entire idea was to filter at /48s. If you filter on shorter prefixes, the idea fails. Simple. - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 174 bytes Desc: not available URL: From kurtis at kurtis.pp.se Sun Jun 1 19:28:42 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sun, 1 Jun 2003 19:28:42 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <3ED6007E.79063E54@pipeline.ch> Message-ID: <7D8E3215-9456-11D7-8FD0-000393A638B2@kurtis.pp.se> > Which network engineer wants to define for each and every $forcountry > where it goes? Oh, like UUCP you mean? Maybe we could distribute maps? Wait, that is part of the idea...(although they are based on population)... On a more serious note... If the geo-based routing models could be made to work, they would be great. I am just afraid that we are lacking a lot. Experience is one thing. From the global-v6 list I learned that Michel is working with some vendor on running code for the MHAP proposal. I am really curious for how it will work out in real-life and I hope that Michel posts data once they start testing. Personally I believe more on a solution based on location/identifier separation. - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 174 bytes Desc: not available URL: From kurtis at kurtis.pp.se Sun Jun 1 19:23:34 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sun, 1 Jun 2003 19:23:34 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030529124408.A29837@bug> Message-ID: >>> So, what we really want is PI addresses. And with the current >>> pratices they >>> just do not aggregate which also is a bad thing. This is why I think >>> the >>> geographical approach already mentioned on the list (one netblock per >>> country, different sizes depending on population) currently is the >>> approach >>> which fits that need best, I believe. >> >> How do you come to that conclusion? Every other PI space will be with >> another ISP. So even thought you might have everything close together >> on a "human logic" level there is no way to aggregate the prefixes >> together in the routing system. Unless of course you want to do it >> PTT style where one is the one who routes this block. > > I think in most cases the "human logic level" also works for routing. > So > I guess many people will carry the complete routingtable for those > countries > they communicate a lot with (mostly this will be the own country and > some > nearby, but YMMV) and just have a few aggregates like "send all > traffic to > $farcountry1 to uplink A, send all for $farcountry2 via uplink B etc". ...and if you are a "Tier-1" operator that is also selling services all across the globe and use one single AS-number, you will end up having to carry all those routes anyway....and guess what, the "Tier-1"s are coming to the conclusion that routes equals state equals costs. Cost need to be recovered. I think you can work out the rest. > I think this could be a good compromise between every multihomed user > has to > be in every routing table and ongoing provider dependance. > It's a good idea, but the world doesn't really look that way. - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 174 bytes Desc: not available URL: From kurtis at kurtis.pp.se Sun Jun 1 21:42:13 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sun, 1 Jun 2003 21:42:13 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <7D8E3215-9456-11D7-8FD0-000393A638B2@kurtis.pp.se> Message-ID: <24A7C810-9469-11D7-8FD0-000393A638B2@kurtis.pp.se> On s?ndag, jun 1, 2003, at 19:28 Europe/Stockholm, Kurt Erik Lindqvist wrote: > > Oh, like UUCP you mean? Maybe we could distribute maps? Wait, that is > part of the idea...(although they are based on population)... > > Before I get shot-down over this : It's missing a ;-) at the end was intended as a joke... - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 174 bytes Desc: not available URL: From michel at arneill-py.sacramento.ca.us Mon Jun 2 00:59:48 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 1 Jun 2003 15:59:48 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5067185@server2000.arneill-py.sacramento.ca.us> > Kurt Erik Lindqvist wrote: > Personally I believe more on a solution based on > location/identifier separation. For the record, that's what MHAP is. Michel. From kurtis at kurtis.pp.se Mon Jun 2 06:53:33 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 2 Jun 2003 06:53:33 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5067185@server2000.arneill-py.sacramento.ca.us> Message-ID: <29C4983A-94B6-11D7-8FD0-000393A638B2@kurtis.pp.se> >> Personally I believe more on a solution based on >> location/identifier separation. > > For the record, that's what MHAP is. > But with Geo mapping of the location if I have understood it correctly. - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 174 bytes Desc: not available URL: From pekkas at netcore.fi Mon Jun 2 07:44:10 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 2 Jun 2003 08:44:10 +0300 (EEST) Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526185658.W67740@Space.Net> Message-ID: Ordered from the most preferable to the least preferable. On Mon, 26 May 2003, Gert Doering wrote: > [ ] something else Something else: allocate bigger chunks IANA->RIR and allocate as before. That seems pretty close to the third option. > [ ] allocate bigger chunks IANA->RIR (/8 ?) and inside those chunks, > use a binary chop algorithm similar to the one described in RIPE-261 So this is the second preference, I guess (but there is not enough detail to say whether the binary chop etc. is actually what we want.) > [ ] continue the IANA->RIR->LIR allocation as it is now Current is OK, except IANA gives way too small blocks. > [ ] accept RIPE-261 Whole 2000 seems like a lot, and I fail to see any need to lose the RIR separation here. > [ ] go for a full multi-level regional distribution, down to > "one /32 per LIR per country" (as detailed by Michael Py) This seems to have issues e.g. for multinational LIR's as well as when new countries are born and die. But maybe the issues could be worked out.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From marcelo at it.uc3m.es Mon Jun 2 11:05:49 2003 From: marcelo at it.uc3m.es (marcelo bagnulo) Date: 02 Jun 2003 11:05:49 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <29C4983A-94B6-11D7-8FD0-000393A638B2@kurtis.pp.se> References: <29C4983A-94B6-11D7-8FD0-000393A638B2@kurtis.pp.se> Message-ID: <1054544748.770.8.camel@presto.it.uc3m.es> On Mon, 2003-06-02 at 06:53, Kurt Erik Lindqvist wrote: > >> Personally I believe more on a solution based on > >> location/identifier separation. > > > > For the record, that's what MHAP is. > > > > But with Geo mapping of the location if I have understood it correctly. > As fat as i know, MHAP identifiers for small-medium sites are assigned based in geography and MHAP locators are regular PA addresses. Regards, marcelo > - kurtis - -- marcelo bagnulo uc3m From kurtis at kurtis.pp.se Mon Jun 2 12:35:10 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 2 Jun 2003 12:35:10 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <1054544748.770.8.camel@presto.it.uc3m.es> Message-ID: >>>> Personally I believe more on a solution based on >>>> location/identifier separation. >>> >>> For the record, that's what MHAP is. >>> >> >> But with Geo mapping of the location if I have understood it >> correctly. >> > > As fat as i know, MHAP identifiers for small-medium sites are assigned > based in geography and MHAP locators are regular PA addresses. > Thinking again (and not eating breakfeast at the same time), I would say you are right. But I guess Michel can sort us out? - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 174 bytes Desc: not available URL: From michel at arneill-py.sacramento.ca.us Mon Jun 2 18:25:17 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 2 Jun 2003 09:25:17 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F84B@server2000.arneill-py.sacramento.ca.us> Pekka, >> [ ] go for a full multi-level regional distribution, down to >> "one /32 per LIR per country" (as detailed by Michael Py) > Pekka Savola wrote: > This seems to have issues e.g. for multinational LIR's I was hoping someone from the very large LIRs to comment on this. > as well as when new countries are born and die. > But maybe the issues could be worked out.. There is slack space in each zone for this very purpose; some issues could not be worked out though. If China or India were to split into two equal-size countries, we would have a problem. However, short of this kind of radical change, the rest could be handled. I have inventoried the following situations: New country: ------------ Example: East Timor. What we have here is a smaller part of a larger country that splits. Should something similar happen, the way to handle it is very simple: The larger part keeps their block, we allocate a block from the slack to the newly created country; pick a RIR to have stewardship of the new country. It is obvious that renumbering will occur in the newly created country although I will point out that the kind of event that leads to this is a civil war and it is likely that the new country will want to cut ties anyway. So if Kurdistan or Cashmere were to become countries we would not have a problem. Merge: ------ Example: Germany. Countries do not die, they become part of another country or merge and yes this does happen. When it does, a choice will have to be made between the following solutions: a) A new block is allocated to the new country and the two old blocks are returned to the free pool when everyone has renumbered. b) The new country keeps the two existing blocks. The only issue doing this is that instead of a single route to the new country there needs to be two routes, which is not a big deal. c) We were clever enough to put merge candidates consecutively so we just have to extend the prefix. IMHO, a) is not going to happen so we are looking at b) and possibly c). Which means that as an enhancement we need to pair merge candidates. For example, it would be a good idea to allocate space to North and South Korea in an aggregatable fashion should they merge later (I picked this example because it has similarities with Germany). Michel. From chbm at cprm.net Mon Jun 2 18:57:01 2003 From: chbm at cprm.net (Carlos Morgado) Date: Mon, 2 Jun 2003 17:57:01 +0100 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F84B@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F504F84B@server2000.arneill-py.sacramento.ca.us> Message-ID: <20030602165701.GA20527@cprm.net> On Mon, Jun 02, 2003 at 09:25:17AM -0700, Michel Py wrote: > > IMHO, a) is not going to happen so we are looking at b) and possibly c). > > Which means that as an enhancement we need to pair merge candidates. For > example, it would be a good idea to allocate space to North and South > Korea in an aggregatable fashion should they merge later (I picked this > example because it has similarities with Germany). > Better make the whole EU aggregatable space too. cheers -- Carlos Morgado - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer. From db-news at ripe.net Wed Jun 4 11:38:32 2003 From: db-news at ripe.net (DB-News) Date: Wed, 04 Jun 2003 11:38:32 +0200 Subject: [lir-wg] Re: Improvements to database update software Message-ID: <200306040938.h549cXWq013192@birch.ripe.net> Dear Colleagues, [apologies for duplicate messages] This is to announce that the transition period for the introduction of new database update software is over. This means that the mail boxes auto-dbm-old at ripe.net and auto-dbm-new at ripe.net are not available any more and all update messages to auto-dbm at ripe.net will be processed by the new database update software. Best regards, -- Engin Gunduz RIPE NCC Database Group -- DB News wrote 23 Apr 2003: > > [apologies for duplicate messages] > > Dear Colleagues, > > The Database Group at the RIPE NCC has been working on restructuring > the dbupdate program. This is the part of the RIPE Whois server that > processes update requests from users. > > The main goal has been to improve the acknowledgement messages that > users receive from the RIPE Whois Database and provide clearer error > reporting and authorisation information. We have also been able to > make the software easier to maintain and modify. This will reduce the > time spent fixing bugs and adding new features. > > Details may be found here: > > http://www.ripe.net/db/dbupdate/ > > A page further explaining the new acknowledgements can be found here: > > http://www.ripe.net/db/dbupdate/acknowledgments.html > > The new dbupdate messages have a different format. Therefore a phased > approach to introducing the new server has been taken. For a period we > will use the new dbupdate in parallel with the old one. This will > allow people using automated tools time to update their software. > > PRE-MIGRATION > Before the new dbupdate was available. > > auto-dbm-old at ripe.net DOES NOT EXIST > auto-dbm at ripe.net --> old dbupdate > auto-dbm-new at ripe.net DOES NOT EXIST > > DAY-X, Wednesday, 23 April, 2003 > The new dbupdate is available but must be requested specifically. > > auto-dbm-old at ripe.net --> old dbupdate > auto-dbm at ripe.net --> old dbupdate > auto-dbm-new at ripe.net --> new dbupdate > > DAY-Y, Wednesday, 7 May, 2003 > The new dbupdate is the default but the old dbupdate may be requested > specifically. > > auto-dbm-old at ripe.net --> old dbupdate > auto-dbm at ripe.net --> new dbupdate > auto-dbm-new at ripe.net --> new dbupdate > > DAY-Z (POST-MIGRATION), Wednesday, 4 June, 2003 > The old dbupdate is no longer available. > > auto-dbm-old at ripe.net DOES NOT EXIST > auto-dbm at ripe.net --> new dbupdate > auto-dbm-new at ripe.net DOES NOT EXIST > > > Best regards, > > -- > Shane Kerr > Database Group > RIPE NCC From haskar at gedik.net Thu Jun 5 09:32:20 2003 From: haskar at gedik.net (A. Hakan ASKAR) Date: Thu, 5 Jun 2003 10:32:20 +0300 Subject: [lir-wg] Hi to the group Message-ID: <03b601c32b34$990f5b00$5525f4c3@elrond> Dear all ! We are an ISP operating in Turkey called Gediknet. We got some problems about managing our IP blocks. As Gediknet A.S. these ip blocks ( 195.244.32.0 - 195.244.63.255 ) are belong to us and if you look to the whois db you can see that these ip's are mnt-by your RIPE. We are trying to get an AS Number but as you can imagine we are not the mnt !. To correct this problem, what can we do ? Regards ; A. Hakan ASKAR Gediknet A.S. Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at ripe.net Thu Jun 5 12:06:56 2003 From: dominic at ripe.net (Dominic Spratley) Date: Thu, 05 Jun 2003 12:06:56 +0200 Subject: [lir-wg] Hi to the group In-Reply-To: <03b601c32b34$990f5b00$5525f4c3@elrond> Message-ID: <5.1.0.14.2.20030605120101.03a3ea20@mailhost.ripe.net> Hi Hakan, I have asked one of our Hostmasters to contact you off list to provide some assistance in resolving your problem. Regards, Dominic Spratley, RS Manager RIPE NCC At 10:32 AM 6/5/2003 +0300, you wrote: >Dear all ! > >We are an ISP operating in Turkey called Gediknet. > >We got some problems about managing our IP blocks. > >As Gediknet A.S. these ip blocks ( 195.244.32.0 - 195.244.63.255 ) are >belong to us and if you look to the whois db you can see that these ip's >are mnt-by your RIPE. > >We are trying to get an AS Number but as you can imagine we are not the mnt !. > >To correct this problem, what can we do ? > >Regards ; > >A. Hakan ASKAR >Gediknet A.S. >Manager > > > From registry at eurorings.net Thu Jun 5 09:50:06 2003 From: registry at eurorings.net (registry at eurorings.net) Date: Thu, 5 Jun 2003 09:50:06 +0200 (MET DST) Subject: [lir-wg] Hi to the group In-Reply-To: <03b601c32b34$990f5b00$5525f4c3@elrond> Message-ID: On Thu, 5 Jun 2003, A. Hakan ASKAR wrote: >> We are an ISP operating in Turkey called Gediknet. We got some problems >> about managing our IP blocks. As Gediknet A.S. these ip blocks ( >> 195.244.32.0 - 195.244.63.255 ) are belong to us and if you look to the >> whois db you can see that these ip's are mnt-by your RIPE. That's a quite normal thing - all allocation inetnums have mnt-by attribute pointing to RIPE NCC (RIPE-NCC-HM-MNT). Also, I noticed you don't have any mnt-lower attribute set, so you can create object within your allocation. Of course, to protect yourselves, setting "mnt-lower: GEDIKNET-MNT" would be probably what you should do. Write to and ask them to set this for you. Regards, Beri --------- Berislav Todorovic, Senior IP Specialist -------- ----- KPN Eurorings B.V. - IP Engineering/NOC/Support ----- ---- Telecomplein 5, 2516 CK Den Haag, NL ---- ----- Email: beri at eurorings.net <=> beri at EU.net ---- From gert at space.net Thu Jun 5 17:28:51 2003 From: gert at space.net (Gert Doering) Date: Thu, 5 Jun 2003 17:28:51 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <3ED6007E.79063E54@pipeline.ch>; from oppermann@pipeline.ch on Thu, May 29, 2003 at 02:43:42PM +0200 References: <20030527210705.S67740@Space.Net> <20030529102600.A29214@bug> <3ED5D490.669AD78@pipeline.ch> <20030529124408.A29837@bug> <3ED6007E.79063E54@pipeline.ch> Message-ID: <20030605172851.N67740@Space.Net> Hi, On Thu, May 29, 2003 at 02:43:42PM +0200, Andre Oppermann wrote: > Nope. It looks like you have never done BGP before. Until you have > got some significant experience, I'm sorry to say, you are not fully > qualified for discussion on this level. (What about me? Have a look > at AO6-RIPE, AS8271 and AS8235). I find this way of discussion not very helpful. Especially if the attacks are coming from someone who didn't bother to back any of his claims with anything but "I know better than you". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55295 (54837) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Thu Jun 5 17:34:30 2003 From: gert at space.net (Gert Doering) Date: Thu, 5 Jun 2003 17:34:30 +0200 Subject: [lir-wg] proposal: remove annyoing auto-responders from the lir-wg list? Message-ID: <20030605173430.P67740@Space.Net> Hi, let's start a second discussion... I propose that people that have broken auto-responders and respond to mailing list postings (and don't even back off, but respond to every single e-mail) are removed from the lir-wg mailing list. It's just too annoying. Comments? gert ----- Forwarded message from webmaster at keyworld.net ----- To: gert at space.net Subject: Autoreply: Re: [lir-wg] Discussion about RIPE-261 From: webmaster at keyworld.net Date: Thu, 5 Jun 2003 17:32:03 +0200 Hi, I am out of the office till the 9th of June 2003. --> If you have a technical issue please send an e-mail to support at keyworld.net. --> If you have a query on the Vegastream products please send an e-mail to sales at keyworld.net. --> If you have a query on website hosting or require changes to one currently hosted with us please contact Mr. Alton Costa on email alton at keyworld.net Thank you for choosing KeyWORLD as your communications partner. Best Regards, Christian Ransley B.Sc. Web & Technical Services Manager Keyworld Ltd. UB42, Industrial Zone San Gwann SGN 09 Tel: (+356) 2540 2540 Fax: (+356) 2540 9999 Email: webmaster at keyworld.net Website: http://www.keyworld.net ----- End forwarded message ----- Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55295 (54837) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From ncc at ripe.net Thu Jun 5 17:37:34 2003 From: ncc at ripe.net (Nick Hyrka) Date: Thu, 05 Jun 2003 17:37:34 +0200 Subject: [lir-wg] RIPE 45 Meeting Report Message-ID: <5.1.0.14.2.20030605163432.03248850@mailhost.ripe.net> (Apologies for any duplicate mails.) RIPE 45 Meeting Report Dear Colleagues: The RIPE 45 Meeting was held at the Hotel Fira Palace from 12 - 16 May 2003 in Barcelona, Spain. There were a total of 322 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, LACNIC and ICANN. HIGHLIGHTS ========== Highlights of RIPE 45 included the open discussion during the Plenary on the services of the RIPE NCC; an ICANN update by Paul Twomey, President and CEO of ICANN; the proposal to split and rename the LIR Working Group into the RIPE NCC Services Working Group and the Address Policy Working Group; the deactivation of the Tools and NetNews Working Groups; and the second phase of RIPE Meeting webcast trials. Paul Wilson, APNIC Director General, provided a presentation on RIPE 261 that proposes reorganising the distribution of IPv6 allocations "from the root" to LIRs. RIPE 261, "IPv6 Address Space Management", can be found at: ftp://ftp.ripe.net/ripe/docs/ripe-261.txt Daniel Karrenberg, Chief Scientist, RIPE NCC, spoke on the measurement activities and statistics performed by the RIPE NCC, referencing RIPE 271, "RIPE NCC Hostcount in the 21st Century". He noted the benefits and necessity of these activities and requesting support from the community. RIPE 271 can be found at: http://www.ripe.net/ripe/docs/hostcount.html "ROSIE", the RIPE On-site Information Exchange, was also launched at the meeting. ROSIE provided up-to-date meeting information and resources to RIPE Meeting attendees and will be featured again at RIPE 46. The RIPE NCC would like to thank RedIRIS, CESCA, SATEC, FocusPoint, MFN, SURFnet and NRN for the support they provided to the meeting. SUMMARY ========= LIR === - The LIR Working Group will split into two groups. The policy-making function will move to the new "Address Policy Working Group" and the RIPE NCC services reviewing function will be moved to the "RIPE NCC Services Working Group". Kurt Erik Lindqvist, Netnod CEO, has agreed to chair the new "RIPE NCC Services Working Group". The LIR WG mailing list will remain active during the transition phase. - The RIPE NCC presented its plans for improved secure communication (via X.509 PKI) with RIPE NCC members: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-lir-pki/ A discussion document has been published at: http://www.ripe.net/ripe/draft-documents/pki-20030429.html DATABASE ========= - Wilfred Woeber, UniVie-ACOnet and DB WG Chair, requested feedback from the community on changes to the "status:" attribute and their impact on scripts. - The RIPE NCC will look into the possibility of dbupdate accepting updates with the usual indentation inserted by most mail clients. - The RIPE NCC will also review a request on allowing users more access to its code. - Wilfred Woeber proposed a discussion for the DB mailing list on revising the charter for the DB Working Group. IPv6 ==== - Gert Doering, SpaceNet AG, provided a global v6 routing update noting fewer undesired prefixes leaking into the global routing tables; a decline in 6bone prefixes being routed; and a corresponding increase in RIR v6 space being routed. - John Crain, ICANN, spoke on the RIR/ICANN discussion to replace the current /23 prefix delegation procedure to facilitate automatic filtering of addresses per RIR. (See RIPE 261.) - ICANN is testing implementation of "AAAA" records in the root server system to start this summer and will produce a document in co-operation with RSSAC. Production use is pending approval by the U.S. Department of Commerce. - It was noted that the cut off date for allocating 6bone pTLAs is 1/01/2004. The phase out date of 6bone address space is 6/06/2006. - The RIPE NCC was tasked to enable IPv6 for future RIPE Meeting webcasts. ROUTING ======== - Two approaches to secure BGP were presented and discussed. Stephen Kent, Chief Scientist - Information Security at BBN Technologies, provided a presentation on how RIRs put secure BGP implementation into production: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing-sbgp/ And David Cook, CISCO, provided a presentation on soBGP: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing-sobgp-ripe/ DNR FORUM =========== - After a proposal by Rob Blokzijl, RIPE Chair, the RIPE Working Group Chairs agreed to combine future DNS WG and the DNR Forum sessions into the "DN*" Working Group, beginning at RIPE 46. DNS ==== - Presentations regarding lameness followed by a panel discussion on technical and policy issues were provided. It was noted that lameness checks, on the reverse tree in particular, might become a working group item. The discussion was moved to the DNS mailing list. TTM ==== - Daniel Karrenberg, Chief Scientist, RIPE NCC, spoke on re-focusing the measurement activities performed, and the statistics presented, by the RIPE NCC. Referencing RIPE 271, he noted the benefits of these activities and the importance for the community of access to unbiased and credible data about the overall operation of the Internet. He requested community support for this new approach to RIPE NCC measurement activities. RIPE 271 can be found at: http://www.ripe.net/ripe/docs/hostcount.html - Florian Frotzler, RIPE NCC intern, presented his thesis on the effects of IPv6. This was of special interest to those attempting to build native v6 networks: http://www.ripe.net/ttm/Documents/Various/ffrotzler.pdf TECHSEC ======== - A discussion on draft-ietf-dnsop-interim-signed-root-01.txt was held. Comments are to be posted to the DNSEXT mailing list. - A status update on DISI (Deployment of Internet Security Infrastructures) was provided: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-techsec-disi/ ANTI-SPAM ========== - Unsolicited Broadcast E-mail (UBE) volume greatly increased in the last three months with ISPs expecting the UBE load to become a serious technical problem for them by the end of 2003. - The working group was tasked to develop a "best practice advice" on defensive measures against UBE. EIX === - It was noted that the EIX Working Group session at RIPE 46 will be in two parts: The first session will be orientated towards ISPs with a series of presentations from IXPs discussing recent trends and statistics in a regular format. The second session will focus on IXPs with presentations on technical, operational and commercial issues that affect IXPs in the RIPE community. EOF ==== - The European Operators Forum convened Monday and Tuesday at RIPE 45. Emphasis was on inter-domain routing and BGP security. A discussion on how to develop the EOF from its current state at future RIPE Meetings was also held. TUTORIALS ========= - The RIPE NCC staff presented the RIPE NCC IP Request Tutorial. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/ripe-45/tutorials/ip-tutorial/ - A tutorial on the "myAS" system, which allows users to devise a control/notification system for BGP route propagation in real-time, was provided at RIPE 45: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-tt-myas/ RIPE MEETING WEBCASTING ======================= - The second phase of RIPE Meeting webcasting trials was held at RIPE 45. Recordings of sessions have been archived and can be accessed at: http://www.ripe.net/ripe/meetings/ripe-45/webcast-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) ==================================== - The RIPE NCC Hostmaster Centre was open during RIPE 45. The centre continues to be a useful facility for the meeting attendees and will be provided at RIPE 46. Later consultation hours were successfully introduced at RIPE 45 and will be repeated at RIPE 46. "MEET & GREET" ============== - The RIPE NCC's "Meet & Greet" desk was available for first time RIPE Meeting attendees at RIPE 45. "Meet & Greet" was introduced at RIPE 44 and introduces newcomers to the meetings, to key attendees of the RIPE community and to social events throughout the week. RIPE 45 REFERENCE PAGE ====================== - A complete list of RIPE 45 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-45/index.html RIPE 46 ====== - RIPE 46 will be held in Amsterdam, the Netherlands from 1 to 5 September 2003. Information on RIPE 46 will be made available later this month at: http://www.ripe.net/ripe/meetings/ripe-46/ RIPE NCC GENERAL MEETING ======================== - The RIPE NCC Executive Board has announced that the 2003 annual General Meeting will be held adjacent to the RIPE 46 Meeting in Amsterdam from 14.00 to 17.00 on Friday, 5 September 2003. For more information about RIPE NCC annual General Meetings, please see: http://www.ripe.net/ripencc/about/gm/ New Local Internet Registries (LIRs) please note: - LIRs who signed up in 2002 are entitled to two (2) free tickets to attend RIPE 46. The tickets cover registration only and do not apply to the RIPE dinner, your travel or hotel accommodations. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/ripe-45/new-lir.html Or contact . END From randy at psg.com Thu Jun 5 18:47:31 2003 From: randy at psg.com (Randy Bush) Date: Thu, 5 Jun 2003 12:47:31 -0400 Subject: [lir-wg] proposal: remove annyoing auto-responders from the lir-wg list? References: <20030605173430.P67740@Space.Net> Message-ID: > I propose that people that have broken auto-responders and respond to > mailing list postings (and don't even back off, but respond to every > single e-mail) are removed from the lir-wg mailing list. yep From randy at psg.com Thu Jun 5 18:52:56 2003 From: randy at psg.com (Randy Bush) Date: Thu, 5 Jun 2003 12:52:56 -0400 Subject: [lir-wg] proposal: remove annyoing auto-responders from the lir-wg list? References: <20030605173430.P67740@Space.Net> Message-ID: >> I propose that people that have broken auto-responders and respond to >> mailing list postings (and don't even back off, but respond to every >> single e-mail) are removed from the lir-wg mailing list. > yep sigh! randy --- Date: Thu, 5 Jun 2003 18:48:11 +0200 (CEST) From: SYMPA To: randy at psg.com Subject: Your message to ncs has been rejected Your message for list ncs has been rejected. The message is thus sent back to you. Your message : Received: from alquanto.nextra.it (alquanto.nextra.it [193.43.2.90]) by magari.nextra.it (8.11.4/8.11.4/NETTuno 6.0) with ESMTP id h55Gm6m85944 for ; Thu, 5 Jun 2003 18:48:06 +0200 (CEST) (envelope-from lir-wg-admin at ripe.net) Received: from postboy.ripe.net (postboy.ripe.net [193.0.0.201]) by alquanto.nextra.it (8.9.3/8.9.3/NETTuno 5.0) with ESMTP id SAA03456 for ; Thu, 5 Jun 2003 18:48:05 +0200 (MET DST) Received: from postboy.ripe.net (localhost [127.0.0.1]) by postboy.ripe.net (Postfix) with ESMTP id 0B2396A0FA; Thu, 5 Jun 2003 18:48:02 +0200 (CEST) Delivered-To: lir-wg at lists.ripe.net Received: by postboy.ripe.net (Postfix, from userid 8) id 697126A0FA; Thu, 5 Jun 2003 18:47:35 +0200 (CEST) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by postboy.ripe.net (Postfix) with ESMTP id 5DDC36A0C7 for ; Thu, 5 Jun 2003 18:47:35 +0200 (CEST) Received: by postman.ripe.net (Postfix, from userid 8) id 2A8934E0AC; Thu, 5 Jun 2003 18:47:35 +0200 (CEST) Received: from psg.com (psg.com [147.28.0.62]) by postman.ripe.net (Postfix) with ESMTP id CEC6D4E05B for ; Thu, 5 Jun 2003 18:47:34 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Nxtl-0000lA-00; Thu, 05 Jun 2003 16:47:34 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19Nxtk-0003bn-2R; Thu, 05 Jun 2003 12:47:32 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 5 Jun 2003 12:47:31 -0400 To: Gert Doering Cc: lir-wg at ripe.net Subject: Re: [lir-wg] proposal: remove annyoing auto-responders from the lir-wg list? References: <20030605173430.P67740 at Space.Net> Message-Id: X-RIPE-Spam-Level: X-RIPE-Signature: 817f82ae3c4a5410def48dbd557b1690 Sender: lir-wg-admin at ripe.net Errors-To: lir-wg-admin at ripe.net X-BeenThere: lir-wg at ripe.net X-Mailman-Version: 2.0.13 Precedence: bulk List-Id: RIPE Local IR Working Group List-Post: X-RIPE-Lists: RIPE Local IR Working Group List-Subscribe: , List-Unsubscribe: , List-Help: > I propose that people that have broken auto-responders and respond to > mailing list postings (and don't even back off, but respond to every > single e-mail) are removed from the lir-wg mailing list. yep From randy at psg.com Thu Jun 5 18:53:27 2003 From: randy at psg.com (Randy Bush) Date: Thu, 5 Jun 2003 12:53:27 -0400 Subject: [lir-wg] proposal: remove annyoing auto-responders from the lir-wg list? References: <20030605173430.P67740@Space.Net> Message-ID: To: randy at psg.com Subject: Autoreply: Re: [lir-wg] proposal: remove annyoing auto-responders from the lir-wg list? From: webmaster at keyworld.net Date: Thu, 5 Jun 2003 18:51:03 +0200 Hi, I am out of the office till the 9th of June 2003. --> If you have a technical issue please send an e-mail to support at keyworld.net. --> If you have a query on the Vegastream products please send an e-mail to sales at keyworld.net. --> If you have a query on website hosting or require changes to one currently hosted with us please contact Mr. Alton Costa on email alton at keyworld.net Thank you for choosing KeyWORLD as your communications partner. Best Regards, Christian Ransley B.Sc. Web & Technical Services Manager Keyworld Ltd. UB42, Industrial Zone San Gwann SGN 09 Tel: (+356) 2540 2540 Fax: (+356) 2540 9999 Email: webmaster at keyworld.net Website: http://www.keyworld.net From michel at arneill-py.sacramento.ca.us Fri Jun 6 04:24:30 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 5 Jun 2003 19:24:30 -0700 Subject: [lir-wg] proposal: remove annyoing auto-responders from the lir-wg list? Message-ID: <963621801C6D3E4A9CF454A1972AE8F50671AA@server2000.arneill-py.sacramento.ca.us> > Gert Doering wrote: > I propose that people that have broken auto-responders and > respond to mailing list postings (and don't even back off, > but respond to every single e-mail) are removed from the > lir-wg mailing list. It's just too annoying. > Comments? Very good idea IMHO. I think that bouncing one time for each source address is acceptable, but not every email. Michel. From leo at ripe.net Fri Jun 6 09:48:07 2003 From: leo at ripe.net (leo vegoda) Date: Fri, 6 Jun 2003 09:48:07 +0200 Subject: [lir-wg] Hi to the group In-Reply-To: References: <03b601c32b34$990f5b00$5525f4c3@elrond> Message-ID: Hi all, registry at eurorings.net writes: >On Thu, 5 Jun 2003, A. Hakan ASKAR wrote: > >>> We are an ISP operating in Turkey called Gediknet. We got some problems >>> about managing our IP blocks. As Gediknet A.S. these ip blocks ( >>> 195.244.32.0 - 195.244.63.255 ) are belong to us and if you look to the >>> whois db you can see that these ip's are mnt-by your RIPE. > >That's a quite normal thing - all allocation inetnums have mnt-by attribute >pointing to RIPE NCC (RIPE-NCC-HM-MNT). > >Also, I noticed you don't have any mnt-lower attribute set, so you can >create object within your allocation. Of course, to protect yourselves, >setting "mnt-lower: GEDIKNET-MNT" would be probably what you should do. >Write to and ask them to set this for you. Actually, it is possible to set this and change most of attributes in an allocation via the Allocation Editor in the LIR Portal. Regards, -- leo vegoda RIPE NCC Registration Services From mk at e-lectron.de Thu Jun 5 19:12:05 2003 From: mk at e-lectron.de (Matthias Kluth) Date: Thu, 05 Jun 2003 19:12:05 +0200 Subject: [lir-wg] proposal: remove annyoing auto-responders from the lir-wg list? In-Reply-To: <20030605173430.P67740@Space.Net> References: <20030605173430.P67740@Space.Net> Message-ID: <3EDF79E5.4070704@e-lectron.de> Hi Gert, Gert Doering wrote: > I propose that people that have broken auto-responders and respond to > mailing list postings (and don't even back off, but respond to every > single e-mail) are removed from the lir-wg mailing list. > > It's just too annoying. Yeah, you're right. Let's kick them. Kind regards. Matthias Kluth From pim at bit.nl Fri Jun 6 11:03:50 2003 From: pim at bit.nl (Pim van Pelt) Date: Fri, 6 Jun 2003 11:03:50 +0200 Subject: [lir-wg] proposal: remove annyoing auto-responders from the lir-wg list? In-Reply-To: <20030605173430.P67740@Space.Net> References: <20030605173430.P67740@Space.Net> Message-ID: <20030606090349.GA90607@crow.bit.nl> On Thu, Jun 05, 2003 at 05:34:30PM +0200, Gert Doering wrote: | Hi, | | let's start a second discussion... | | I propose that people that have broken auto-responders and respond to | mailing list postings (and don't even back off, but respond to every | single e-mail) are removed from the lir-wg mailing list. I second that motion. And for what its worth, I would like it to happen on every mailing list. groet, Pim -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From slz at baycix.de Fri Jun 6 11:11:32 2003 From: slz at baycix.de (Sascha Lenz) Date: Fri, 6 Jun 2003 11:11:32 +0200 Subject: [lir-wg] proposal: remove annyoing auto-responders from the lir-wg list? In-Reply-To: <20030606090349.GA90607@crow.bit.nl>; from pim@bit.nl on Fri, Jun 06, 2003 at 11:03:50AM +0200 References: <20030605173430.P67740@Space.Net> <20030606090349.GA90607@crow.bit.nl> Message-ID: <20030606111132.B32323@mama.baycix.de> Hay, On Fri, Jun 06, 2003 at 11:03:50AM +0200, Pim van Pelt wrote: > On Thu, Jun 05, 2003 at 05:34:30PM +0200, Gert Doering wrote: > | Hi, > | > | let's start a second discussion... > | > | I propose that people that have broken auto-responders and respond to > | mailing list postings (and don't even back off, but respond to every > | single e-mail) are removed from the lir-wg mailing list. > I second that motion. And for what its worth, I would like it to happen > on every mailing list. actually, i don't even see the point for a discussion here - i rather think this is a standard procedure for every serious mailinglist. "just do it" - on every list. The Listmanager shouldn't forget to inform the poor little person about unsubscribing him/her though. Might just be an accident, people get forced to use such things like auto-responders from time to time and have no control about what it does :-} One can re-subscribe at any time after (s)he fixed the "little problem". -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================== From gert at space.net Fri Jun 6 11:13:57 2003 From: gert at space.net (Gert Doering) Date: Fri, 6 Jun 2003 11:13:57 +0200 Subject: [lir-wg] proposal: remove annyoing auto-responders from the lir-wg list? In-Reply-To: <20030606090349.GA90607@crow.bit.nl>; from pim@bit.nl on Fri, Jun 06, 2003 at 11:03:50AM +0200 References: <20030605173430.P67740@Space.Net> <20030606090349.GA90607@crow.bit.nl> Message-ID: <20030606111357.Z67740@Space.Net> Hi, On Fri, Jun 06, 2003 at 11:03:50AM +0200, Pim van Pelt wrote: > And for what its worth, I would like it to happen > on every mailing list. While I second that, it's up to the individual list owners / chairpeople to decide for the other lists... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55295 (54837) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From zsako at banknet.net Fri Jun 6 12:17:51 2003 From: zsako at banknet.net (Janos Zsako) Date: Fri, 6 Jun 2003 12:17:51 +0200 (MET DST) Subject: [lir-wg] proposal: remove annyoing auto-responders from the lir-wg list? Message-ID: <200306061017.h56AHpj4001535@banknet.banknet.net> > From lir-wg-admin at ripe.net Fri Jun 6 11:14:14 2003 Dear all, I second the automatic deletion from the lir-wg list of the subscribers who set up broken auto-responders (i.e. Gert's original proposal). As the list is open to anyone as far as I know, i.e. the subscription is automatic, and does not need an authorization from a human, I see no harm in deleting such subscribers (I guess they would get a notification of the termination of the subscription anyway - otherwise I recommend to send one). Once deleted from the list, when they come back from the pleasant vacation they can on one hand re-subscribe if they wish and they can check the list archives for mail they may have missed. > On Fri, Jun 06, 2003 at 11:03:50AM +0200, Pim van Pelt wrote: > > And for what its worth, I would like it to happen > > on every mailing list. > > While I second that, it's up to the individual list owners / chairpeople > to decide for the other lists... Yes, I second this too. Of course, Gert is right, and the list owners should probably base their decision on the above (i.e. availability of archives, automatic subscription, notification upon deletion). Janos From libdanz at hotmail.com Tue Jun 10 19:33:42 2003 From: libdanz at hotmail.com (Liberty Dandira) Date: Tue, 10 Jun 2003 10:33:42 -0700 Subject: [lir-wg] 80.x.x.x cannot resolve .zw addresses Message-ID: <000601c32f76$70b607d0$5a00a8c0@breeze1> The webserver on this IP is refusing to talk, but the DNS is proper... I suspect they have set an IP thats on a local area network, typical for Windows 2000 or NT. Liberty Dandira (Msc.) Harare -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at ripe.net Tue Jun 24 17:01:02 2003 From: nick at ripe.net (Nick Hyrka) Date: Tue, 24 Jun 2003 17:01:02 +0200 Subject: [lir-wg] [aso-announce] Call comments on draft ASO documents Message-ID: <5.1.0.14.2.20030624164332.06cebf58@mailhost.ripe.net> [apologies for any duplicate mails.] Dear Colleagues, The ASO Secretariat has announced the following call for comments: Greetings. The Address Supporting Organization (ASO) is pleased to call for public comments on the following draft documents: * Procedures for the election of AC Chair and Co-Chairs (draft) - This draft document defines the role of ASO Address Council (AC) Chairs and Co-Chairs describes the process of electing individuals to serve in these roles. - http://www.aso.icann.org/docs/chair-selection-draft20030510.html * ASO-AC ICANN Board Selection Procedures (draft) - This draft document describes the procedures and criteria the AC should adopt in selecting individuals to serve on the ICANN Board of Directors. - http://www.aso.icann.org/docs/bod-selection-draft20030424.html * ASO Roadmap 2003 (draft) - This draft document sets out the proposed work plan for the AC in 2003. - http://www.aso.icann.org/docs/roadmap-2003.html If you have any comments or questions on any of these documents, please direct them to the aso-policy mailing list. For subscription details, please refer to: http://www.aso.icann.org/lists/ Kind regards - ASO Secretariat -- * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-announce * -- Nick Hyrka RIPE NCC Communications Manager From leo at ripe.net Tue Jun 24 19:38:50 2003 From: leo at ripe.net (leo vegoda) Date: Tue, 24 Jun 2003 19:38:50 +0200 Subject: [lir-wg] AfriNIC Announces Decision On Host Country Proposals Message-ID: <20030624173850.GA26623@ripe.net> Dear Colleagues, The following announcement was released by the AfriNIC Board of Trustees. Best regards, -- leo vegoda RIPE NCC Registration Services Manager ------------------------------------------------------------------------- Announcement by the AfriNIC BOT Concerning AfriNIC Host Country Proposals ------------------------------------------------------------------------- ------------------ Date: 23 June 2003 ------------------ 1. There was a call for proposals in terms of the hosting proposal document as published on the AfriNIC web site. The BOT received 5 proposals 2 of which were received after the deadline. All the proposals were accepted by the AfriNIC BoT. The proposals are published at http://www.afrinic.org/AfriNIC-Hosting-Proposals.shtml 2. AfriNIC held a public meeting in Kampala on 15 June 2003, where the host country proposals were presented. 3. Having heard the proposals that Board requested that at closed meeting be held to find a consensus on the matter between interested parties. The following were present at that meeting; * Board Members including Nii Quaynor, Richard Bell, Charles Musisi, Theo Kramer and Alan Barrett. * Members Of The Working Group from Montevideo including Sunday Folayan, Brian Longwe, and Anthony Brooks. * Representatives of Host Country Bidders - including representatives from Ghana, Uganda, Kenya, South Africa, and Mauritius. 4. Those present were are able to agree on the following consensus. As with all compromises the solution did not meet 100% of everyone's expectations, however it was agreed that all parties present found the proposal to be an acceptable and workable one. Notwithstanding the need for cost control and operational efficiency, it was decided that the operational functions of AfriNIC could be effectively divided as follows; a. Administrative Centre. Including legal incorporation, business manager, and, secretariat. b. Training Centre. To co-ordinate and implement all the training activities for AfriNIC. c. Technical Operations Centre. Including hardware & infrastructure facilities. d. Back Up & Disaster Recovery Facility for Technical Operations. 5. The consensus was to allocate these functions as follows: a. Administrative Centre - Mauritius b. Training Centre - Ghana c. Technical Operations Centre - South Africa d. Back Up & Disaster Recovery Centre - Egypt 6. It was agreed that the board should issue revised terms of reference for each of the functionalities so that the successful bidders in each section could produce detailed implementation plans and finalize funding for their respective areas of responsibility. These revised TORs would be discussed with bidders. 7. Subsequent to the Kampala meeting, the AfriNIC Board of Trustees has unanimously voted to ratify the the consensus proposal from the Kampala meeting as described above. Whatever our collective interests and reservations, consensus requires compromise. We have a workable proposal on the table with consensus from the majority of interested parties. That proposal has been ratified by the board and we take this opportunity to inform the community at large of the board's decision. It is our sincere hope that the process will now begin to progress rapidly and we thank the community for their continued support. Yours sincerely, The AfriNIC Board of Trustees From ripe-ml-2003 at ssd.axu.tm Wed Jun 25 05:39:08 2003 From: ripe-ml-2003 at ssd.axu.tm (Aleksi Suhonen) Date: Wed, 25 Jun 2003 06:39:08 +0300 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <3ED22BB6.5F9BF632@pipeline.ch> References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> <3ED2109C.CB625692@pipeline.ch> <20030526154228.L67740@Space.Net> Message-ID: <20030625033909.851DE1A21D@tikka.axu.tm> Hello, I know I'm responding to an old email, but I can't resist pointing out a small but common fallacy here: Quote from Andre Oppermann: } In 1993 I was the } proud owner of a i386sx16MHz PC with 1MB of RAM. Today I've got two } GB of RAM in the very PC I'm writing this email on. What the heck, } I've could even stick four GB in there, it's only EUR320 nowadays. } About the price of an average high level 3d graphics card for gaming. Routers -- and especially L3-switch-routers -- tend to use content addressable memory (CAM) or other such specialized architectures instead of dynamic random access memory (DRAM) to store the forwarding table on NICs. The production numbers of DRAM chips are orders of magnitude larger than those of CAM chips, and the gap is getting bigger. These technologies are also way more complex than DRAM to begin with. This means that the same amount of memory takes up a lot more silicon real estate which is exponentially relative to chip cost. Using just DRAM is not an option either because you cannot build the whole Internet on small-to-medium size routers with slow line cards. Some operators will always outgrow them and those operators will be the ones who in the end dictate how things are done. This doesn't actually have anything to do with my personal view on routing table growth. I'm just saying that there is a real technical reason to be worried about it. CAMs (et al.) are getting larger every year of course but, to the best of my knowledge, they are not doubling in size every year as per Moore's law. To quote Frederick Brooks, I don't think there will be a silver bullet to this problem. -- Aleksi Suhonen / Axu TM Oy Internetworking Consulting From michel at arneill-py.sacramento.ca.us Wed Jun 25 05:51:07 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 24 Jun 2003 20:51:07 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F8E1@server2000.arneill-py.sacramento.ca.us> Aleksi, Agree with your posting below, which is one of the reasons vendors of geeky hardware have stated that they can't guarantee they'll continue to ride Moore's law (one of the other reasons being that the problem of routing table growth tends to switch from memory/cpu usage to protocol stability issues). > These technologies are also way more complex than DRAM > to begin with. No argument here. Put a DRAM wafer and a CAM wafer side-by-side under a microscope and you'll immediately realize this. Michel. > Aleksi Suhonen wrote: Routers -- and especially L3-switch-routers -- tend to use content addressable memory (CAM) or other such specialized architectures instead of dynamic random access memory (DRAM) to store the forwarding table on NICs. The production numbers of DRAM chips are orders of magnitude larger than those of CAM chips, and the gap is getting bigger. These technologies are also way more complex than DRAM to begin with. This means that the same amount of memory takes up a lot more silicon real estate which is exponentially relative to chip cost. Using just DRAM is not an option either because you cannot build the whole Internet on small-to-medium size routers with slow line cards. Some operators will always outgrow them and those operators will be the ones who in the end dictate how things are done. This doesn't actually have anything to do with my personal view on routing table growth. I'm just saying that there is a real technical reason to be worried about it. CAMs (et al.) are getting larger every year of course but, to the best of my knowledge, they are not doubling in size every year as per Moore's law. To quote Frederick Brooks, I don't think there will be a silver bullet to this problem. From hpholen at tiscali.com Mon Jun 30 19:22:05 2003 From: hpholen at tiscali.com (Hans Petter Holen) Date: Mon, 30 Jun 2003 19:22:05 +0200 Subject: [lir-wg] Request for contributions Message-ID: <001601c33f2c$20b57660$050b2f0a@no.tiscali.com> Dear Colleagues, The next meeting of this Working Group will be held in Amsterdam during RIPE 46: RIPE 46 1 - 5 September 2003 Amsterdam, The Netherlands The scope of these meetings is the open discussion of the addressing policies for the RIPE region. We request your proposals for discussion topics at this next WG meeting. Topics for discussion should be within the WG's remit of addressing policy for the RIPE region. It is worth making clear that this working group is an open forum and is NOT restricted to RIPE NCC members. Any person from the RIPE community that is interested in the activities of the WG is welcome to contribute with these suggestions. Some of the topics that are still ongoing discussions originated on previous WG meetings are: - Review of the PI assignment policy - Review of the IPv6 allocation and assignment policy - Discussion on IPv6 Address Space Management The proposals should be submitted to the WG public mailing list: If you need more information, please contact one of the chair/co-chairs - Hans Petter Holen (Chair) - Gert D?ring (Co-chair) - Andrea Borgato (Co-chair) Sincerely Hans Petter Holen WG Chair