[Sidrops] Alvaro Retana's Discuss on draft-ietf-sidrops-rov-no-rr-03: (with DISCUSS and COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-sidrops-rov-no-rr-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rov-no-rr/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) [I'm raising this point to be a discussion -- it may not end with changes
to the document.]

This document recommends that route refresh not be used when inbound policies
change at a relatively high rate.  ROV validation is "only" an example.

As Jeff Haas wrote on the idr list [1]:

   This isn't any different than any other over-aggressive
   provisioning tool's impact.

Was there any consideration given to making a general recommendation and not
just limiting it to ROV?  I can see the direct impact on rfc6811/rfc8481, and
how general BGP advice is out of scope for sidrops.  However, I am primarily
curious whether there is anything particular to ROV to focus the recommendation
this way.  I couldn't find a related discussion (beyond Jeff's message) in the
archive, but I may have missed it.

[1] https://mailarchive.ietf.org/arch/msg/idr/F3w0RDyv9dK4w15fzuDZx3P4Jw0

(2) I have a couple of issues with this paragraph from §4.  Addressing them
should be relatively easy:

   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.

(2a) "paths to be dropped due to ROV, those paths MUST NOT be evaluated for
best path"

Neither rfc6811 nor rfc8481 require that routes be "dropped due to ROV". 
rfc8481 requires that "Absent specific operator configuration, policy MUST NOT
be applied."

Please clarify that the trigger above ("dropped due to ROV") is defined by the
operator and is not just a result of ROV.

(b) "MUST be saved (either separately or marked)"

For a required action, the description is not clear.  For starters, "marked"
how?  Separately where?

>From §1.1/rfc4271:

   The Adj-RIBs-In contains unprocessed routing information that has
   been advertised to the local BGP speaker by its peers.

The RIB structures in rfc4271 are conceptual -- but since this document
requires keeping information (presumably in the Adj-RIB-In), please be more
specific about where and marked how.

(3) The following requirement from §5 is outside the scope of this document:

   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 Section 4 should only be used in very
   well known and controlled circumstances.

Requiring a node not to be used for ROV is a powerful statement.  It basically
invalidates the base operation specified on rfc6811/rfc8481 by always requiring
the mechanism in this document.  While I understand the potential resource
demands, selecting a node to perform a specific operation in a particular
operator's network is outside the scope of this document.

Instead, I would like to see guidance to the operator to consider not using the
specific piece of equipment to perform a particular function.  This can be as
easy as:

    If the BGP speaker has insufficient resources to support either
    of the two proposed options, the operator is strongly encouraged
    to consider an alternate piece of equipment to perform Route Origin
    Validation.

The second part of the sentence ("I.e. ...") sounds like a better
recommendation -- and, clearly, not the same as "MUST NOT be used".


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) This document should be tagged as replacing draft-ymbk-sidrops-rov-no-rr.

(2) Expand ROV on first use.

(3) rfc4271 doesn't talk about a "best path" -- it does talk about a Decision
Process that results in a best route (or ineligible routes).  Please be
consistent with existing terminology.

(3) The reference to route-refresh should include rfc2918.

(4) §4: s/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./an
implementation MUST provide a global mechanism to control the operation.

A knob makes me think of the CLI -- I'm sure you want the possibility to
control the behavior in other ways: YANG, etc..

(5) §5: "Operators...SHOULD ensure that the BGP speaker implementation is not
causing unnecessary Route Refresh requests to neighbors."

What is the interoperability-related requirement with "ensuring" that makes
Normative language needed?  What does "ensure" entail?  When is it ok for the
operator to not "ensure"?  Why is this action only recommended and not
required?  After all, eliminating unnecessary route refresh requests is the
purpose of this document.

There's a similar phrase later on without Normative language.

s/SHOULD/should

(6) §5: "the operator SHOULD enable the vendor's knob"

Same questions as above:  Why is Normative language needed here?  When is it ok
to not enable the functionality?  Why is this action recommended and not
required?  ...

(7) §5: "Pre-policy filtering...SHOULD be used to reduce this exposure."

When is it ok to not use pre-policy filtering?  Why is this action recommended
and not required?

(8) rfc6811 and rfc8481 should be Normative references.

(9) s/(IXPs)which/(IXPs) which