Re: [lir-wg] AS Number Policy - continued
Not really important, but just to avoid being counted as agreeing :-)
Anyway, I think that everyone have suggested to do both with a OR in between.
...no objection against the OR, but the result of the OR should not be the _only_ input to a decision process. It would be an efficient mechanism to be used _in support_ of continued AS# holdership, though.
Basically just claiming that "yes I do peer at backwater-IX with Farm-IP and Countryside Networks and I don't get transit from anywhere" should not be enouhg.
I disagree.
RIPE should be able to verify that this is true.
Some nit-picking... RIPE (the community): I don't think so - other than having access to some publicly accessible documentation, e.g. in the Routing Registry. The NCC: maybe, if and when we can agree on the criteria, and the cost for verification vs. the result.
- kurtis -
Wilfried.
Not really important, but just to avoid being counted as agreeing :-)
Horrible thought? :)
Anyway, I think that everyone have suggested to do both with a OR in between.
...no objection against the OR, but the result of the OR should not be the _only_ input to a decision process. It would be an efficient mechanism to be used _in support_ of continued AS# holdership, though.
Agreed. OTH, this discussion to me was for new AS assignments that are not yet used. Which is somewhat easier to deal with than with existing AS:es. AS286 beeing an example that is announced but the question is if we can consider it "as in use" ?
Basically just claiming that "yes I do peer at backwater-IX with Farm-IP and Countryside Networks and I don't get transit from anywhere" should not be enouhg.
I disagree.
I read this as you mean that RIPE NCC shoudl trust the word of the AS number holder?
RIPE should be able to verify that this is true.
Some nit-picking...
RIPE (the community): I don't think so - other than having access to some publicly accessible documentation, e.g. in the Routing Registry.
My mistake. I ment the RIPE NCC.
The NCC: maybe, if and when we can agree on the criteria, and the cost for verification vs. the result.
Well, if we consider the RIPE db OR announced (or both - which is what it is supposed to be if the latter is true) it's not that hard. First, a requirement to register the AS number policy to keep it would be a easy task. Basically RIPE could then check assigned AS:es to registred. Still, the object does not have to be upto-date or actually reflecting anything. Second, as I belive there is so few assigned AS:es that never make it to the global routing tabele, I would like to define a few points of checks. These could even be route servers and this could be included in the automation. It could also be from the view of the test-traffic boxes. Best regards, - kurtis -
On Fri, 2 Aug 2002, Kurt Erik Lindqvist wrote:
Agreed. OTH, this discussion to me was for new AS assignments that are not yet used. Which is somewhat easier to deal with than with existing AS:es. AS286 beeing an example that is announced but the question is if we can consider it "as in use" ?
Yes. If it appears in your BGP tables it is in use. We cannot go and look deeper. Many more cases of ASNs appearing in the RIPE DB and not appearing in any BGP announcement for the past year. Easy targets - no complications.
- kurtis -
Hank
look deeper. Many more cases of ASNs appearing in the RIPE DB and not appearing in any BGP announcement for the past year. Easy targets - no complications.
It would be really interesting to be able to get a full report of a full bgp table match against the RIPE db and see how many there really are and, try and dig into why. Hmm, Jhma, now that you are at RIPE NCC....couldn't we have the routing analasys pages extended?..:) - kurtis -
On Fri, 2 Aug 2002, Kurt Erik Lindqvist wrote:
look deeper.Many more cases of ASNs appearing in the RIPE DB and not appearing in any BGP announcement for the past year.Easy targets - no complications.
It would be really interesting to be able to get a full report of a full bgp table match against the RIPE db and see how many there really are and, try and dig into why.
Start with: http://www.ris.ripe.net/cgi-bin/asinuse.cgi and select 3 months. -Hank
Hmm, Jhma, now that you are at RIPE NCC....couldn't we have the routing analasys pages extended?..:)
- kurtis -
Start with: http://www.ris.ripe.net/cgi-bin/asinuse.cgi and select 3 months.
Are you suggesting that RIPE use this tool and have it updated to include 6 months or even 1 year? Tanya
On Fri, 2 Aug 2002, Tanya Hinman wrote: Imagine an automated RIPE process that cycles thru all allocated RIPE ASNs, checks RIS and sends out emails to the mntner and to the LIR that requested the ASN.
Start with: http://www.ris.ripe.net/cgi-bin/asinuse.cgi and select 3 months.
Are you suggesting that RIPE use this tool and have it updated to include 6 months or even 1 year?
Tanya
Hank Nussbacher
--On Friday, August 02, 2002 18:39:39 +0300 Hank Nussbacher <hank@att.net.il> wrote:
Start with: http://www.ris.ripe.net/cgi-bin/asinuse.cgi and select 3 months.
This is not really what I had in mind though. I wanted a listing of AS:es assigned, but not in the routing table. Here I already need to know the AS number. But yes, it's the starting point. Best regards, - kurtis -
On Fri, 2 Aug 2002, Kurt Erik Lindqvist wrote:
--On Friday, August 02, 2002 18:39:39 +0300 Hank Nussbacher <hank@att.net.il> wrote:
This is not really what I had in mind though. I wanted a listing of AS:es assigned, but not in the routing table. Here I already need to know the AS number. But yes, it's the starting point.
Interested parties may find the files in ftp://ftp.ripe.net/ripe/stats/ to be useful. Regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security
Hello all, some of you asked for numbers, here are some: I wrote a little script on the weekend, which looks for unused and singlehomed ASs within the routing tables of some specified routers. I gave it our routers and some public route servers/looking glasses and it produced the following results (which should be treated as figures, not as absolut and correct numbers!): ASs allocated to RIPE: 6016 ASs unassigned: 616 ASs singlehomed: 224 ASs unused: 1526 I used data from saturday and today. I'll be happy to send the script to everyone who requests (via PM, please!) and I'ld also give my result files to NCC. MfG / Regards, S.Willing, mopSys GmbH ************************************************************************ mopSys GmbH Sebastian Willing http://www.mops.net Technical director Telefon: 05139/9813-11 e-Mail: s.willing@mops.net Telefax: 05139/9813-13 Webspace ab 2,5 EUR: http://www.ciz.de/ ************************************************************************
--On Monday, August 05, 2002 14:52:13 +0200 Sebastian Willing <s.willing@mops.net> wrote:
ASs allocated to RIPE: 6016 ASs unassigned: 616 ASs singlehomed: 224 ASs unused: 1526
Sebastian, this is a good excersie! However, if we really have 25% of the AS:es assigned to RIPE not visible in the Global routing table, I think we have a problem.... - kurtis -
Kurt, Kurt Erik Lindqvist wrote:
--On Monday, August 05, 2002 14:52:13 +0200 Sebastian Willing <s.willing@mops.net> wrote:
ASs allocated to RIPE: 6016 ASs unassigned: 616 ASs singlehomed: 224 ASs unused: 1526
Sebastian, this is a good excersie!
However, if we really have 25% of the AS:es assigned to RIPE not visible in the Global routing table, I think we have a problem....
I used limited data for the analysis. I think, if we could incorperate information from some EP's route servers, the results would change. If someone could/would like to send me a full "sh ip bgp paths" - log from an EP's route server, I'ld be happy to re-run the analysis and post the updated numbers. AND: I collected the data only two times with only two or three days difference. If RIPE would run the tool regulary (each week or so) on their routers and some route-servers of EP's (no need to make them public, just give RIPE some kind of very limited access), we'ld have better results. But I still think, we'ld be over 1000 unused ASs, and I don't think, that many of them are younger than a year. MfG / Regards, S.Willing, mopSys GmbH ************************************************************************ mopSys GmbH Sebastian Willing http://www.mops.net Technical director Telefon: 05139/9813-11 e-Mail: s.willing@mops.net Telefax: 05139/9813-13 Webspace ab 2,5 EUR: http://www.ciz.de/ ************************************************************************
Sebastian,
<s.willing@mops.net> wrote:
ASs allocated to RIPE: 6016 ASs unassigned: 616 ASs singlehomed: 224 ASs unused: 1526
If RIPE would run the tool regulary (each week or so) on their routers and some route-servers of EP's (no need to make them public, just give RIPE some kind of very limited access), we'ld have better results.
We already have similar numbers online: http://www.ris.ripe.net/as-stat/ These show the number of AS's seen by sites peering with one of the RRC's of the RIS project, split out by month and by registry. The data doesn't change that much, so running this once a month is sufficient. What we want to do is to add a list showing the individual AS's, registries and number of peers for all AS's assigned to the RIPE NCC. If you look at over the last 7 months: the number of AS's increased by about 2000 (12000 in January, 14000 now), while at the same time the percentage of single-homed AS's dropped from 50% to 40%. I'll show plots of both at RIPE43. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) NOTE: My email address (and a hole in our mailing list software) is being abused by a spammer. We are working on fixing this hole and tracking the spammer down. If you receive mail from "henk@ripe.net" that is obviously spam, please send me a copy of the mail including ALL headers. I'm sorry for any inconvenience caused by this.
At 03:17 PM 05-08-02 +0200, Kurt Erik Lindqvist wrote:
--On Monday, August 05, 2002 14:52:13 +0200 Sebastian Willing <s.willing@mops.net> wrote:
ASs allocated to RIPE: 6016 ASs unassigned: 616 ASs singlehomed: 224 ASs unused: 1526
Sebastian, this is a good excersie!
However, if we really have 25% of the AS:es assigned to RIPE not visible in the Global routing table, I think we have a problem....
As someone who actively goes after unused ASNs as well as single-homed ASNs, I would say the toughest problem is RIPE itself. Here are some examples: --------------------------------------------------------- Example #1: ASN returned 2/2001 and not reused. It took a few emails on my part to "convince" RIPE to reuse it, as they did finally in 6/2002:
Dear Hank
We have taken AS8885 back, however we cannot re-assign it as it is referenced in another object in the RIPE Database.
There is no reason that that entry be in the database since Doarnet has not existed for the past 2 years and I doubt they have paid their RIPE dues for the past 2 years. Proof: they no longer are listed as a member: http://www.ripe.net/ripencc/mem-services/general/indices/IL.html
What procedures does RIPE use to reclaim IP address space that has been assigned and no longer is used?
-Hank
Incidentally, they reclaimed the ASN from this bankrupt ISP but have not yet reclaimed the IP address space from this defunct ISP: inetnum: 212.77.128.0 - 212.77.129.255 netname: DOARNET-IL descr: DoarNet Internal Net. country: IL admin-c: SP401 tech-c: SP401 rev-srv: dns.doar.net rev-srv: dns2.doar.net status: ASSIGNED PA notify: shai@consonet.com mnt-by: DRNT-SP changed: shai@consonet.com 19990201 source: RIPE ----------------------------------------------------- Example #2: ASN removed by one hostmaster and reassigned to a new organization and then along comes another hostmaster and does:
Thanks for your message about the deleted and unused AS number AS6875.
Unfortunately, we cannot return it to the pool of unused AS numbers at this time because it still has one peer.
Here is the data from http://www.ris.ripe.net/cgi-bin/asinuse.cgi=20
full url below:
(http://www.ris.ripe.net/cgi-bin/asinuse.cgi?as=3DAS6875&display=3Dpeer&int= erval=3Done&outype=3Dhtml&.submit=3DSubmit)
"AS6875 was last announced on Thu Jul 18 16:37:57 2002 (UTC). 1 peer are fo= und for AS6875.
Neighbor of 6875 Last Seen AS Path 9004 Thu Jul 18 16:37:57 2002 13129 8220 12761 9004 6875"
Do you know anything about this?
I had to go explain that AS6875 was already returned, reassigned and has already established a new peer session with AS9004. ------------------------------------------------- Example #3: Company owning the ASN is bought out, no longer needs the ASN, but it is protected via "auth:" with one of email|crypt-pw|md5 which is no longer known. This then requires for written hardcopy, quoting from hostmaster:
Changing the authorisation of a maintainer object means changing sensitive user data. In cases when our manual intervention is necessary we require written hardcopy confirmation from the maintainer's admin-c which serves as a form of authentication and authorisation for the change.
So before we can change your maintainer for you please send us a fax stating the reason for the change and full text of the old and then new object. The fax should be on the headed paper of your company, signed by the admin-c of the object ...
I was lucky to find someone in the new company who joined in the email ping-pong marathon with RIPE, typed up the letter on company letterhead, faxed it to RIPE (4x until RIPE accepted it), and then finally I was able to change the entry and then delete it. And I was lucky on that one. If the company had gone bankrupt or just shutdown, and the autnum entry were "auth" protected, and there would be no "admin-c" to speak to, I do not know what RIPE would end up doing. You really see LIRs investing a few hours of work every time they try to be "good to the Internet" to return a defunct ASN and battle with RIPE hostmasters every step of the way? My experience is that returning things to RIPE is just as hard as trying to get a /16 for a new ISP :-). So Kurt, you are absolutely right that "we have a problem" with 25% unused RIPE assigned ASNs. -Hank
- kurtis -
My experience is that returning things to RIPE is just as hard as trying to get a /16 for a new ISP :-). So Kurt, you are absolutely right that "we have a problem" with 25% unused RIPE assigned ASNs.
Yes, I agree. Perhaps we could have a discussion around this added to the agenda of the next LIR-WG meeting? Hans-Petter? - kurtis -
Hello, On Mon, 5 Aug 2002 14:52:13 +0200 (CEST), Sebastian Willing wrote:
ASs allocated to RIPE: 6016 ASs unassigned: 616 ASs singlehomed: 224 ASs unused: 1526 Good peace of work, interesting ...
This statistics shows that the typical problem case isn't a singlehomed ASn, it's just an *unused at all* ASn. Thus it seems it isn't necessary to establish a big buerocracy with forms to be signed etc. (like we German tend to do ;-|, its just sufficient to validate their use in the global table and/or view peer/upstream AS references (listing in as-set or aut-num object of partner) corresponding to the ASn in the RIPE database. IMHO this should give a large yield (1500+x) with little effort and covers most "I am $BIGCOMPANY and need a ASn because its rare and for free" cases. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
On Fri, Aug 02, 2002 at 02:45:45PM +0200, Kurt Erik Lindqvist wrote:
Well, if we consider the RIPE db OR announced (or both - which is what it is supposed to be if the latter is true) it's not that hard. First, a requirement to register the AS number policy to keep it would be a easy task. Basically RIPE could then check assigned AS:es to registred. Still, the object does not have to be upto-date or actually reflecting anything. Second, as I belive there is so few assigned AS:es that never make it to the global routing tabele, I would like to define a few points of checks. These could even be route servers and this could be included in the automation. It could also be from the view of the test-traffic boxes.
Kurt, no BGP table check whatsoever can verify very valid setups like the one I described a few weeks back. (AS702 backup uplink using 702:80 community). What should the ASN holder do to prove the existance of this backup upstream? Take down their main link? Regards, Daniel
On Fri, 2 Aug 2002, Daniel Roesen wrote:
On Fri, Aug 02, 2002 at 02:45:45PM +0200, Kurt Erik Lindqvist wrote:
Well, if we consider the RIPE db OR announced (or both - which is what it is supposed to be if the latter is true) it's not that hard. First, a requirement to register the ASnumber policy to keep it would be a easy task. Basically RIPE could then check assigned AS:es to registred. Still, the object does not have to be upto-date or actually reflecting anything. Second, as I belive there is so few assigned AS:es that never make it to the global routing tabele, I would like to define a few points of checks. These could even be route servers and this could be included in the automation. It could also be from the view of the test-traffic boxes.
Kurt, noBGP table check whatsoever can verify very valid setups like the one I described a few weeks back. (AS702 backup uplink using 702:80 community). What should the ASN holder do to prove the existance of this backup upstream? Take down their main link?
Contingent BGP announcements are valid. Our view should not be to hurt ISPs. If one comes along and says he is doing a backup link and can bring documentation from his backup upstream, it is up to RIPE to verify it and accept it. Not impossible.
Regards, Daniel
Hank Nussbacher
Kurt, no BGP table check whatsoever can verify very valid setups like the one I described a few weeks back. (AS702 backup uplink using 702:80 community). What should the ASN holder do to prove the existance of this backup upstream? Take down their main link?
No, if there are cases that are not visible in the global routing table, notifying RIPE NCC as to why not would be good enough. At least IMHO. - kurtis -
participants (9)
-
Bruce Campbell -
Daniel Roesen -
Hank Nussbacher -
Henk Uijterwaal (RIPE-NCC) -
Kurt Erik Lindqvist -
Oliver Bartels -
Sebastian Willing -
Tanya Hinman -
Wilfried Woeber, UniVie/ACOnet