March 2001 - lir-wg - mailman.ripe.net

New Proposal
by Stephen Burley 29 Mar '01

29 Mar '01

Hi I would like to here your comments on the following proposal. After being in an audit and getting a list as long as my arm of broken objects in the DB it turned out that the majority of the objects where pre RIPE and not subject to the same checks. I therefore propose that all inetnums without a status (being pre-RIPE there is no status) should be marked with a new status of PR (Pre RIPE) and therefore be ignored by an audit tool. Also all other objects prior to ripe should be flagged so as to be ingnored in an audit, making it much easier to see what really needs fixing. Your thoughts and comments please. -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life [SB855-RIPE] if you're stupid and willing to wait" ------------------------------------------------------------------------

5 5

Re: New Proposal
by Janos Zsako 29 Mar '01

29 Mar '01

> From owner-lir-wg(a)ripe.net Thu Mar 29 16:39:45 2001 > To: Janos Zsako <zsako(a)banknet.net> Stephen, > > I am just wondering whether "no status" really means "pre RIPE". > > I suspect it is not the case, as Daniel's document was discussed > > on the mailing list in May 1995 (and is dated 30 June 0995), while > > RIPE NCC did perform allocations much earlier as far as I remember. > > But in a classful enviroment. Correct. > > So my point is that the term "pre RIPE" may be misleading. > > > > What about "status: UK"? (UK for UnKnown :)) ) > > UK = United Kingdom Sure, this is why I put the smiley there. > What about CA = Classful Allocation Yes, this may be the right term, although it is not strictly related to this (if inetnum has status attribute it does not mean it is a classless allocation or assignment as classful allocations and assignments continued for another year or so after ripe-127 was published). "No status" means pre-ripe-136, dated May 1996 (as this is the document that made the status attribute mandatory) and classless assignments did start only after ripe-136 indeed, as far as I remember. Janos

1 0

Routing Workshop
by RIPE NCC Staff 29 Mar '01

29 Mar '01

CALL FOR APPLICATIONS Routing Workshop, Amsterdam, The Netherlands, 7-11 May 2001 Dear Colleagues, A Routing Workshop will be provided for RIPE NCC staff on 7-11 May 2001 in Amsterdam, The Netherlands by Cisco Systems. This is a call for applications for 14 places still available in the workshop. This workshop will be provided free of charge and includes lunches. PLEASE NOTE: Travel and accommodation are not provided or reimbursed. Who should Attend: The target audience for this course is persons in the ISP community with a basic familiarity of Cisco Systems equipment. This is a technical workshop and most suitable for those persons who are now or will soon be building or operating a wide area TCP/IP base Internet Service Provider (ISP) network or Internet eXchange Point (IXP) with international and/or multi-provider connectivity. Prerequisites: Cisco IOS fundamentals; user level UNIX and possibly some system administration and; some use of network design, preferably TCP/IP based. * Preference for this course will be given to those individuals that come from developing countries (i.e. Central Europe, Central Asia, Africa and The Middle East) Cisco Systems will select 14 participants to attend the tutorial based on the information provided in the application form enclosed below. WORKSHOP SCOPE: --------------- - Techniques for design, set-up, and operation of a metropolitan, regional or national ISP backbone network. This includes advanced OSPF, BGP4 and policy based routing. - IOS Essentials every ISP should be doing. The hidden secrets that all key NSPs have been using for years but not telling anyone (ie: competitive advantage. - Techniques for multiple connections to the Internet (multihoming), including connections to IXPs, NSP and transoceanic Internet links. - Techniques for the design, set-up and operation of a metropolitan, regional or national IXPs - Techniques to achieve optimal performance and configuration from a Cisco backbone router. This includes routing scalability, network design and configuration techniques. - Examples from a case study from successful ISPs who are making use of many of the workshop techniques. COURSE LOCATION: --------------- The course will take place at The Groot Industrieele Club, Dam 27, Amsterdam, The Netherlands The instructors for the Workshop will be Philip Smith and Duncan Rogerson. IMPORTANT DATES: --------------- * The deadline for application submissions: 11 April 2001. * Acceptance notification to selected candidates: 16 April 2001 * Routing Workshop - 7-11 May 2001 For further information about the Cisco ISP workshop please contact: Joao Silva Damas Chief Technical Officer RIPE NCC E-mail: joao(a)ripe.net ====== ROUTING WORKSHOP - APPLICATION FORM * Please submit your application form by email to <joao(a)ripe.net> with the following text as the subject: Routing Workshop First Name: Last Name: Nationality: Contact Information: - postal address: - Tel/Fax number: - email address: CV detailing ISP experience [max 200 words]: ======

1 0

IMPT
by Guy Vegoda 22 Mar '01

22 Mar '01

OK, lets get this IP tool sorted out quicky. I'm gonna set a deadline of Friday 30th of March for anyone who cares to send in their minimal requirements. After this, we will move on to specification for exactly two weeks. At the end of this period, those who wish to volunteer to do any coding will have a window to do so, and within this group, dicussions about implimentation will begin. Sorry if this seems a little bossy; it is. I just know that unless somebody gives it a kick start, this thing will fade into oblivion. There's no reason why it should do this as it could be so good. I am officially asking Mal to please repost the current requirements back up on this list. All those who would like to change, insert or delete a requirement, can then email with their changes. If you want something in, say so, and why, explicitly.. If you just say "Well, it might be nice if...", then it wont get stuck in. We need concrete, minimal requirements, that the working group can vote on. Hope this sparks some interest, Looking forward to hearing from people, Thanks everyone very much, Guy -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

1 0

FW: LIR Registration
by Tramnitz＠t-online.de 20 Mar '01

20 Mar '01

I sent the mail below to ncc(a)ripe.net and didnt get an answer up to now, so I'm wondering if anyone in this list may help or could give us some notes. tia >>>>>>>>>>>>>>>>>>>>>>>> Dear Ladies and Gentlemen, we plan to become LIR in the very near future and have some questions concerning registration and status issues. Currently we deploy VPN-connections over WANs and the internet for customers, including centralized internet-gateway and hosting services. As we grow, the needs of our customers grow exponentially, forcing us to provide redundant internet-access at our internet-gateway and hosting location here in Berlin. For this need, we plan to connect to (in the first step) two upstream providers and get an fully internet-routable addressblock. As you state in Ripe-Document 142 the use of PI-address-space in an AS would be suitable for this, but as you say in the same document you do not guarentee the ability to route this address-space in the whole internet. But exactly this guarantee is what we need to provide our customers the service-level-agreements they expect. So we can't only use this PI-address-space but instead become LIR and get our own allocated address space in an order of magnitude that is routed in the internet. Our question is now, what is the real difference between enterprise LIR and small provider LIR? We do not plan to assign customers address-space besides RFC1819 nets for LAN-2-LAN connections through VPNs but only assign addresses for hosting, housing and VPN-Connections through the internet. The second question is, if we would get *at all* an addressblock /19 if we cant show up a plan that we will use an certain amount of this address in e.g. 48 months which will be true in our current considerations. Sincerely, Christian Tramnitz

2 1

Re: IP Management Tool - Minimum Requirements
by Guy Vegoda 06 Mar '01

06 Mar '01

> Would there not be intellectual property difficulties if you > wrote a similar system for another company? > > Niall > > (Interested but also enmeshed in IP problems) I guess that depends on how similar you mean by similar (-: I don't think IPMT will be anything like Robo-Bijal, code-wise. (Not least because: (1) I will not be the only coder, (2) Manuel's IP libraries are open source, (3) It will probably support IPv6, which Robo-Bijal doesn't, and (4) I would like to do it in OO perl. ) So should hopefully all work out. Guy -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

2 1

RIPE RPSL transition date set!
by SchmitzJo＠aol.com 05 Mar '01

05 Mar '01

Hello all, following up on our last call for comments on the RPSL transition for the RIPE database, we did not receive any mails or information which may have delayed the transition. In contrast, we received a set of supportive mails. Accordingly, the transition to RPSL will now follow the outlined dates: o 23-Apr-2001: switching to the RPSL database *** now set *** - All objects are automatically converted to RPSL format - Queries return RPSL only - Mirroring follows new format and rules at whois.ripe.net, port 4444 - RPSL formatted updates can be submitted to auto-rpsl(a)ripe.net - RIPE-181 updates are still accepted at auto-dbm(a)ripe.net, but are autmatically converted to RPSL - RFC2725 (Routing Policy Security System) rules apply throughout o 14-May-2001: exchanging mail addresses for submitting RIPE181 and RPSL-formatted updates - auto-dbm(a)ripe.net only accepts RPSL updates - RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL (again, RFC2725 rules apply here as well) o 15-Oct-2001: RIPE-181 updates are no longer accepted For further reading, please refer to the migration web page http://www.ripe.net/rpsl We will continue to update you prior to the dates detailed above. Thanks - the RIPE NCC and the chairmen of Routing: Joachim Schmitz DB: Wilfried Woeber LIR: Hans Peter Holen

1 1

Re: Refuse een assignment because it 'cannot' be routed?
by Wilfried Woeber, UniVie/ACOnet 05 Mar '01

05 Mar '01

To continue that (cute | silly | pick-your-choice) analogy... => I only want a fixed frontdoor (1 fixed IP address), but I am trying to force => my landlord into letting me have it without paying tripple rent, by asking => the government (RIPE) to give me a building permission to install more => doors. Not because I want more doors, but to keep the landlord from moving => my single door every day :) => = =Hi, = = Hmm... this analogy isn't correct. RIPE is not the government in this. =RIPE, or your local LIR can give you a door (address assignment), but =you still need to get a permit from the local counsil to place it =(Getting your service provider to actually route it). = =One of the things your local LIR may require before selling you a door =is having a permit. Buying the door somewhere else (RIPE) does not =automagically entitle you to a permit. ...what we are seeing in reality, though, is something like the "government" (the RIPE NCC) coming back with a question about the colour and style of the door. And - depending on your answer - either going ahead issuing a _permanent_ permit for e.g. an Ethernet- or leased-line-style door ("static"), but limiting the validity of the permit for an xDSL- style or dial-up door to as long as you, or someone from your family, happens stay at home ("dynamic"). As soon as you go to work, or even worse - take a couple of days off, duhh!!! - you have to submit another application for installing a door. And, the "government", suggests to the manufaturers of the doors (and/or to the landlord), to give you a call on the phone every, say, 8 hours, to confirm that you haven't left for shopping (physicly) or turned to RTFM (virtually/mentally logging off). That's exactly what happens to me, back home, with my ADSL link being dropped every 8 hours by the ISP *on purpose*, because the NCC sort of "suggests" to the ISPs to use dial-up ratio mechanisms for 24x7 xDSL, flat rate billing. Very clever, indeed, in particular when someone tries to do stuff that is security-aware. But I have beaten that one to death before (technology independence of assignment rules). Sigh... Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Träume darf man nicht verbieten, sonst werden sie Wirklichkeit...

3 3

Re: RIPE: last call for comments RPSL transition
by SchmitzJo＠aol.com 02 Mar '01

02 Mar '01

Dear Christian, you wrote: > well I'd say go for it. Thank you for your support. > But let me kindly ask for the following thingies: > > since the RIPE-NCC is now in charge of the maintenance of the RAtoolset > please make sure that there's a release available (specifically > RTconfig) which is fully compatible with the RIPE RPSL server by mid of > March 2001 latest. I believe that this request is more than legitimate, and that the NCC is hearing you very well - after all it is in all our interest to have this running. > > It appears that this might be available already (since Feb20 ?), > however, the link to > > "RtConfig Patch for the RAToolSet" of the "RPSL Migration" homepage is > broken. This is currently worked on, as I hear. > > In addition, any clear links to concise How2do documents on RAToolSet > and RtConfig would be appreciated. On the one hand, I think the best source for that still is http://www.isi.edu/ra/RAToolSet/ On the other hand, we will have a tutorial on the RAToolSet during RIPE39. This has been confirmed by now, and I believe that additional documentation will become available around it. Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

Re: RIPE: last call for comments RPSL transition
by SchmitzJo＠aol.com 02 Mar '01

02 Mar '01

Dear Ping Lu, you wrote: > We had a lively discussion about the RPSL transition during the RIPE-38 > meeting. This is correct, and I very much appreciate the input you provided during our joint working group session. > Well, if we can't fight them then the best thing to do is to join them. Do I need to be worried now? I never considered this to be a fight ;-) > With the company's support behind us, we (Cable & Wireless Global) as a > legacy LIR (used to be MCI) > would like to work with RIPE to help the RPSL transition. > > CW will adopt a similar schedule as RIPE's to transform our Routing Registry > into the new RPSL format. > This will probably make all the mirroring LIRs' job much easier and > hopefully all the downstream ISPs happier (only the RPSL format to deal > with). > > So GO FOR IT. I welcome your approval. I believe I do not exaggerate stating that you can count on the support from the RIPE community and the NCC in particular in the transition effort. Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0