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

[Alvaro Retana <[e-mail]>]

On August 22, 2022 at 9:12:32 PM, Randy Bush wrote:


Randy:

Hi!

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

As I said, I just wanted to discuss this point.

The text is ok -- I just hate to hide this type of information in a
ROV-specific document.  Too late for this document, but it would have
been better for the recommendation to be general and to use ROV as an
example/motivation.

** Consider this point closed. **



> > (2) I have a couple of issues with this paragraph from §4. Addressing
> > them should be relatively easy:
...
> > (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?

rfc4271 spends a lot of time describing the conceptual operation of
the RIB and those implementations do just fine. ;-)

The text is confusing because it implies that there is a "separate"
place to keep the information, even if the section is titled "Keeping
Partial Adj-RIB-In Data".  Also, it seems to separate the storage
(separately) from an indication that the route is somehow recognized
as one that was dropped (marked).  There's no explanation for either.

Combining the two points, here's my suggestion:

   A route that is dropped by operator policy due to ROV MUST be
   considered ineligible and MUST be kept in the Adj-RIB-In for
   potential future evaluation.

> *** so issue still open ***

If you think the suggestion (or something very similar) is ok then we
can consider this point closed.



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

The problem that I have is that the normative language applies to the
box: "the BGP speaker...MUST NOT be used" -- how about if we turn it
around:

   The mechanisms specified in this document MUST be used in
   well-known and controlled circumstances.  If the equipment
   has insufficient resources to support either of the two
   proposed options, it should either be replaced with capable
   equipment or ROV not used.

** At this point we're probably splitting hairs, so we can consider
this item closed too. **




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

The Chairs/AD know. ;-)

[In the datatracker page for this document.]



Thanks!

Alvaro.