Assuming that's right, I'm curious what the rationale is for giving
not-found routes a low preference?
it was intended more as prefer valid. but i take your point. do remind
me when we have gained enough experience to rev 7115
By definition, they don't compete with a route that is in any other
state -- NotFound basically means there is no ROA that has anything
to say about this prefix at all, so all routes for this prefix will
be NotFound.
true, if they are notfound, then they can not be either valid or invalid
as there is no covering roa.
Actually I think the "lower preference" thing still makes some
sense. I still see the case where you receive the routes from
different peerings, for which you either check or do not check the
received prefix against the ROA. I can give the below example:
you have a sick mind.:) yes, this is possible. so perhaps qualify the
recommendation.
in a configuration when some announcements may be checked and others
not, it is possible that a prefix may be marked both notfound,
because of not being checked, and [in]valid, because it is checked.
in this configuration, we recommend that the operator prefer valid
over notfound.
randy