>> 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