Subject: [Sidrops] AMS-IX Lightning talk @ RIPE 75

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 15 Nov 2017 14:13:30 +0800 (Malaiische Halbinsel Normalzeit)

For the numbers see slides 12 and 13:

https://ripe75.ripe.net/presentations/66-m6-introspective.pdf

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl

---

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 15 Nov 2017 14:18:08 +0800 (Malaiische Halbinsel Normalzeit)

and for more live data: 

https://ams-ix.net/technical/statistics/route-server-stats

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Wed, 15 Nov 2017 06:21:52 +0000

Slide 11 is interesting:

"No traffic loss detected, although
advertised prefixes (with IRR+RPKI
filtering) went from ~165K to ~68K."

Totally redundant announcements?   Loss of TE paths?

Interesting statistics to compute on "Invalids" include - how many invalids are covered by routes to 

1. the same origin, 
2. the same next hop AS, 
3. and the same complete path.

dougm
--- 
Doug Montgomery @ NIST / ITL / ANTD  

On 11/15/17, 1:13 AM, "Sidrops on behalf of Matthias Waehlisch" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 15 Nov 2017 17:40:12 +0800

> On 15 Nov 2017, at 14:21, Montgomery, Douglas (Fed) <[email-masked]> wrote:
> 
> Slide 11 is interesting:
> 

Looking at slide #13, most of those are due to IRR filtering. Only 295 routes are RPKI invalid.

IRR+RPKI filtering means, I believe, that an announcement is filtered if:
= it is NOT authorised in IRR; or
= it is RPKI INVALID

Tim

> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 15 Nov 2017 17:48:10 +0800 (Malaiische Halbinsel Normalzeit)

> Looking at slide #13, most of those are due to IRR filtering. Only 295 
  yup.

> = it is NOT authorised in IRR; or
  Yes:

* Filter prefixes not present in an AS's announced AS/AS-SET

* Filter prefixes with ROA status: INVALID

Cheers
  matthias

---

From: Aris Lambrianidis <[email-masked]>
Date: Wed, 15 Nov 2017 14:49:46 +0100

Hi Douglas,

We did have concerns with regards to traffic loss before moving to a more strict filtering route server configuration,
so we were quite surprised ourselves by the non-linear relation between prefixes and traffic.

What I can say though is that route servers were created (at least in our case) as a safety net/catch all/last resort
type of peering. Historically our recommendation was (and still is) to peer directly for traffic you care about.

My guess is that this recommendation is honored; direct peerings probably cover most of the traffic exchanged
over our platform.

OTOH, new customers, especially smaller ones, definitely see great value in being able to peer immediately with
a route server and do traffic through it without setting up any other sessions altogether. But these definitely
would not be reflected in aggregated traffic statistics.

Kind regards,
Aris
AMS-IX

> On 15 Nov 2017, at 07:21, Montgomery, Douglas (Fed) <[email-masked]> wrote:
> 
> Slide 11 is interesting:
>