Limitations of BGP AS confederations?

[Ondrej Zajicek]

On Fri, Nov 06, 2020 at 12:01:20AM +0100, Erik Zscheile (Software Development) wrote:
> Hello,

Hello

> in an article [1] (which was one of very few articles which I found about BIRD + BGP AS confederations)
> it is stated that currently, BGP AS confederations have the following limitation:
> 
> > Bird won't consider the confederation part while calculating distance, which leads to weird routing results.

That is expected behavior per RFC 5065 5.3 (3).

The idea is that inside confederation BGP next hops are preserved when
paths are propagated from one internal ASN to another, therefore paths
are compared based on IGP cost to confederation border (assuming shared
IGP routes / metrics within whole confederation).

> > Bird neither provides a variable for the filter to calculate confederation length and make manual adjustments.
> >  * bgp_path.len in Bird doesn't contain the length of Confederation, as stated above;

It is true that bgp_path.len returns AS PATH length without confederation
ASNs, to be consistent with AS_PATH length used for best route selection.

Seems to me that the best tool for your case might be AIGP option (RFC
7311, implemented in version 2.0.7).

> 
> (citation from section below "But there is some problem when using Confederation in Bird")
> 
> The article seems to be tested against BIRD version 2.0.7.
> I'm not sure if that information is really correct, as I wasn't able
> to find any other source which stated that, but on the other hand,
> I also found no other source which explains BIRD + BGP AS confederation
> equally (or at least) that detailed.
> I (as of now) wasn't able to test it, but maybe I do that soon.
> (but I have no lab env running here, and didn't want to disrupt my currently working BGP setup,
>  althrough it is not 'extremely' important if it is interrupted for a short amount of time...)
> 
> 
> ## If this is still an issue in the master branch:
> 
> I think it would be a good idea to add an config option to conditionally enable
>   "count confederation AS's in bgp_path.len / distance calculations"
>   (or add another "method" on bgp_path and an option to
>    switch the default AS-path-length calculation to that).
> 
> * The statements above and the documentation combined sound like
>   the confederation AS's are kept inside an aggregated,
>   (unordered?) AS-set inside of bgp_path. Is that true?

>   (I wasn't able to find any concrete documentation about this,
>    and previously just thought that confederation AS's
>    were kept as an sequence.)
>   In BGP protocol terms [2], this would imply that either:
>   * BIRD only uses AS_CONFED_SET's for the "confederation part"
>     (under the assumption that these are treated like AS_SET), or
>   * BIRD uses AS_CONFED_SEQUENCE as expected, but treats
>     AS_SET, AS_CONFED_SET and AS_CONFED_SEQUENCE equally, even though
>     that doesn't seem like a universally practicable choice.

BIRD uses AS_CONFED_SEQUENCE, treats AS_SEQUENCE as length n, AS_SET as length 1
and AS_CONFED_SEQUENCE / AS_CONFED_SET as length 0.


> * Is there some easier way to fix this
>   (either via configuration which I just missed or via patching of code)?
> 
> * If not, is it possible to implement a more
>   complex fix for this in a reasonable timeframe
>   (e.g. not an excessive amount of work for a rather niche feature)?
> 
> * If it is possible, where should I start implementing it
>   (e.g. which parts of the BGP code are probably related to this,
>    as I don't want to read all the BGP code multiple times just to find those places)?
> 
> 
> Regards,
> Erik Zscheile
> 
> 
> [1]: https://lantian.pub/en/article/modify-website/bird-confederation.lantian/
> [2]: RFC 5065, page 5; https://www.rfc-editor.org/rfc/rfc5065.txt

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."