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

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 at ripe.net> wrote:
>
> 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
> >
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/