[Main] [Communities] [sBH/erBH] [rtsdCoS] [Routing Policy] [Filtering Policy] [Peering Policy]


KPN LOGO
AS286 Routing Policy

v20181005




Introduction

This document only applies to the KPN worldwide IP backbone AS286.

The hereby described routing policy may be adjusted, altered and updated any time. Even our processes cover updates to documentation, there's no guarantee, that it's always up-to-date. In case of doubt, transit customers should contact our NOC and peers should contact as286-peering@kpn.com.

A list of communities used by AS286 and their meaning can be found here AS286-communities.html.

AS286's AS-set is AS-KPN (RIPE). A current list of prefixes of the expanded AS-set (via RADb) can be found here:




Routing policy (transit (IPT) customers)




Routing policy (peering partners)




rPKI/route validation

In June 2018 AS286 started to evaluate RV/ROV (rPKI) on the production network. After some "real world" testing and impact analysis, some customer communication to have them clean their ROA (for the prefixes with no not-invalid alternatives) we decided to drop invalids from customers starting (latest) 1st of October 2018. After that date we'll slowly start to drop invalids from selected peers ... but again: slowly!

We decided NOT to reject everywhere due to foreseen connectivity issues. If there would be complains, nice, then we could work on, but we decided not to take the risk for "hidden" failures (like someone trying to reach a shop not getting there and then going to another shop). Others might decide different - there's always some possible impact and risk involved.

rPKI/RV doesn't play nice with RTBH, sBH, rtsdCoS and thus RV results are ignored for such announcements (customers only). Sigh

Little leftover of our impact analysis is a daily updated report (https://as286.net/data/ana-invalids.txt) of invalids we see from our peers/customers and "alternative" -not-invalid- paths (same sized valid prefix, more-specific valids (partial/covering full invalid prefix size) or less specifics valid/unknown). The report has its limitation, some "local" noise included and the "alternative" paths are just taken from a simple full view table and not all possible paths we have in the network, but it might be of use for the one or other.

It's generated the following way:

iROAS (prefix/mask-maxlen(originAS)) are the ROAs making this announcement invalid.

The rest of the format is hopefully more or less self explaining. In case of questions, drop us an email. Format might also change over time without notice. If you depend on it, drop us an email. Just one little note: The indented lines are just the different paths we recorded for this invalid. And it could be srcAS or srcASes on the non-indented line (invalid with single or multiple source ASes). srcas (lower case) is used on the indented lines (single).





[1] If the IX announces a less specific prefix including the IX LAN, than pMTUd with uRPF should work (if needed at all) for paths through the IX; but most IX do not announce the LAN space at all - so there's a potential risk of things going wrong; if IX start to announce the IX LAN, KPN may (will, must, should) consider re-announcing IX's own announcement (rather than suppressing re-announcement of internal/own -redistributed into iBGP- interface route ...)