Hi denis, I am not sure if this feature is used or not however I think this is a very good reason to not go forward with a clean-up (at least until we have properly evaluated things). We will probably have to figure out some other way to deal with objects that are currently causing issues I think.
-Cynthia On Wed, Nov 30, 2022 at 3:27 PM denis walker via db-wg <db-wg@ripe.net> wrote: > > 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 > > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
