Large communities indicating RPKI VALID status
Job Snijders
job at fastly.com
Sun Apr 28 13:00:40 CEST 2024
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
More information about the Bird-users
mailing list