RIS [Re: AS41961 not seen in many networks]

Fri Jan 5 11:14:18 UTC 2007

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070105/05911f13/attachment.sig>