> 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 <ra...@psg.com>
Subject: Re: Last Call: <draft-ietf-opsec-bgp-security-05.txt> (BGP operations
and security) to Best Current Practice
To: Jerome Durand <jerdu...@cisco.com>
Cc: "John G. Scudder" <j...@juniper.net>,
<draft-ietf-opsec-bgp-secur...@tools.ietf.org>,
opsec <op...@ietf.org>,
ietf <i...@ietf.org>
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
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
