[db-wg] will NWI-19 break routing?

On Thu, 24 Nov 2022 at 16:13, Nick Hilliard via db-wg <db-wg at ripe.net> wrote:
>
> Niall O'Reilly via db-wg wrote on 23/11/2022 18:17:
> > What I have in mind is AS-NIALLSPECIAL, which I populate with a list of
> > AS numbers which I want to advertise to let others know that these
> > are to be handled in some special way, unlike those in AS-NIALLNORMAL.
> >
> > According to operational circumstances, there might be periods, even
> > long ones, with nothing special going on; AS-NIALLSPECIAL would then be
> > empty, but only for as long as this continued to be the case.
>
> this ^^^ is one of the failure modes.
>
> It would not be safe to assume that empty as-sets named in RPSL policies
> are unused. It would be less unsafe to assume that unreferenced as-sets
> are unused.  A reasonable middle ground might be - after the proposed
> new unqualified as-set block has been implemented - to check out all
> unreferenced as-sets older than a specific period of time and flag those
> for deletion.
>
> It would also be worthwhile inspecting rpsl in other IRRDBs to see if
> there are any references.  The reason for this is that lots of people
> use tools like bgpq3 / peval / etc, and query aggregate IRRDBs, e.g.
> RADB, NTT, etc.
>
> So if you have RPSL in another IRRDB and this references an empty as-set
> in the RIPE IRRDB, that definition may be picked up in preference to
> other as-set definitions.  I.e. by removing an as-set definition in the
> RIPE IRRDB, it could unexpectedly influence routing policies elsewhere.
>
> These are corner cases, but they should show why some care will be
> needed to figure out whether deleting these objects is a good idea.

This is an interesting point. I know nothing about bgpq3 or peval
(even though it has been around since the beginning of time). So I
just read the documentation on GitHub for them. I never realised this
feature existed. What you have described here Nick is in effect a
cross registry dependency. A feature that, as far as the RIPE Database
is concerned, is undocumented and unsupported. If anyone actually uses
this feature we have probably just broken it with NWI-19.

These two tools (and there may be others) work differently. Let's look
first at peval. It says in the docs:

"\-s <source-list>"
Consider the sources specified in the comma separated <source-list>.
If an object is defined in multiple sources in <source-list>,
peval uses the definition first encountered in <source-list>
from left to right.

Suppose we have '-s RIPE,RADB'. If RADB contains AS-AMAZON and we
create an AS-AMAZON in the RIPE Database, then the object in RIPE DB
will be used instead of the one in RADB. I guess that is the problem
we are trying to solve. But suppose RADB contains AS-WALKER and you
don't trust this object. By creating an empty AS-WALKER object (or one
with different content) in the RIPE DB you can effectively override
the object in RADB in your aggregation. This could be an intentional
and legitimate action. The question is, does anyone actually do this?
If so we may have just broken this. You can no longer create a short
name AS-SET object in the RIPE DB to override one in RADB.

However for peval you can get around this using:

"\-f <file-name>"
IRR cache file. You can have any RPSL object in this file, except route
objects.
They will override these objects in IRR.
This option is intended for private objects, or to test new public objects
before publishing. You can specify more than one cache file by specifying this
option repeatedly.

So you could put a short name AS-SET object in a cache file to
override the object you want to ignore in RADB.

The bgpq3 tool also has a source flag (-S) and sources with identical
objects are handled the same way as with peval. This tool doesn't have
the cache file option of peval. So with bgpq3 you can no longer
intentionally override an object in RADB using this feature, if anyone
ever does do this.

This is an odd feature as it creates interdependencies between IRR
databases that are not defined in the database documentation. It also
means that, if anyone uses this feature, we cannot safely delete any
AS-SET based on being empty or un-referenced (within its own registry
database). It also breaks the self referential integrity of the RIPE
Database (and others) because data may be entered into the RIPE
Database for use by external tools to impact on data in another
registry. Even though peval has been around since the beginning of
time, this feature is not even covered by the historical purposes of
the RIPE Database. Yet again showing that we don't understand how the
RIPE Database is used.

So can anyone say, with any certainty, if this feature is being used?

cheers
denis
co-chair DB-WG



>
> Nick
>