But, to come back to another comment: we're discussing details of routing configuration (because that's "easy"?) but I haven't seen any comment yet on my question on price/effort vs. (expected) result ratio (maybe because it's a bit more difficult? ;-).
I am not sure this has anything to do with routing configuration vs pricing.
I agree.
It has to do with application of AS-numbers and who are entiled to get/have one.
- kurtis -
My point is that any attempt to actively reclaim AS#s is going to *cost money*, both on the NCC's end as well as on the community's end. And as many(?) of the ASs which we are presumably talking about have been distributed _before_ the RIRs have been established, there is probably no (longer) a direct AS#/LIR/RIR (i.e. funding) relationship. And even if, we are talking about *our* (the LIRs') money! That's the reason why I'd like to find out about the expected cost, and even more about any educated guess relating to the number of ASs that can likely be reclaimed. And what a difference that number would make in the context of avoiding the introduction of AS#s with more than 16 bits. I hope I was able this time to get my point across ? Wilfried.
It should be *very* easy for RIPE to produce a list of AS numbers assigned and not in the routing tables (of course only for the RIPE area) This first list is just an estimate (see the discussion) but should give us an indication what we are talking about.... best regards, Wolfgang
-----Original Message-----
And as many(?) of the ASs which we are presumably talking about have been distributed _before_ the RIRs have been established, there is probably no (longer) a direct AS#/LIR/RIR (i.e. funding) relationship. And even if, we are talking about *our* (the LIRs') money!
That's the reason why I'd like to find out about the expected cost, and even more about any educated guess relating to the number of ASs that can likely be reclaimed. And what a difference that number would make in the context of avoiding the introduction of AS#s with more than 16 bits.
I hope I was able this time to get my point across ?
Wilfried.
On Tue, 16 Jul 2002, Wolfgang Tremmel, WT5-RIPE wrote:
It should be *very* easy for RIPE to produce a list of AS numbers assigned and not in the routing tables (of course only for the RIPE area)
Kinda out of topic, but still wondering - I just downloaded: ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.aut-num.gz Now, I know that unassigned AS numbers hanging around in the routing tables are nothing new. However, if they are properly registered within RIPE DB and noone notices the forgery - that's worrying: After processing it I've got the list of 5656 AS numbers assigned by RIPE NCC (not that difficult, agree). However, the list contacts two very interesting entries: AS55000 and AS55555! IANA-reserved ASN range! Let's examine the first one - it has an aut-num, route object and a proper route in the global routing table. Appears to be single-homed. aut-num: AS55000 as-name: MIPT-NET descr: MIPT-TELECOM-NET [snip] route: 81.5.64.0/20 descr: MIPT-TELECOM-NET origin: AS55000 [snip] * i81.5.64.0/20 134.222.249.118 80 50 3561 8342 8342 8810 8810 5467 55000 i The other one was a bit more "honest" - they admitted they are "fake" and they don't pollute the global routing table. They also don't have any route objects. Still, an ugly entry exists in the RIPE DB: aut-num: AS55555 as-name: AS55555 descr: fake AS descr: Kiev, Ukraine [snip] Are we going to stick with the rule that RIPE NCC people cannot modify the RIPE DB and tolerate the offenders? Just wondering ... Regards, Beri
Dear Berislav, Colleagues, Berislav Todorovic wrote: [...]
Now, I know that unassigned AS numbers hanging around in the routing tables are nothing new. However, if they are properly registered within RIPE DB and noone notices the forgery - that's worrying:
[...]
Are we going to stick with the rule that RIPE NCC people cannot modify the RIPE DB and tolerate the offenders? Just wondering ...
I just wanted to note that though we have such general rule we also have exceptions. Especially when the data in the database conflicts with the information in the Registration Services. Of course our main concern is regarding the space distributed by the RIPE NCC. Speaking of the quality of data in the RIPE Database in general, we are working towards making the database more restrictive to reject bogus records. We also run database consistency projects to help people to keep their records up to date. Also, as you know, we perform massive clean-ups if the community have requested such actions. That, for instance, happened to unreferenced person objects; we plan a cleanup of non valid "auth:" fields in mntner objects. In my opinion such actions are more favourable as they get community consensus and require much less resources per inconsistency than a single clean-up. We are also discussing some ideas of how to allow the holders of the address or ASN space to perform necessary clean-ups within their space without requesting the RIPE NCC to do this.
Regards, Beri
Regards, Andrei Robachevsky DB Group RIPE NCC
At 11:20 16/07/2002 +0200, Berislav Todorovic wrote:
Now, I know that unassigned AS numbers hanging around in the routing tables are nothing new. However, if they are properly registered within RIPE DB and noone notices the forgery - that's worrying:
I've noticed, from the day it appeared - I highlight all "illegal" AS announcements in my weekly routing report (sent to the routing-wg amongst lots of other places). It seems as though the RIPE NCC couldn't care less though about the forgery, and that is alarming given that address and AS allocation is supposed to be their function. On the otherhand, if this is a real allocation, can someone from the NCC please announce to the community what new AS block this is from, and correct the IANA delegation file... thanks! philip --
--On Wednesday, July 17, 2002 12:08:48 +1000 Philip Smith <pfs@cisco.com> wrote:
It seems as though the RIPE NCC couldn't care less though about the forgery, and that is alarming given that address and AS allocation is supposed to be their function.
What is ofcourse interesting as well is - what can the NCC do to stop this or prevent it from happening in the future? They can send angry emails and remove the objects from the database (which ofcourse would be a good start...:) ), but they can't prevent the AS:es from being routed. What is really interesting is that some upstream is actually accepting these AS:es as peers... - kurtis -
What is really interesting is that some upstream is actually accepting these AS:es as peers...
perhaps RIPE should bash these upstreams.... one after the other down the AS path, until one takes action..... Wolfgang
What is really interesting is that some upstream is actually accepting these AS:es as peers...
perhaps RIPE should bash these upstreams.... one after the other down the AS path, until one takes action.....
Hmm, RIPE NCC could ofcourse create entries in the db to block all their announcements until they fixed this...no wait that would require people to actually understand and use filters in the first place...:( - kurtis -
Greetings, On Tue, 16 Jul 2002 09:36:12 +0200 "Wolfgang Tremmel, WT5-RIPE" <wtremmel@vianetworks.com> wrote:
It should be *very* easy for RIPE to produce a list of AS numbers assigned and not in the routing tables (of course only for the RIPE area)
If people in the community show interest for this data, the RIPE NCC is ready to publish it. It should be noted that this data would be extracted from the Routing Information Registry Project, with the limitations that were already highlighted somewhere in this thread - see also http://ris.ripe.net/
This first list is just an estimate (see the discussion) but should give us an indication what we are talking about....
Indeed. Regards, -- Manuel Valente - Software Manager - RIPE NCC "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." (Antoine de Saint-Exupery)
participants (8)
-
Andrei Robachevsky -
Berislav Todorovic -
Kurt Erik Lindqvist -
Manuel Valente -
Philip Smith -
Randy Bush -
Wilfried Woeber, UniVie/ACOnet -
Wolfgang Tremmel, WT5-RIPE