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

response to alvaro's discuss

Browse source
This commit is contained in:
Randy Bush 2022-08-23 08:54:14 -07:00
parent e36beef57b
commit 888b96c0b2
1 changed files with 50 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -10,8 +10,8 @@
<rfc category="std" consensus="true"
submissionType="IETF"
docName="draft-ietf-sidrops-rov-no-rr-02"
ipr="trust200902">
docName="draft-ietf-sidrops-rov-no-rr-04"
ipr="trust200902" updates="8481">
<front>
@ -80,10 +80,11 @@
<t>
A BGP Speaker performing RPKI-based policy should not issue Route
Refresh to its neighbors when receiving new RPKI data. This
document describes avoiding doing so by either keeping a full
Adj-RIB-In or saving paths dropped due to ROV 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 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>
@ -111,16 +112,17 @@
Memory constraints in early BGP speakers caused classic <xref
target="RFC4271"/> BGP implementations to not keep a full
Adj-RIB-In (Sec. 1.1). When doing RPKI-based Route Origin
Validation (<xref target="RFC6811"/> and <xref
Validation (ROV) (<xref target="RFC6811"/> and <xref
target="RFC8481"/>), and similar RPKI-based policy, if such a BGP
speaker receives new RPKI data, it might not have kept paths
previously marked as Invalid etc. Such an implementation must
then request a Route Refresh <xref target="RFC7313"/> from its
neighbors to recover the paths which might be covered by these new
RPKI data. This will be perceived as rude by those neighbors as
it passes a serious resource burden on to them. This document
recommends implementations keep and mark paths affected by
RPKI-based policy so Route Refresh is no longer needed.
then request a Route Refresh, <xref target="RFC2918"/> and <xref
target="RFC7313"/>, from its neighbors to recover the paths which
might be covered by these new RPKI data. This will be perceived
as rude by those neighbors as it passes a serious resource burden
on to them. This document recommends implementations keep and
mark paths affected by RPKI-based policy so Route Refresh is no
longer needed.
</t>
</section>
@ -166,48 +168,54 @@
used, the problem will increase.
</t>
<t>
Other mechanisms, such as automented policy provisioning, which
have flux rates similar to ROV (i.e. on the order of minutes),
could very well cause similar problems.
</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.
problem for resource constrained BGP speakers. In reality, only
some data need be retained.
</t>
<t>
When RPKI data cause one or more paths to be dropped due to ROV,
those paths MUST NOT be evaluated for best path, but MUST be saved
(either separately or marked) so they may be reevaluated with
respect to new RPKI data.
When RPKI data cause one or more paths to be dropped by operator
policy due to ROV, those paths MUST NOT be evaluated for best
route, but MUST be saved (either separately or marked) so they may
be reevaluated with respect to new RPKI data.
</t>
<t>
If new RPKI data arrive which invalidate the best path, and the
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
path.
route.
</t>
<t>
Policy which may drop paths due to RPKI-based checks such as ROV,
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 paths saved per the above paragraph, before non-RPKI
dropped routes saved per the above paragraph, before non-RPKI
policies are run, as the latter may change path attributes.
</t>
<t>
As storing these paths could cause problems in resource
constrained devices, there MUST be a knob allowing operator
control of this feature. Such a knob MUST NOT be per peer, as
this could cause inconsistent behavior.
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.
</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
path selection and in outbound signaling.
route selection and in outbound signaling.
</t>
</section>
@ -215,7 +223,7 @@
<section anchor="ops" title="Operational Recommendations">
<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
unnecessary Route Refresh requests to neighbors.
</t>
@ -227,7 +235,7 @@
<t>
If the BGP speaker does not implement these recommendations, the
operator SHOULD enable the vendor's knob to keep the full
operator should enable the vendor's control to keep the full
Adj-RIB-In, sometimes referred to as "soft reconfiguration
inbound". The operator should then measure to ensure that there
are no unnecessary Route Refresh requests sent to neighbors.
@ -236,16 +244,18 @@
<t>
If the BGP speaker has insufficient resources to support either of
the two proposed options, it MUST NOT be used for Route Origin
Validation. I.e. the knob in <xref target="rib"/> should only be
used in very well known and controlled circumstances.
Validation. The equiptment should either be replaced with capable
equipement or ROV not used. I.e. the knob in <xref target="rib"/>
should only be used in very well known and controlled
circumstances.
</t>
<t>
Operators using the specification in <xref target="rib"/> should
be aware that a misconfigured neighbor might erroneously send a
massive number of paths, thus consuming a lot of memory.
Pre-policy filtering such as described in <xref
target="I-D.sas-idr-maxprefix-inbound"/> SHOULD be used to reduce
massive number of paths, thus consuming a lot of memory. Hence
pre-policy filtering such as described in <xref
target="I-D.sas-idr-maxprefix-inbound"/> could be used to reduce
this exposure.
</t>
@ -299,21 +309,22 @@
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2918.xml"?>
<?rfc include="reference.RFC.4271.xml"?>
<?rfc include="reference.RFC.6811.xml"?>
<?rfc include="reference.RFC.7313.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.I-D.sas-idr-maxprefix-inbound.xml"?>
<?rfc include="reference.RFC.8481.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6480.xml"?>
<?rfc include="reference.RFC.6482.xml"?>
<?rfc include="reference.RFC.6811.xml"?>
<?rfc include="reference.RFC.7947.xml"?>
<?rfc include="reference.RFC.8205.xml"?>
<?rfc include="reference.RFC.8481.xml"?>
<?rfc include="reference.I-D.ietf-sidrops-8210bis.xml"?>
<?rfc include="reference.I-D.ietf-sidrops-aspa-verification.xml"?>
<?rfc include="reference.I-D.sas-idr-maxprefix-inbound.xml"?>
</references>
</back>