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