randy/draft-rov-no-rr
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

jgs review

Browse source
This commit is contained in:
Randy Bush 2022-08-24 14:02:18 -07:00
parent 34827af356
commit e84d93dcac
1 changed files with 43 additions and 32 deletions
Download patch file Download diff file Expand all files Collapse all files

75
draft-ietf-sidrops-rov-no-rr.xml
View file

@ -10,7 +10,7 @@
<rfc category="std" consensus="true"
submissionType="IETF"
docName="draft-ietf-sidrops-rov-no-rr-05"
docName="draft-ietf-sidrops-rov-no-rr-06"
ipr="trust200902" updates="8481">
<front>
@ -80,11 +80,11 @@
<t>
A BGP Speaker performing RPKI-based policy should not issue Route
q Refresh to its neighbors because it has received new RPKI data.
This document updates RFC8481 by describing how to avoid doing so
by either keeping a full Adj-RIB-In or saving paths dropped due to
ROV (Route Origin Validation) so they may be reevaluated with
respect to new RPKI data.
Refresh to its neighbors because it has received new RPKI data.
This document updates <xref target="RFC8481"/> by describing how
to avoid doing so by either keeping a full Adj-RIB-In or saving
paths dropped due to ROV (Route Origin Validation) so they may be
reevaluated with respect to new RPKI data.
</t>
</abstract>
@ -169,52 +169,55 @@ q Refresh to its neighbors because it has received new RPKI data.
</t>
<t>
Other mechanisms, such as automented policy provisioning, which
Other mechanisms, such as automated policy provisioning, which
have flux rates similar to ROV (i.e. on the order of minutes),
could very well cause similar problems.
</t>
<t>
Therefore this document updates <xref target="RFC8481"/> by
describing how to avoid this problem.
</t>
</section>
<section anchor="rib" title="Keeping Partial Adj-RIB-In Data">
<t>
Ameliorating this 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 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.
</t>
<t>
A route that is dropped by operator policy due to ROV MUST be
considered ineligible and MUST be kept in the Adj-RIB-In for
potential future evaluation.
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.
</t>
<t>
If new RPKI data arrive which invalidate the best route, and the
BGP speaker did not keep all alternatives, then it MUST issue a
route refresh, so those alternatives may be evaluated for best
route.
</t>
<t>
Policy which may drop routes due to RPKI-based checks such as ROV,
ASPA, BGPsec <xref target="RFC8205"/>, etc. MUST be run, and the
dropped routes saved per the above paragraph, before non-RPKI
policies are run, as the latter may change path attributes.
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.
</t>
<t>
As storing these routes could cause problems in resource
constrained devices, there MUST be a global operation, CLI, YANG,
... allowing operator control of this feature. Such a control
MUST NOT be per peer, as this could cause inconsistent behavior.
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.
</t>
<t>
If Route Refresh has been issued toward more than one peer, the
order of receipt of the refresh data can cause churn in both best
route selection and in outbound signaling.
As a side note: policy which may drop routes due to RPKI-based
checks such as ROV (and ASPA, BGPsec <xref target="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.
</t>
</section>
@ -224,12 +227,14 @@ q Refresh to its neighbors because it has received new RPKI data.
<t>
Operators deploying ROV and/or other RPKI based policies should
ensure that the BGP speaker implementation is not causing
unnecessary Route Refresh requests to neighbors.
Route Refresh requests to neighbors.
</t>
<t>
BGP Speakers MUST either keep the full Adj-RIB-In or implement the
specification in <xref target="rib"/>.
specification in <xref target="rib"/>. Conformance to this
behavior is a additional, mandatory capability for BGP speakers
performing ROV.
</t>
<t>
@ -244,7 +249,7 @@ q Refresh to its neighbors because it has received new RPKI data.
If the BGP speaker's equipment has insufficient resources to
support either of the two proposed options, it MUST NOT be used
for Route Origin Validation. The equipment should either be
replaced with capable equipement or ROV not used. I.e. the knob
replaced with capable equipment or ROV not used. I.e. the knob
in <xref target="rib"/> should only be used in very well known and
controlled circumstances.
</t>
@ -258,6 +263,12 @@ q Refresh to its neighbors because it has received new RPKI data.
this exposure.
</t>
<t>
If Route Refresh has been issued toward more than one peer, the
order of receipt of the refresh data can cause churn in both best
route selection and in outbound signaling.
</t>
<t>
Internet Exchange Points (IXPs) which provide <xref
target="RFC7947"/> Route Servers should be aware that some members