Way to store ROA info so we can accept but view?

[Douglas Fischer]

Humm...

I think that I'm "insanely careful"!
hahaha.
I try to use in every consultant customer that accepts(not all of them
accepts that level of insanity) the concept of Internal communities and
external communities.
- Internal being marked on the eBGP-In, and propagated only thought my iBGP
and striped on eBGP-Out.


I think that I understood the part of being harmful to the rest of the
world.
But my worry is more related to the impact of that (marking the state of
RPKI on the routes using communities) in my own instance of BIRD.

On the point of view of day-to-day operations, keep the rejected routes and
tag then with communities to be presented and interpreted on a Looking
Glass is very pedagogic to Transit Customers that asks:
"Why my routes are being rejected?"

Actually, I try to do that(tag with internal communities) with good or bad
for every check that I do... Ex.:
- Prefix Bogons
- ASN Bogons
- Tier 1 Free
- RPKI


Em seg., 30 de mai. de 2022 às 09:15, Dan Mahoney <danm at prime.gushi.org>
escreveu:

>
>
>
>
> > On May 30, 2022, at 8:04 AM, Douglas Fischer <fischerdouglas at gmail.com>
> wrote:
> >
> > That made me curious...
> >
> > "Note: REALLY DONT store the validation state inside a bgp_community or
> bgp_large_community or bgp_ext_community variables. It can cause CPU &
> memory overload resulting in convergence performance issues."
> >
> > Why that ( CPU & memory overload ) would happen?
> > Why is that different from a lookup against a Prefix List?
>
> Prefix lists are on-device only.  As are the attributes I was asking
> about.  Communities...aren't.
>
> Unless you're insanely careful to strip them, these are passed along to
> peers and cause reconvegence issues and recalculation issues down the chain.
>
> "It is considered harmful to manipulate BGP Path Attributes (for example
> LOCAL_PREF or COMMUNITY) based on the RPKI Origin Validation state. Making
> BGP Path Attributes dependent on RPKI Validation states introduces needless
> brittleness in the global routing system as explained here. Additionally,
> the use of RFC 8097 is STRONGLY ABSOLUTELY NOT RECOMMENDED. RFC 8097 has
> caused issues for multi-vendor network operators."
>
> (Since this is a plain text mail, I'll expand that link)
>
> https://mailarchive.ietf.org/arch/msg/sidrops/dwQi9lgYKRVctdlMAHhtgYkzhSM/
>
> -Dan
>
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20220530/825c708f/attachment.htm>