[routing-wg] Adding "::" notation to RIPE DB

Hi Sasha, Sander,

Thanks for your replies. Side note: I’m at DENOG next week if anyone wants to talk face to face.

I think there are three points that need to be addressed, and I think you are both referring to point number 3 (as I see it). I think we need to look at points 1 and 2 first.

1. Can the requested change even be made to the RIPE DB?
2. What would the impact of the change be on the RIPE DB?
3. What would be the impact of the change on 3rd party tools/services that interact with the RIPE DB?

Regarding 1:
I don’t know much about the back-end of the RIPE DB so I’m hoping some else can confirm, or someone from RIPE can provide an answer. I would assume “yes” is the answer though, it doesn’t sound like a major change to me.

Regarding 2:
I can think of two methods for implementing the proposed change. The first method is that AS-SETs and Route-Sets keep their existing name format like AS-EXAMPLE or RS-EXAMPLE, but the members field/key is updated to support both formats, “AS-EXAMPLE” and “SOURCE::AS-EXAMPLE”. This means that the members field/key in a parent AS-SET doesn’t contain the exact name of a child object, it would contain a source tag “RIPE::” followed by the child object name “AS-EXAMPLE”. The second method is that the format of AS-SETs and Route-Sets names are also modified, so that the objects can be named as either “RIPE::AS-EXAMPLE” or “AS-EXAMPLE”. This way the member field/key in a parent AS-SET will contain the exact name of the child object.

With method 1, it’s a change to the members field only, and both the old format “AS-EXAMPLE” and the new format “RIPE::AS-EXAMPLE” must be supported by the members field. Because the name of the AS-SET or Route-Set object is unchanged in the RIPE DB and still called “AS-EXAMPLE”, when querying the RIPE database one queries for AS-EXAMPLE, the same as one does today, there is no object called “RIPE::AS-EXAMPLE”. However, queries with a “RIPE::” tag could simply have the source tag stripped by the RIPE DB before the query is executed, in order to return the same object as a query without the source tag, to help with transition/adoption and user error.

With method 2 you’d have a lot of redundant information in the IRR DBs because (assuming people adopt the idea over time), all AS-SETs in RIPE would be called RIPE::AS-xxx and all AS-SETs in ARIN would be called ARIN::AS-xxx, and so on. It does have the advantage though that the name of a child AS-SET in the member field/key of a parent AS-SET is the exact name of the object as it is stored in the DB.

I’m leaning towards method 1, only changing the format of the members field/key, and not the name format of AS-SETs/Route-Sets in addition. I think there is no need to change the format of the AS-SET or Route-Set name field, if the RIPE DB can strip “RIPE::” from the front of an incoming query. The reason I prefer this is method, is that it allows for a gradual deployment. If we chose method 2 and I renamed my AS-SET from “AS-EXAMPLE” to “RIPE::AS-EXAMPLE”, every AS-SET which contains “AS-EXAMPLE” just became invalid (the member object “AS-EXAMPLE” no longer exists), and it would take months to identify all the AS-SETs containing my AS-SET and get them updated. Instead if we just update the format of the members field, people can update the members fields/keys in their own AS-SETs/Route-Sets so that all of their downstream members now contain the correct “SOURCE::” tag, at their own speed, without breaking anything within the RIPE DB directly, especially if RIPE can strip the “SOURCE::” query off incoming requests, then we maintain backwards compatibility on direct queries to the RIPE DB and we allow for gradual adoption as members update their AS-SETs.

Regardless of the technical method chosen there are also some other impacts; any RIPE DB  documentation needs to be updated, and maybe training courses/workshop materials will also need updating. Anything else non-technical?


Finally, regarding 3:
Again, I think this can be broken down into sub-problems. Firstly, I don’t think we should be trying extra hard to maintain backwards comparability with IRRd v2/v3. If one allows customer/user inertia and/or ineptitude to steer the ship, Windows XP would still be in wide spread use, IPv6 adoption would never become wide spread, and so on. At some point you you have so say, it is no longer “reasonable” to support these things, they are holding back progress for the masses, and we have to move forwards because we have issues not being resolved. I think introducing breaking changes is totally fine, they happen often, and there are methods to deal with them. We would need to ensure we take reasonable steps to triage any breaking changes.

Secondly, I have already had a PR accepted into bgpq4 (thanks to Job) which supports this “SOURCE::” format. You can use it now to specify which data source to use for the top level AS-SET, i.e. “bgpq4 RIPE::AS-EXAMPLE” will pull AS-EXAMPLE from RIPE. However, because the “SOURCE::” format is not supported in any RIR DBs today, the expansion of all the members in the AS-SET tree will fall back to the default data sources the IRRd server is using. But this already an improvement for operators. As a result of the PR, the code is already there, for every member bgpq4 will check for a “SOURCE::” tag and use that source if one is specified, it’s just they the tags aren’t there yet. Instead of using either of the recursive queries (“a!” or “!i,1”) bgpq4 in this mode, will query every object in the AS-SET tree individually so that the “SOURCE::” can be honoured (it performs “s!” then “i!” for each member in the tree).

I would be happy to work on a PR for IRRd which either adds a new recursive query type, something like the existing “a!” or “!i,1” but which also takes any “SOURCE::” tags into consideration, or work on a PR which updates the two aforementioned queries so that they take “SOURCE::” tags into consideration, so that this benefit is received by all users by default.

If we can work on a PR for IRRd to support this, then we could update IRRd first, then RIPE could implement the DB changes, and at this point nothing would break. Only when RIPE DB users start to update their AS-SET members field and add a source tag would operators with legacy IRRd versions start to have issues, and then they would have to update. But before that happens we can publicise the up coming changes and give people a fair warning, we can try to provide resources on what the changes are, why they are beneficial, and why it’s in their interest to upgrade instead of complaining. As I said above, denying progress to many networks in favour of a few slower networks is not ideal. This issue of not being able to specify a “SOURCE::” tag is causing operational issues for various networks right now, so denying them a resolution would need a very good level of justification in my opinion.

Thank you all for your time.

Kind regards,
James Bensley (he/him)
Network Team
Inter.link GmbH

Boxhagener Str. 80, 10245 Berlin, Germany
Email: hello at inter.link,
Phone: +49-030-577123821
Registry: Local court Charlottenburg, HRB 138876
Managing directors: Marc Korthaus, Theo Voss