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


KPN LOGO
AS286 Routing Policy

v20180627




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 make use of ROA information. However ... slow start ... it's for now a trial and requires some follow up before getting strict.

Why not enforce it right away?

First we want to inform our customer and give them some time to get their setup corrected and help them if needed rather than annoy them from day one. And by now we haven't yet decided on how to handle (customer) RTBH, sBH/erBH and rtsdCoS announcements - it's very unlikely that standard ROA covered address space includes masks up-to /32 or /128 ... And who knows, what else pops up ...

Further we see (20180627) ~5400 invalid prefixes from peers and for ~2300 out of these prefixes no valid prefixes or less-specific not-invalid prefixes (=valid or unknown validation state) prefixes are known in the DFZ. Maybe we'll reach out to some of them ... or not ...

Here (ana-invalids.txt) is an -from time to time updated- analysis of invalids we see (peers only, downstreams will be directly contacted). The format is somewhat simple. For every invalid prefix seen from a peer NOT rejected because of other criteria (private AS, smaller than /24|/48, normal BGP filters, ...) there is a single line like (note the uppercase AS in srcAS/srcASes):
   $prefix$;srcAS=$originas$;altpfx=$validalternative$
or
   $prefix$;srcASes=$originaslisting$;altpfx=$validalternative$
with
   $prefix$ - guess what
   $originas$ - one and only seen origin AS
   $originlisting$ - {$originas[1],$originas[2],...} in case multiple origin ASes have need observed
   $validalternative$ - a not-invalid alternative (same size or less specific) - NONE if there's none
For every prefix there is one or there are multiple lines with (note the lowercase AS in srcas)
   $prefix$;srcas=$originas$;aspath=$recordedaspath$
with
   $recordedaspath$ - seen as path(s) for this $prefix$-$originas$ announcement


Routing policy rPKI/route validation - 20180627





[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 ...)