- lir-wg - mailman.ripe.net

RE: SLA's needed !!! [2: ed. amendment]
by Wilfried Woeber, UniVie/ACOnet 01 Sep '00

01 Sep '00

On August 31 I sent a message with the following text at the beginning: >>Subj: RE: SLA's needed !!! (Was: Re: ASN wait time) > > IMHO, it's "fairly" simple to get this problem under control: > > Assumptions: > > - the RIPE NCC is working for it's members and for the common good of > the (european) Internet (providers, and thus, indiretly users). I was putting that together in a bit of a hurry, so the wording used was quite sloppy. As AMRM correctly pointed out (thanks - appreciated!), this should have read: - the RIPE NCC is working for it's members and for the common good of the "RIPE Region" Internet (providers, and thus, indirectly users). I'd also like to grab that opportunity to add that IMHO the NCC is doing very well in that respect, and that this is not an "assumption"! Apologies if I managed to mislead anyone. Regards, 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Ticket handling at the RIPE NCC
by Nurani Nimpuno 01 Sep '00

01 Sep '00

Dear all, Prior to sending a mail to the lir-wg regarding an on-going request, I would like to encourage you to check the actual status of your request. This can be done at the following URL: http://www.ripe.net/cgi-bin/rttquery The wait queue is indeed high and you may have to wait up to two weeks before an *initial* response from the hostmasters at the RIPE NCC. However, once your ticket is being processed, you normally get a reply within one working day. So if you are waiting for the reply to an on-going request for more than a couple of days, it is highly possible that the RIPE NCC has responded to your request and is waiting for additional information from you before proceeding further with the request. If you have checked the status of your request using the rttquery and you have in fact not received notification from the RIPE NCC, please do not hesitate to contact us through the <hostmaster(a)ripe.net> mailbox, including the ticket number of your on-going request. By including the ticket number of your on-going request, you will *not* be put at the bottom of the wait queue and can expect a prompt reply. I hope this clarifies how your tickets are handled by the RIPE NCC. Kind regards, Nurani Nimpuno Registration Services Manager RIPE NCC

1 0

Is this normal behaviour?
by Marco Davids 01 Sep '00

01 Sep '00

Hello, A routine check on as-macro AS-EURONET on the RIPE-database returned an unexpected result. The same check on the RADB whoisd (whois.raddb.net) however, returned the expected result together with two unexpected ones. Investigation learned us that someone deleted an unprotected as-macro on the RIPE-database. It seems it is fixed now. But what I would like to know is to what extend the several whois databases a synchronised, in other words; how reliable is the information retrieved from it? And... is the as-set object supposed to be unique or not? -- Marco Davids / SARA - Academic Computing Services Amsterdam Today's tip: ftp://ftp.ripe.net/rfc/rfc1925.txt

7 7

Re: [Robert.Kiessling@de.easynet.net: RE: SLA's needed !!!]
by Stephen Burley 01 Sep '00

01 Sep '00

Hi I think alot of what has been said hold alot of water but lets not let the ideas get lost in the frustration. If you could hold your thoughts till the RIPE meeting the LIR working group in particular, then the May17th Task Force has a presentation with suggestions we would like the communty to adopt and would really go a long to solving hte current problems. -- Regards, ------------------------------------------------------------------------ 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" ------------------------------------------------------------------------

1 0

IP allocs on the NAPs/IXs
by Berislav Todorovic 31 Aug '00

31 Aug '00

Hello, Apologies if this is a FAQ, but I really didn't find any site that contains a list of IP address allocations/assignments for various Internet exchange points worldwide. Is there any list of NAP addresses available? Such a thing would be useful to filter out leaking NAP address announcements from peers. Thanks in advance for any information! Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----

1 0

RE: SLA's needed !!! (Was: Re: ASN wait time)
by Wilfried Woeber, UniVie/ACOnet 31 Aug '00

31 Aug '00

>Subj: RE: SLA's needed !!! (Was: Re: ASN wait time) IMHO, it's "fairly" simple to get this problem under control: Assumptions: - the RIPE NCC is working for it's members and for the common good of the (european) Internet (providers, and thus, indiretly users). - RIPE and the RIPE NCC's Members define and approve (by providing the NCC's funding) the rules which govern the distribution of Internet Resources, as implemented on a day-to-day basis by the hostmasters. Requirement: (under the assumption - to be verified - that indeed there is still a performance problem at the NCC) - get the community to review the usefulness and the boundary conditions of the existing policy framework. - get the community to review the allocation of resources to the NCC to implement these policies. - get the NCC to implement an *internal* feedback loop which breaks the vicious circle of (sometimes perceived as unilaterally) tightening operational rules (with good intentions, indeed!) when the additional resources are not available to cope with the additional workload. I'd say that many (all?) of those things are being worked on already, in one way or another. Although the positive effects of those efforts might still not be obvious to the community at large... <Rant> Thinking in terms of money is not a useful approach here, for many reasons as already given during the discussion and some others, too, because what you/we (the customers) really want to obtain is _fast_ *and* _fair_ access to (sometimes perceived as limited) Internet Resources. I guess most of us are not interested in the first place to save money or to spend additional money when doing so wouldn't have any positive systematic impact on the resolution of the underlying problem... </Rant> -WW _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

RE: SLA's needed !!! (Was: Re: ASN wait time)
by Jorma Mellin 31 Aug '00

31 Aug '00

>service. So, if a LIR decides to have an SLA-bound agreement, it will pay N >times more (N may be even 10 or 20) than a standard contribution fee, but >will get guaranteed service. If RIPE NCC fails to provide service to those >registries, they would pay penalties, which would be automatically deduced >from the LIR contribution fee. > >All other registries should pay normal fees and get normal class of service >(not SLA bound, no penalties for delays etc.). I't doesn't sound too good, because in that model you can use money to obtain better service. So that model is going to hurt the LIR's who are not willing or able to pay. I know my employer can easily afford to pay to get the service we want, but somehow it doesn't sound right when we are talking about a resource (IP addr. space) what should be divided among users as equally as possible. But, if every LIR would agree to pay a small amount if service is running smoothly then we are all at the same level. And it doesn't require an application to keep track who has what SLA. So far I haven't hear a fact that the long delays are caused by lack of human resources. It has beeing an assumption so far. If it really is a manpower problem how many people we do need more and how much money it takes to hire and train them? BTW, I have handled the problem with queues so that we do not make any exact promices to our customers that they can have numbers an a given date. More or less we explain that there is a process behind all this and it is there because of a reason. 99% of them are happy with that. Problems usually start when too optimistic promices are beeing made (by someone not familiar with the process). Jorma

2 1

RE: SLA's needed !!! (Was: Re: ASN wait time)
by Jorma Mellin 31 Aug '00

31 Aug '00

>Therefore, personally, I think it's time for us to start thinking how to set >up SLA's between LIRs and RIPE NCC: let's define strict time boundaries for >the first and later hostmaster answers to an IP/AS request. It doesn't matter >whether it is 5, 7 or 14 days - but let's define them and abide by them. Also, >an escalation procedure within RIPE NCC is needed (who to contact should a >request get not processed - e.g. Registration services manager and higher), >determine what happens should RIPE NCC fail to process a request within >specified time (e.g. deduce XXX EUR from next year contribution fee for each >day of delay). That doesn't clear the problem. The lack of resources don't vanish if issues are escalated to managers and such. Or if they do vanish we have a problem with work-moral within hostmasters. There is a risk with this suggestion that service-time (SLA) would be different for different LIR's, and the LIR whose hostmaster yells out load will get serviced first. If we reduce the annual contribution fee when a request is not served within the SLA, we are only making things worse. RIPE NCC will then have even less money to correct the problem. Maybe we should try to give somekind of carrot to NCC. If IP/ASN request is served less than 5 working days give 100EUR extra contribution, if it is served in less than 2 working days give 200EUR. This is also an equal method, you cannot use money to buy SLA's. Jorma ---------------------------------------------------------- jorma.mellin(a)teliafi.net Development Manager ; CCIE#4185 Telia Finland Inc, Network Services

3 2

Re: ASN wait time
by Hank Nussbacher 31 Aug '00

31 Aug '00

At 09:04 31/08/00 +0100, Willy Calderon wrote: Yes, I got hit by this last week after having filed over 80 ASN requests with no problem. Fortunately, we require a signed fax on letterhead from the requestor stating the 2 peers as well as other details. Even so, we have had about 5 cases of organizations either never announcing the ASN or reverting to being single homed. We continue to chase after those that do not use their ASN properly and have returned a few ASN to RIPE in the past and have 2-3 in the return process now as well. I would imagine that sites that do not require a signed document from a VP level or higher from the company asking for the ASN will incur an even higher rate than the 6% we have of troublemakers. I know that RIPE has started to scan the major peering sites to see if ASNs assigned are indeed multihomed (we have been doing that for the past 2 years - on a quarterly basis for all ASN's assigned) and I guess they are finding too many not being used, so they have toughened their ASN assignment policies. ASNs are also a finite resource - just like a /19. -Hank >Good morning, > >We filed a request for an AS Number several weeks ago. Ticket number is >NCC#2000085127. Having finally receiving initial response from RIPE late >last week, we were then asked to provide contact details for the ISP that >we had placed in our application. The reason being that RIPE would be >contacting them in their time to confirm that they will accept peering and >allow our PA space. Presumably this will take another few weeks for them >to verify that indeed our application was accurate and said ISP has agreed >to accept our peering details. As this is urgent, I'm quite concerned >whether or not this is the norm now at RIPE. > >Has this happened to anyone else? That is, has their ASN application >been needlessly delayed like this? > >Thanks, > >Willy Calderon

1 0

ASN wait time
by Willy Calderon 31 Aug '00

31 Aug '00

Good morning, We filed a request for an AS Number several weeks ago. Ticket number is NCC#2000085127. Having finally receiving initial response from RIPE late last week, we were then asked to provide contact details for the ISP that we had placed in our application. The reason being that RIPE would be contacting them in their time to confirm that they will accept peering and allow our PA space. Presumably this will take another few weeks for them to verify that indeed our application was accurate and said ISP has agreed to accept our peering details. As this is urgent, I'm quite concerned whether or not this is the norm now at RIPE. Has this happened to anyone else? That is, has their ASN application been needlessly delayed like this? Thanks, Willy Calderon

2 1