On Fri, Jan 05, 2007 at 12:16:07PM +0200, Pekka Savola wrote:
On Fri, 5 Jan 2007, Alexander Koch wrote:
On Fri, 5 January 2007 08:11:41 +0200, Pekka Savola wrote:
Well, the undocumented fact is that RIS does not accept multi-hop BGP peerings, which may somewhat limit its coverage.
Why then do I have one? They do such things, they indeed do.
Well, some time ago we opened a ticket to create RIS peering, and it was set up but didn't work, because they didn't realize it'd be multihop (about 3 hops). The peering was cancelled.
A disclaimer in advance: this was far before my time here. Part of the explanation is true. If you are present at one of the IXPs where we are, we prefer to configure the peering there. Also, we only configure multi-hop on our exchange-connected RRCs in very rare cases, as it could confuse people. RRC00, which is not connected to any exchange, is the dedicated rrc for multi-hop sessions.
This policy was not, AFAIR, available in any public documents.
Part of it was, but perhaps a bit hidden. I'll clarify it and add it in a more obvious place. It was here: http://www.ripe.net/info/faq/projects/ris.html#18 The RIS FAQ says:
Note: Since the database update capacity is currently limited, we do not accept any new peers on RRC00. However, do not hesitate to contact us if you can provide us with data that is complementary to what RRC00 already collects and we'll see what can be done.
So I wouldn't be surprised if RIS's coverage was somewhat limited.
Would anyone? The view of RIS is always limited by the amount of data we can process and the locations where we are present. Therefore, we would be very happy to hear ideas about how to improve the usefulness of the data we collect. Should we get more full feeds at exchanges (requiring bigger hardware)? Or more locations? Which locations? Or accept more multi-hop? regards, -- Erik Romijn RIPE NCC jr. software engineer http://www.ripe.net/ Information Services dept.