[db-wg] recording ROV enforcement

Dear all,

Speaking as individual contributor.

On Fri, Mar 03, 2023 at 03:36:37PM +0200, Aleksi Suhonen via db-wg wrote:
> On 2/2/23 14:57, Tomas Hlavacek via db-wg wrote:
> > This brings me to the question whether there is any structured and
> > machine-readable way that the networks and IXPs can use to publish
> > the fact that they enforce ROV?
> 
> No.
>
> > It seems that the logical place for this would be IRR and therefore
> > I am off-topic here, but since I am not aware of any previous
> > efforts to extend the RPSL for this particular purpose and I can
> > imagine reasons against it, I was wondering if there is something
> > else, possibly in the non-IRR part of the RIPE DB or somewhere else?
> 
> I suppose one could create a boolean in PeeringDB? I feel it fits the
> purpose of that database better than IRR...

A few years ago such an idea was discussed in PeeringDB:
https://github.com/peeringdb/peeringdb/issues/56

I still have my doubts about the usefulness of extending RPSL (or
PeeringDB) for network operators to publish whether they enforce
RPKI-ROV or not. I'll try to explain my reasoning:

Enforcing RPKI-ROV (which I take to mean the practise of rejecting
RPKI-invalid BGP routes) very much is "show, don't tell": you filter
routes based on RPKI data or you don't, but the act of informing the
world about the filtering is not the filtering itself. As such, the
field's scope would reduce to "we intend to enforce RPKI-ROV: yes/no".
But what do these intentions mean? Right now? Tomorrow? Next year?

I also think a boolean data type is a poor fit for a complex topic like
RPKI-ROV: it is possible a network operator uses RPKI to filter routes
on some EBGP sessions but not all EBGP sessions. For example AT&T/AS 7018
applies RPKI-ROV on EBGP sessions facing their peering partners, but not
facing their customers. Would they enter value '0.5' in such a field? :)
It's also possible RPKI-ROV is temporarily disabled on one (not all)
EBGP routers in a given network (because of some kind of software
defect), causing some friction between the stated intentions and
external observations.

I understand the academic interest to compare observations to stated
intentions, but from my perspective it feels a bit like forcing network
operators to participate in a monthly survey about RPKI-ROV.

Kind regards,

Job