Filters for decentralised networking

[Ondrej Zajicek]

On Tue, Dec 26, 2023 at 06:32:22PM +0100, Nico Schottelius via Bird-users wrote:
> 
> Hello everyone,
> 
> I was wondering how you typically handle announcing
> a decentralised infrastructure to its upstreams / the Internet and how
> you handle receiving your own routes again on other upstreams.
> 
> The scenario is as follows:
> 
> CUSTOMER
> PEERINGS 1     ------ AS P6 --- CUSTOMER PEERINGS 2
>  |            /
>  |           /
> AS P5 ---- AS P10 --- UPSTREAM 1
>  | \      /     \
>  |   AS P7---\   \
>  |------------ AS P15 --- UPSTREAM 2
>                    \ ---- UPSTREAM 3
>                    \ ---- UPSTREAM 4
> 
> 
> So essentialy the different AS are somewhat connected internally (*) (not
> full mesh due to physical constraints) and the objective is to
> announce all internal and all customer peerings to all upstreams.

Hello

So i understand that AS P5 - AS P15 are different ASNs, but under common
administrative control, and one of issues is that different AS path
lengths conflicts with optimal path based on real topology?

In that case i would suggest to use AIGP (RFC 7311), if you keep IGPs
separate in each AS.

To handle customer routes, i would just mark them with custom community
on ingress to distinguish from other routes (e.g. for the purpose of
propagation to upstreams). And another custom community for upstream
routes (with similar behavior to OTC, RFC 9234). Of course, these
communities must be filtered out on all ingresses before proper one
is assigned.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
"To err is human -- to blame it on a computer is even more so."