jgs work-around alston

This commit is contained in:
Randy Bush 2022-08-26 12:56:20 -07:00
parent e84d93dcac
commit cb1b85375f

View file

@ -10,7 +10,7 @@
<rfc category="std" consensus="true"
submissionType="IETF"
docName="draft-ietf-sidrops-rov-no-rr-06"
docName="draft-ietf-sidrops-rov-no-rr-07"
ipr="trust200902" updates="8481">
<front>
@ -208,8 +208,8 @@
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.
dropped routes. Such an operator control MUST NOT be per peer, as
this could cause inconsistent behavior.
</t>
<t>
@ -247,11 +247,13 @@
<t>
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 equipment or ROV not used. I.e. the knob
in <xref target="rib"/> should only be used in very well known and
controlled circumstances.
support either of the two proposed options (keeping a full
AdjRibIn or at least the dropped routes), the equipment should
either be replaced with capable equipment or not use ROV. I.e.
the configuration setting in <xref target="rib"/> should only be
used in very well known and controlled circumstances. Such
circumstances could include operational work-arounds such as the
informed consent of the affected peers.
</t>
<t>