Yesterday, Ruediger talked about a 4th validation state for BGP routes
(RFC 6811 gives only 3). After thinking about it more, I believe it may
be helpful to call this validation state "Uninitialized". Here's why.
First, for the purposes of this discussion, we assume that the
validating cache has a "complete" snapshot of the global RPKI. The
definition of "complete" must be tuned via the validator settings
according to local policy, but that's a separate conversation.
I believe Ruediger is talking about the actual variable *in the router*
that stores validation state. Currently, in the router, the three
prescribed validation states for a BGP route are (RFC 6811):
o NotFound: No VRP Covers the Route Prefix.
o Valid: At least one VRP Matches the Route Prefix.
o Invalid: At least one VRP Covers the Route Prefix, but no VRP
Matches it.
There's a hidden assumption in this trichotomy: that the snapshot has
been completely transferred to the router (via the rpki-rtr), and all
related processing is complete. "NotFound" really means "I have
searched the complete set of VRPs, and no VRP Covers the route prefix."
Similarly, "Invalid" really means "I have searched the complete set of
VRPs, and at least one VRP Covers the route prefix, but no VRP Matches it."
During startup, however, it's important to for a validation state
variable to start in a 4th state ("Uninitialized"). "Uninitialized"
says "I haven't finished receiving/processing all the VRPs yet". This
is different from "NotFound". In fact, filters would potentially treat
this "Uninitialized" state differently from "NotFound".
In some sense this is just an implementation issue, but it is something
that an implementer could easily get wrong. You probably DON'T want
your variables to start out in the "NotFound" state.
Andrew
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
