Re: [sidr] Fwd: Last Call: <draft-ietf-opsec-bgp-security-05.txt> (BGP operations and security) to Best Current Practice

[Randy Bush <[e-mail]>]

> John Scudder made an interesting observation, which looks of interest
> to this group.

it has to happen occasionally, but jgs was not completely correct, as
the author pointed out.

From: Randy Bush <[e-mail]>
Subject: Re: Last Call: <draft-ietf-opsec-bgp-security-05.txt> (BGP operations and security) to Best Current Practice
To: Jerome Durand <[e-mail]>
Cc: "John G. Scudder" <[e-mail]>,
    <[e-mail]>,
    opsec <[e-mail]>, 
    ietf <[e-mail]>
Date: Tue, 09 Sep 2014 11:14:47 +0900

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