Re: [Sidrops] John Scudder's Discuss on draft-ietf-sidrops-rov-no-rr-05: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

LGTM. Thanks!

—John

> On Aug 24, 2022, at 5:01 PM, Randy Bush <[e-mail]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> thaks john,
> 
> how about a more logical ordering and a slight rewording?
> 
> 4.  Keeping Partial Adj-RIB-In Data
> 
>   If new RPKI data arrive which cause operator policy to invalidate the
>   best route, and the BGP speaker did not keep the dropped routes, then
>   it would issue a route refresh, which this feature aims to prevent.
> 
>   A route that is dropped by operator policy due to ROV is, by nature,
>   considered ineligible to compete for best route, and MUST be kept in
>   the Adj-RIB-In for potential future evaluation.
> 
>   Ameliorating the Route Refresh problem by keeping a full Adj-RIB-In
>   can be a problem for resource constrained BGP speakers.  In reality,
>   only some data need be retained.  If an implementation chooses not to
>   retain the full Adj-RIB-In, it MUST retain at least routes dropped
>   due to ROV, for potential future evaluation.
> 
>   As storing these routes could cause problems in resource constrained
>   devices, there MUST be a global operation, CLI, YANG, etc. allowing
>   the operator to enable this feature, storing the dropped routes.
>   Such a control MUST NOT be per peer, as this could cause inconsistent
>   behavior.
> 
>   As a side note: policy which may drop routes due to RPKI-based checks
>   such as ROV (and ASPA, BGPsec [RFC8205], etc. in the future) MUST be
>   run, and the dropped routes saved per this section, before non-RPKI
>   policies are run, as the latter may change path attributes.
> 
> randy