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

[Randy Bush <[e-mail]>]

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