On Thu, 24 Nov 2022 at 16:13, Nick Hilliard via db-wg <db-wg@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