[mat-wg] feature request: have stat report on transitted prefixes

Dear colleagues,

I wanted to follow-up on Job's feature request, about RIPEstat also
displaying prefixes transited by an ASN, since several of you also said
you would find this feature useful.

Supporting this feature will require some work on RIPEstat's front-end
as well as on the back-end (our Hadoop storage platform). Implementing
this for all available historic RIS data would have a large impact on
our storage capacity. However, we will be able to implement this feature
for a sliding window of 30 days, as you suggested. So RIPEstat will be
able to show the prefixes for which an ASN provided transit during the
previous 30 days.

At the moment I don't have a concrete delivery date for this feature,
but we will merge the necessary development work into our work plan and
let you know before the end of June when we expect to be able to support
this feature in RIPEstat. We will make sure it is implemented before
RIPE 71 in November.

Please let me know if you have any further feedback or questions.

Regards,

Christian Teuschel & Romeo Zwart
RIPE NCC

On Mon, May 11, 2015 at 01:15:09PM +0200, Job Snijders wrote:
> Hi MAT,
> 
> I'd really like the stat team to implement a tool that tells me
> what prefixes are originated AND transitted by a given ASN. The
> use-case is that I (before setting up BGP sessions) can make an
> automated assessment what amount of prefixes the network will
> announce, which prefixes they are likely to announce and if that
> matches up with the prefix-filter I would apply on that bgp
> session.
> 
> A second use case is that when I want to connect a peer or customer
> to which I have never been connected before, I have no idea what
> they will announce to me. Should I want to make predictions for
> traffic engineering purposes, it would be beneficial if I could
> fetch a list of prefixes this peer is likely to announce to other
> peers from the stat system.
> 
> A sliding window of say 30 days would be perfect, for my purposes I
> do not need the tool to offer data going back to the beginning of
> time.
> 
> Do others agree that the above would be a useful feature?
> 
> Kind regards,
> 
> Job
>