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

Hi everyone,

I'm a little late to the show, but here's my 0.02 EUR regarding this issue:

First, I find welcome the patch that allows bgpq4 to directly use the IRR::SET syntax. I would add that the next addition would be SET at IRR, which is another form that is accepted by and used in PeeringDB. If my memory is good, there was even one of the releases, a few years ago, when the PeeringDB team tried to make the use of one of the 2 above-mentioned forms mandatory.

The main issue here is "which IRR(s) should I use to expand a specific set", and if using multiple IRRs, in which order.
 - my preference, enforced by existing documentation (randomly, the bgpq4 one) indicates that one should prefer RIR-based authoritative IRRs. However, you end up quite rapidly in a bad position, since a number of peering-friendly networks reply on RADB or ALTDB.
 - you can choose to use "RADB first" (or even ATLDB) as source, but you will end up missing data. We already did.
 - you may also decide that you want to do some form or RIR-lock, only to en up with ASNs that use a set declared in an IRR different of the RIR of their ASN. Missing or incorrect data at the end.

In any case, you need better information on which IRRs to use, and in which order. Explicit specification of the IRR is one (good) form of solving this problem. 

On Wed, Nov 9, 2022, at 17:42, James Bensley wrote:

> 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.

Not only RIPE DB. There's also irrd, but I see that Sasha, as a maintainer, is already taking part to the discussion.

> 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”.

I would stop here, you already mentioned the drawbacks for the second method.

> 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.

Actually no (or not much), and besides this is the exact problem that IRR prefixing (or suffixing) is trying to solve. You have your peer with AS-CompanyX in RIPE (by "Company X SAS/FR/EU"), but there is another AS-CompanyX in RADB, used by "Company X Ltd/CA/US". No relation between, just happen to be the the same (or almost the same) name. And inter-RIR/inter-IRR objects are a reality.

> I’m leaning towards method 1, only changing the format of the members 

+1

> 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.

What would need to be defined is how the expansion of an IRR::SET should be done:
 - use the specified IRR for the set only, any additional members not using an explicit IRR will be expanded with the default or user-specified source list
 - use the specifier IRR for the set and all its members that do not explicitly specify an IRR.

In any case, when expanding a a SET, you have a member specifying an explicit IRR, you expand that member with the specified IRR.

Maybe an option/distinct query for each of the two possibilities ?

> 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. 

Given the ressource requirements of irrd4, that would not be very fun for them, but that's life....

> 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.

Not sure it's related to this discussion, but some (not very) funny things happened about 2-3 weeks ago, exactly because of the lack of explicit IRR specification.

-- 
Radu-Adrian FEURDEAN