On Sat, Apr 27, 2024 at 03:00:45PM +0200, Ondrej Zajicek via Bird-users wrote:
On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote:
There's internet draft describing in detail, why it's not a good idea to store RPKI validation state inside community variables at all..
https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-0...
Well, note that this draft is primarily about not announcing validation state in transitive attributes to the whole internet.
Yes
But there are good reasons for having validation state in non-transitive BGP attributes (or communities properly filtered out on AS egress). Validating RPKI and marking routes at AS ingress ensures that all routers within AS have consistent routing state and thus avoiding routing loops.
Perhaps I am missing something, but how does marking in itself help avoid routing loops? I am under the impression that a requirement for intra-AS transitive marking follows from non-standard modifying of non-transitive local attributes (for example, 'weight' or 'preference') based on the validation state - which is not what I'd recommend to begin with. Merely rejecting RPKI-invalid routes at the AS ingress and *not* manipulating any other local or transitive path attributes will also ensure a consistent routing state.
Unfortunately large communities do not have transitive flag like extended ones so perhaps it would make sense to use extended community for this purpose. Or perhaps there should be well-known extended community for that ...
https://www.rfc-editor.org/rfc/rfc8097.html ? Kind regards, Job