Filters for decentralised networking

[Nico Schottelius]

Ondrej Zajicek <santiago at crfreenet.org> writes:

> 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?

Not exactly, but somewhat. I was imagining that above setup is somewhat
common in the sense of having multiple upstream, for which you have to
select the best announcement from within your administrative domain.

So instead of choosing the "best intra administrative domain path", I am
looking for the answer to the question of

"how to safely and sanely distribute routes at a specific ASN, which is
learned from within the whole administrative domain".

Let me give an example of things that don't work:

- Assume you control a /29 IPv6 network, you will announce /48's in
  various places
- A simple approach is that each ASN will emit *any* /48 from within
  that /29 towards *any* upstream, learned from *anywhere*

The problem with that approach is that one of the /48's might actually
have been learned from another outside upstream, redistributed inside
the administrative domain and being announced, even though the route is
not really connected, like this:

  - UPSTREAM 2 from above knows about a /48 from p10
  - ASN P15 learns it and due to the "all within the /29" rule, will
    announce it to UPSTREAM 3 + 4, even though it actually just acts as
    a transit between UPSTREAM 2 + 3/4, adding no value

This example gets even more tricky when you include another indirection,
customer peerings, that also have their /32's, announce various /48's,
at multiple locations (for instance at P5 and P6) - so relying only on
the subnetworks cannot work.

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

That is an interesting one, thanks for the pointer!

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

That could actually work very well even for both cases above, tagging
along the "inside" information.

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

Ondrej, thanks a lot for the suggestions, I have some very interesting
to follow up reads there.

Wish you a good last days of 2023 - soon we are finally entering an even
year again!

Greetings from Germany,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch