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

[Randy Bush <[e-mail]>]

aha!  an alvaro review; always excellent.  thank you!

> 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.

we are not aware of automated provisioning tools which have a policy
update frequency on the order of ROV, which can now be seen on the order
of ten minutes.

this document was a response to  real operational events, not theory.

the authors are not aware of other provisioning tools which have fluxed
policy to the point of other proviers de-peering due to the route
refresh load.

but, a comment that other high flux rate policy changes might also cause
similar problems would not hurt.  how about

      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.

> (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.

embarrassing point given i wrote 8481 <blush>

   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.

or was part of your point wanting that to be "MAY be saved?"

> (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.

as you just pointed out, for many implementations, adjribin is purely
conceptual.  so what those implentations do is hidden black magic.  so
how do we describe augmenting black magic?  do you have a suggestion?

***  so issue still open  ***

> (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.

well, i am not sure we're on the same page here.  what was intended was
an operational requirement that a speaker that can not do rov without
attacking their neighbors (either by having a full adjribin or by the §4
hack) should simply not do rov.
> 
> 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".

how about

   If the BGP speaker has insufficient resources to support either of
   the two proposed options, it MUST NOT be used for Route Origin
   Validation.  The equiptment should either be replaced with capable
   equipement or ROV not used.  I.e. the knob in Section 4 should only
   be used in very well known and controlled circumstances.

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

tagged where/how?

> (2) Expand ROV on first use.

ack

> (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.

ok.  a bit delicate, but will try.

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

ok

> (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..

      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.

> (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

ack

> (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?  ...

ok

> (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?

a bit of grey?

   Operators using the specification in Section 4 should be aware that a
   misconfigured neighbor might erroneously send a massive number of
   paths, thus consuming a lot of memory.  Hence pre-policy filtering
   such as described in [I-D.sas-idr-maxprefix-inbound] could be used to
   reduce this exposure.

> (8) rfc6811 and rfc8481 should be Normative references.

sure

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

ack

thanks for a thorough review!!

randy