jgs review

This commit is contained in:
Randy Bush 2022-08-24 14:02:18 -07:00
parent 34827af356
commit e84d93dcac

View file

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