[PATCH] Add 'preferred' route attribute for selective add-path

[Trisha Biswas]

Hi Ondrej,

Thanks for evaluating the patch. It makes sense to use rte->flags to store
the preferred path and access that from the filter code to get around the
first issue.

For the second issue, it almost feels like there should be a separate mode
of route announcement called RA_SELECTIVE. This would be exactly the same
as RA_ANY, but in addition it would announce when routes change their
REF_BEST. The RA_SELECTIVE mode could be enabled with a config option such
as 'add paths tx selective;', so that we don't end up with lots of
unnecessary announcements for BGP add-path. Previously, we had tried this
by making RA_SELECTIVE a clone of RA_OPTIMAL, but that did not work well.
Do you see issues with this approach up front?

Thanks,
Trisha
--

*Trisha Biswas* | Sr. Software Engineer, Network Systems
fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn
<http://www.linkedin.com/company/fastly>


On Fri, Feb 26, 2021 at 3:53 PM Ondrej Zajicek <santiago at crfreenet.org>
wrote:

> On Fri, Feb 26, 2021 at 01:56:42PM -0800, Trisha Biswas wrote:
> > Hi all,
> >
> > The attached patch adds a 'preferred' route attribute to check whether
> the
> > route being processed has been selected as the best-path for the network
> it
> > belongs to. This attribute does not take in a value, and returns a
> boolean.
> > This is useful for allowing selection in an add-path enabled BGP session.
>
> Hi
>
> I agree this may be a useful feature, but there are two issues with the
> approach used in the patch:
>
> First, we would like not to access rte->net from the filters (outside of
> net_addr). We plan to remove this ptr and instead have ptr from rte
> directly to net_addr.
>
> Second, RA_ANY mode of route announcement (which is used by BGP add-path
> and pipes) would not really work with this change in a way how you expect
> - consider this scenario: route A is added, preferred and accepted for
> export, then route B is added, not-preferred and not-accepted for export.
> Then route A is withdrawn and B is selected as preferred. Protocols with
> RA_OPTIMAL received update with route B as new-preferred (as they accept
> only preferred one and that changed), but protocols with RA_ANY receive
> just withdraw for route A (as they accept all routes and only route A was
> changed, while route B is the same as was announced before), so they do
> not get notification that route B became preferred and export filter for
> B is not re-evaluated.
>
> The one approach that avoids the first issue is to add REF_BEST flag
> (in rte->flags) that would be added to mark preferred routes, and this
> flag can be accessed from the filter code. But that does not fix the
> second issue. We can add RA_ANY announcement for routes that changed
> their REF_BEST, but that would add plenty of unnecessary announcements
> (that are propagated as BGP updates) for BGP add-path that do not
> use or care about this flag.
>
> In general, BGP add-path in BIRD was developed with assumption that
> routes within one network are handled independently and would need some
> deeper redesign for other cases. That might be useful (in order to be
> able to implement things like 'announce best 4 routes for given
> network'), but i do not see an easy solution to this.
>
> --
> 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."
>

> On Fri, Feb 26, 2021 at 1:56 PM Trisha Biswas <tbiswas at fastly.com> wrote:
>
>> Hi all,
>>
>> The attached patch adds a 'preferred' route attribute to check whether
>> the route being processed has been selected as the best-path for the
>> network it belongs to. This attribute does not take in a value, and returns
>> a boolean. This is useful for allowing selection in an add-path enabled BGP
>> session.
>>
>> The motivation behind selective add paths is to reduce the number of
>> routes that are shared in an add-path enabled BGP session on a per-prefix
>> basis. Instead of sending all paths to all destinations for
>> an add-path session, we would like to specify prefixes (and/or other route
>> attributes) for which all paths are to be shared. Further, if there are
>> thousands of ways to reach a destination, simply negotiating add paths for
>> a prefix would result in sharing all additional paths to the peer. This in
>> turn would result in a flood of advertisements to be sent between the
>> nodes, and a high memory footprint on the peer. To avoid this, we are
>> considering a filter-based selection criteria that would unlock the
>> potential of purposefully sending additional paths when desired.
>>
>> Adding the 'preferred' keyword allows us to always send the best-path
>> whether or not other criteria in the export filter match. In the following
>> example, a route is exported when it is either the best route or one of
>> 172.16.0.0/16, 10.0.0.0/8{16,24} <http://10.0.0.0/8%7B16,24%7D> (regardless
>> of best route status). In the case of 8.8.8.0/24, we export it if it's
>> the best route, or if it additionally has the specified extended community
>> attached to the route.
>>
>> protocol bgp {
>> [....]
>> add paths tx;
>> export filter {
>> if preferred || (net = [172.16.0.0/16, 10.0.0.0/8{16,24}
>> <http://10.0.0.0/8%7B16,24%7D>]) then accept;
>> if preferred || (net = 8.8.8.0/24 && (ro, 1, 2) ~ bgp_ext_community)
>> then accept;
>> #remaining filter code
>> reject;
>> }
>> }
>>
>> Cheers,
>> Trisha
>> --
>>
>> *Trisha Biswas* | Sr. Software Engineer, Network Systems
>> fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn
>> <http://www.linkedin.com/company/fastly>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20210226/0cdf91ca/attachment.htm>