Adding "::" notation to RIPE DB
Dear Working Group, I want to discuss a proposal to change the format of the "members" field of the AS-SET and Route-Set objects in the RIPE DB. I do not know what the process is for this so please guide me if this is the wrong place or method for raising this kind of proposal. Specifically, I want to discuss adding supported for the "::" source notation in the "members" field of an AS-SET or Route-Set object. Currently my AS-SET might look like the following when the tree is fully expanded: as-set: AS4200000011:AS-EXAMPLE-11 -> members: AS4200000011 -> members: AS4200000012:AS-EXAMPLE-12 - -> members: AS4200000012 - -> members: AS4200000021 -> members: AS4200000013:AS-EXAMPLE-13 - -> members: AS4200000013 - -> members: AS4200000022:AS-EXAMPLE-22 - - -> members: AS4200000031 When a peer or upstream is building a prefix lists towards me (AS4200000011), they need to generate a prefix list for my entire AS tree/route set tree. Historically, objects (AS-Sets/Roue-Sets) with the same name have been registered in different IRR databases. This causes a problem because it's not clear which IRR DB the object should be pulled from. When building a prefix list for a tree, some of the object are pulled from the wrong IRR DB. For example, AS-GOOGLE currently exists in the RIPE and APNIC IRR DBs, but the AS-SET in both DBs is empty: $whois -h whois.ripe.net AS-GOOGLE | grep -E "as-set|members" as-set: AS-GOOGLE $whois -h whois.apnic.net AS-GOOGLE | grep -E "as-set|members" as-set: AS-GOOGLE As per Google's peeringdb page, the correct data source for their AS-SET is RADB: https://www.peeringdb.com/net/433 $whois -h whois.radb.net AS-GOOGLE | grep -E "as-set|members" as-set: AS-GOOGLE members: AS11344 members: AS13949 members: AS15169 ... The above query to RADB produces the correct information. However, often when building a prefix set to a peer, the wrong object is used and an empty prefix list is generated, or the wrong prefix list, and the AS-SET may contain other false members too. Historically people have registered objects with the same AS-SET or Route-Set name in different IRR DBs, both by accident and maliciously, and this practice continues today. It is very difficult to get these issues resolved in a timely manner and the result on daily operations is that operators can't establish a new peering session with a customer/peer/upstream, or update a prefix list facing an existing customer/peer/upstream, because we can't generate the prefix list. We need to be able to signal which IRR DB is authoritative for an AS-SET or Route-Set object. For this reason I ask, what it would take to allow the use of the "::" indicator in the "members" field of an AS-SET and Route-Set so that in my own AS-SET I can specify the correct source for the direct members (my customers), and in their AS-SET's they can specify the correct source for each of their customers, and so on, all the way down the tree, so that I end up with my AS-SET tree looking like the following when fully expanded: -> members: RIPE::AS4200000011 -> members: RADB::AS4200000012:AS-EXAMPLE-12 - -> members: RIPE::AS4200000012 - -> members: ARIN::AS4200000021 -> members: ARIN::AS4200000013:AS-EXAMPLE-13 - -> members: APNIC::AS4200000013 - -> members: ARIN::AS4200000022:AS-EXAMPLE-22 - - -> members: RADB::AS4200000031 Kind regards, James Bensley (he/him) Network Team Inter.link GmbH Boxhagener Str. 80, 10245 Berlin, Germany Email: hello@inter.link, Phone: +49-030-577123821 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss
Hello James (this time while keeping the list in cc), On 7 Nov 2022, at 10:01, James Bensley wrote:>
Specifically, I want to discuss adding supported for the "::" source notation in the "members" field of an AS-SET or Route-Set object. […]
Thanks for bringing this up. I agree with your problem statement - I have been thinking about this before. In theory, you propose a good solution that already seems current practice here and there. However, there is a big catch. For context, I am the developer and maintainer of IRRD v4, which is currently used by the NTTCOM, ARIN, LACNIC, TC, IDNIC and LEVEL3 authoritative registries along with local deployments that run local mirrors. A few other registries run older versions of IRRD. I am not an IRR operator myself.
$whois -h whois.radb.net AS-GOOGLE | grep -E "as-set|members" […] The above query to RADB produces the correct information. [...] For this reason I ask, what it would take to allow the use of the "::" indicator in the "members" field of an AS-SET and Route-Set so that in my own AS-SET I can specify the correct source for the direct members (my customers) […]
Many users do not query AS sets like this, but rather have IRRD do the set resolving, with queries like `!a` [1] that returns all unique prefixes originated by all ASes in an AS set. This is much more efficient, and tools like bgpq4 use this feature if available. If we adopt your proposal, and the IRR becomes a mix of prefixed (RIPE::AS-DEMO) and non-prefixes AS set names (AS-DEMO), IRRD will interpret prefixed names as the full name, will fail to find any set named RIPE::AS-DEMO, and set resolving will be incomplete. Existing code simply won’t have any understanding of the prefix, and without mitigation, we risk making AS set resolving more broken. You could work around this by adding the prefixed and non-prefixed name, but that will produce inconsistent results depending on a prefix-aware set resolver, and risks duplicate records getting out of sync. Other than that, the only way I see is to first enable support for this in common AS set resolver code, and only support its use in objects once resolver updates are widely deployed. But that will take quite some time. It’s not terribly complex to add support to IRRD v4, but then we will need all operators to upgrade, and some are still on v2/v3. There will also be custom internal set resolving code in some organisations. Sasha [1] https://irrd.readthedocs.io/en/stable/users/queries/whois/#irrd-style-querie...
Hi Sasha,
You could work around this by adding the prefixed and non-prefixed name, but that will produce inconsistent results depending on a prefix-aware set resolver, and risks duplicate records getting out of sync.
Maybe something could be automated on the server side (which in this case would mean RIPE DB), but I have the feeling that this would get ugly pretty fast (add a new qualified-member: attribute which auto-generates a member: attribute?).
Other than that, the only way I see is to first enable support for this in common AS set resolver code, and only support its use in objects once resolver updates are widely deployed. But that will take quite some time. It’s not terribly complex to add support to IRRD v4, but then we will need all operators to upgrade, and some are still on v2/v3. There will also be custom internal set resolving code in some organisations.
This would definitely be the cleanest way forward, but as you say it will take a long time (decades?)… I’m torn between the quick solution and the clean solution. Does anybody have better ideas? Cheers, Sander
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@inter.link, Phone: +49-030-577123821 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss
James Bensley wrote on Wednesday, November 9, 2022 5:42 PM:
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 upcoming changes and give people a fair warning, we can try to provide resources on what the changes are, why they are beneficial [...]
How many *years* you think is a "fair" warning before others have to accept, that their own tooling breaks? (There's more than bgpq4 and IRRd and code doing !i queries). Two, six or more than ten? Don't get me wrong, I like the idea to ensure, the right AS-SET is being used and I know the pain, if not. Getting AS-SETs unique across all RRs or being able to clearly identify the right RR to use would be great. (Even though I would assume adoption might take -after the warning period- still many years for a significant amount of updated AS-SETs to be seen.)
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.
Breaking things just "because it helps" might not be the best choice. And your example about XP is not right. Because your proposal comes closer to turn off v4 (before a v6 stack was available for XP). I think we should try extra hard to maintain backward compatibility and only if most agree, there's no other way and breaking things is the only way to go forward and this saves the world, then it should/might happen. I think goal you like to achieve, the approach likely will not materialize soon or at all. There might be and should be other ways ... Markus
I would look at the precedent of things like RIPE-NONAUTH for time and duration. Sent via RFC1925 compliant device
On Nov 9, 2022, at 8:02 PM, Netmaster (exAS286) <netmaster@as286.net> wrote:
James Bensley wrote on Wednesday, November 9, 2022 5:42 PM:
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 upcoming changes and give people a fair warning, we can try to provide resources on what the changes are, why they are beneficial [...]
How many *years* you think is a "fair" warning before others have to accept, that their own tooling breaks? (There's more than bgpq4 and IRRd and code doing !i queries).
Two, six or more than ten?
Don't get me wrong, I like the idea to ensure, the right AS-SET is being used and I know the pain, if not. Getting AS-SETs unique across all RRs or being able to clearly identify the right RR to use would be great. (Even though I would assume adoption might take -after the warning period- still many years for a significant amount of updated AS-SETs to be seen.)
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.
Breaking things just "because it helps" might not be the best choice. And your example about XP is not right. Because your proposal comes closer to turn off v4 (before a v6 stack was available for XP).
I think we should try extra hard to maintain backward compatibility and only if most agree, there's no other way and breaking things is the only way to go forward and this saves the world, then it should/might happen.
I think goal you like to achieve, the approach likely will not materialize soon or at all. There might be and should be other ways ...
Markus
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/routing-wg
Jared Mauch wrote on Wednesday, November 9, 2022 10:08 PM:
I would look at the precedent of things like RIPE-NONAUTH for time and duration.
I wouldn't. RIPE-NOAUTH was more of a DB cleanup and likely not broke any tools. Introducing '::' however might/will break tools following RFC2280/RFC2622 being read as (and mostly implemented/enforced like this) "a single colon between set names and AS numbers" (hmmm, it states 'separated by colons ":"', but examples kind of imply the "single between"). Markus
On Wed, Nov 09, 2022 at 10:31:06PM +0000, Netmaster (exAS286) wrote:
Jared Mauch wrote on Wednesday, November 9, 2022 10:08 PM:
I would look at the precedent of things like RIPE-NONAUTH for time and duration.
I wouldn't. RIPE-NOAUTH was more of a DB cleanup and likely not broke any tools.
I'm saying use the time window of that migration, so announce and then over that time be able to do it. I'm not saying everyone will upgrade or listen, but also not everyone will until something is actually broken either.
Introducing '::' however might/will break tools following RFC2280/RFC2622 being read as (and mostly implemented/enforced like this) "a single colon between set names and AS numbers" (hmmm, it states 'separated by colons ":"', but examples kind of imply the "single between").
The nice thing is moving to the ASN removes the possibility of being unique, I recently moved from AS-NETHER to AS267 to reduce the chance of conflict. We should also likely move from AS-AKAMAI to AS20940:GLOBAL or something else. Moving forward shouldn't scare people if we have a good notification regime. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Jared Mauch wrote on Wednesday, November 9, 2022 11:39 PM
On Wed, Nov 09, 2022 at 10:31:06PM +0000, Netmaster (exAS286) wrote:
Introducing '::' however might/will break tools following RFC2280/RFC2622 being read as (and mostly implemented/enforced like this) "a single colon between set names and AS numbers" (hmmm, it states 'separated by colons ":"', but examples kind of imply the "single between").
The nice thing is moving to the ASN removes the possibility of being unique, I recently moved from AS-NETHER to AS267 to reduce the chance of conflict. We should also likely move from AS-AKAMAI to AS20940:GLOBAL or something else.
I'm lost. AS20940:GLOBAL wouldn't be a valid AS-SET name. AS20940:AS-GLOBAL? Well, with the requirement of the AS-SET names like ASx:AS-SET requiring mnt-by of ASx, less likely "by accident" dups showing up. But it doesn't protect *evil* person adding ASx to an "open" RR and adding a bad ASx:AS-SET there. <constructive> It's an ugly way, but adding some semantics to the AS-SET names to point to the right RR, wouldn't break existing tooling and could be picked up by smarter tools. Like ASx:AS-SET-SOURCE-RIPE only being valid if source if RIPE. I have said it's ugly, haven't I? And it's not a proposal to solve the problem (as e.g. if someone would have missed this semantical layer and would register whyever AS1:AS-FOOBAR-SOURCE-RIPE in RADB ...) Markus
Maybe we can add some standard mechanism to identifiy the supported "features" by the IRR server? So client before sending the request can figure out whether the server supports source-tagged as-sets (like bgpq4 now checks if the server supports !a queries). Then the client can add some "flag" in the query that it is willing to receive source-tagged as-sets. On the server side we can strip source prefixes in the reply if the client did not identify its will to receive them. In that case legacy tools should not brake. On Thu, Nov 10, 2022, 06:44 Netmaster (exAS286) <netmaster@as286.net> wrote:
Jared Mauch wrote on Wednesday, November 9, 2022 11:39 PM
On Wed, Nov 09, 2022 at 10:31:06PM +0000, Netmaster (exAS286) wrote:
Introducing '::' however might/will break tools following RFC2280/RFC2622 being read as (and mostly implemented/enforced like this) "a single
colon > > between set names and AS numbers" (hmmm, it states 'separated by colons ":"', > > but examples kind of imply the "single between").
The nice thing is moving to the ASN removes the possibility of being unique, I recently moved from AS-NETHER to AS267 to reduce the chance of conflict. We should also likely move from AS-AKAMAI to AS20940:GLOBAL or something else.
I'm lost. AS20940:GLOBAL wouldn't be a valid AS-SET name. AS20940:AS-GLOBAL?
Well, with the requirement of the AS-SET names like ASx:AS-SET requiring mnt-by of ASx, less likely "by accident" dups showing up.
But it doesn't protect *evil* person adding ASx to an "open" RR and adding a bad ASx:AS-SET there.
<constructive> It's an ugly way, but adding some semantics to the AS-SET names to point to the right RR, wouldn't break existing tooling and could be picked up by smarter tools. Like ASx:AS-SET-SOURCE-RIPE only being valid if source if RIPE. I have said it's ugly, haven't I? And it's not a proposal to solve the problem (as e.g. if someone would have missed this semantical layer and would register whyever AS1:AS-FOOBAR-SOURCE-RIPE in RADB ...)
Markus
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/routing-wg
Alexander Zubkov wrote on Thursday, November 10, 2022 8:07 AM:
Maybe we can add some standard mechanism to identifiy the supported "features" by the IRR server? So client before sending the request can figure out whether the server supports source-tagged as-sets (like bgpq4 now checks if the server supports !a queries). Then the client can add some "flag" in the query that it is willing to receive source-tagged as-sets. On the server side we can strip source prefixes in the reply if the client did not identify its will to receive them. In that case legacy tools should not brake.
And not to forget to add this "feature probing" to NRTM sessions (and likely other places). Still, by introducing "::", you might change the way a set name is defined in RFC2280/RFC2622 ... (might, because most of us likely read it as 'a single ":" separates AS numbers and set names' based on the examples). Markus
On 10.11.2022 06:44, Netmaster (exAS286) wrote:
Jared Mauch wrote on Wednesday, November 9, 2022 11:39 PM
On Wed, Nov 09, 2022 at 10:31:06PM +0000, Netmaster (exAS286) wrote:
Introducing '::' however might/will break tools following RFC2280/RFC2622 being read as (and mostly implemented/enforced like this) "a single colon between set names and AS numbers" (hmmm, it states 'separated by colons ":"', but examples kind of imply the "single between").
The nice thing is moving to the ASN removes the possibility of being unique, I recently moved from AS-NETHER to AS267 to reduce the chance of conflict. We should also likely move from AS-AKAMAI to AS20940:GLOBAL or something else.
I'm lost. AS20940:GLOBAL wouldn't be a valid AS-SET name. AS20940:AS-GLOBAL?
Well, with the requirement of the AS-SET names like ASx:AS-SET requiring mnt-by of ASx, less likely "by accident" dups showing up.
Well, actually, you're never safe from shooting yourself in the foot.
But it doesn't protect *evil* person adding ASx to an "open" RR and adding a bad ASx:AS-SET there.
Isn't there only a limited number of "trusted" IRRs? Hence, moving to ASx:AS-SET would be a huge step forward. Arnold
Arnold Nipper wrote on Thursday, November 10, 2022 2:14 PM:
Isn't there only a limited number of "trusted" IRRs? Hence, moving to ASx:AS-SET would be a huge step forward.
Would you trust e.g. RADB and/or NTTCOM? If not, you likely miss quite some information. If you do ... who's the one owning AS517 in NTTCOM, and who's the one owning it in RIPE? [SCNR using AS517 for that ...] But it might be a way to go - which RR is authorized to hold the aut-num ... Markus
On 10.11.2022 15:31, Netmaster (exAS286) wrote:
Arnold Nipper wrote on Thursday, November 10, 2022 2:14 PM:
Isn't there only a limited number of "trusted" IRRs? Hence, moving to ASx:AS-SET would be a huge step forward.
Would you trust e.g. RADB and/or NTTCOM? If not, you likely miss quite some information. If you do ... who's the one owning AS517 in NTTCOM, and who's the one owning it in RIPE? [SCNR using AS517 for that ...]
Hmmm ... isn't this information [0] trustworthy anymore? Arnold, and please give me back *my* ASN :D [0] https://www.irr.net/docs/list.html
Hi, See my reply below. On Thu, Nov 10, 2022 at 4:32 PM Arnold Nipper <arnold.nipper@de-cix.net> wrote:
On 10.11.2022 15:31, Netmaster (exAS286) wrote:
Arnold Nipper wrote on Thursday, November 10, 2022 2:14 PM:
Isn't there only a limited number of "trusted" IRRs? Hence, moving to ASx:AS-SET would be a huge step forward.
Would you trust e.g. RADB and/or NTTCOM? If not, you likely miss quite some information. If you do ... who's the one owning AS517 in NTTCOM, and who's the one owning it in RIPE? [SCNR using AS517 for that ...]
Hmmm ... isn't this information [0] trustworthy anymore?
Arnold, and please give me back *my* ASN :D
That list still contains open registries like ALTDB and RADB. One of my upstreams added a route object in RADB without my consent. (It was identical to one in the RIPE DB that I created so not a huge issue in this case) In my opinion, at this point, when all RIRs have their own authoritative IRR databases requiring authorization*, we should only really consider those** as authoritative. I see very limited purpose for any other IRR DB. Sure there are still plenty of objects in those other IRRs but those objects should probably be migrated over to the relevant RIR managed IRRs. Slightly off-topic maybe but I will also say that personally I see IRR and especially as-sets/route-sets as a lost cause and I'm not sure if it is worth trying to fix it. To me it seems like a much better idea to just spend our effort on putting in the features in RPKI to make it so it can replace IRR entirely. As others have pointed out, it could very well take a very long time to get widespread support for a feature like this. These tweets[1] from Ben Cox who many of you might know really highlights another issue with recursive as-sets. (Essentially, there are as-sets that are recursively so big as to include more AS's than exist in the DFZ. To me feels like you might as well just ignore the filter entirely and just always accept in such a case.) * = I'm not 100% certain if LACNIC's IRR DB requires authorization but I hope it does. ** = Possibly also NIRs if they run their own IRR DBs that make sure that only the orgs holding the resources can create objects for them. [1]: https://twitter.com/Benjojo12/status/1578417574790205441 -Cynthia
Hi, On Fri, 11 Nov 2022, Cynthia Revström via routing-wg wrote:
In my opinion, at this point, when all RIRs have their own authoritative IRR databases requiring authorization*, we should only really consider those** as authoritative.
Strong support!!! Which RIR IRR databases are at this point *still* without mandatory authorization?
I see very limited purpose for any other IRR DB.
Unless one loves bogus IRR information, of course :-))
Sure there are still plenty of objects in those other IRRs but those objects should probably be migrated over to the relevant RIR managed IRRs.
Yes, precisely! If they are not bogus! :-)) (...) Regards, Carlos
From: routing-wg <routing-wg-bounces@ripe.net> on behalf of Cynthia Revström via routing-wg <routing-wg@ripe.net> Sent: 11 November 2022 01:54 To: routing-wg@ripe.net Subject: Re: [routing-wg] Adding "::" notation to RIPE DB ... These tweets[1] from Ben Cox who many of you might know really highlights another issue with recursive as-sets. (Essentially, there are as-sets that are recursively so big as to include more AS's than exist in the DFZ. To me feels like you might as well just ignore the filter entirely and just always accept in such a case.) [1]: https://twitter.com/Benjojo12/status/1578417574790205441 -Cynthia ________________________________________ Hi Cynthia, AFAICT this is expected and valid behaviour. There will always be more ASNs registered than actually being used. Also, there is no one DFZ view. It looks different in different parts of the world/Internet, some of the ASNs will be visible only in certain locations. This is normal operating procedure in my opinion. Cheers, James.
From: Netmaster (exAS286) <netmaster@as286.net> Sent: 09 November 2022 21:01 To: James Bensley; routing-wg@ripe.net Subject: RE: [routing-wg] Adding "::" notation to RIPE DB
James Bensley wrote on Wednesday, November 9, 2022 5:42 PM:
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 upcoming changes and give people a fair warning, we can try to provide resources on what the changes are, why they are beneficial [...]
How many *years* you think is a "fair" warning before others have to accept, that their own tooling breaks? (There's more than bgpq4 and IRRd and code doing !i queries).
Two, six or more than ten?
Don't get me wrong, I like the idea to ensure, the right AS-SET is being used and I know the pain, if not. Getting AS-SETs unique across all RRs or being able to clearly identify the right RR to use would be great. (Even though I would assume adoption might take -after the warning period- still many years for a significant amount of updated AS-SETs to be seen.) ... Breaking things just "because it helps" might not be the best choice ... I think we should try extra hard to maintain backward compatibility and only if most agree, there's no other way and breaking things is the only way to go forward and this saves the world, then it should/might happen.
Thanks for your reply Markus. I don't see how ten years is the correct order of magnitude here, or any justification for why this needs to "save the world"? Do you have some justification for this claim? I will provide some thoughts in the opposite direction: 1. We're not talking about updating something like a life support system or auto pilot system which can result in an immediate loss of life. We're talking about updating some software which is important to the daily operations of network operators, which an operator could live without if it totally exploded (it might be painful, even extremely painful, but they could, and that is an important difference). 2. Software related to the daily operation of the Internet already breaks from time to time, and most operators are able to implement temporary fixes until long term ones can be implemented. For example, we already have the current problem being discussed, that rogue AS-SETs result in invalid prefix lists being generated. This means I can't update the prefix list facing an existing peer automatically, but it doesn't mean the peering stops working or that my whole AS goes offline. The peering stays up, but with the existing prefix list, which I can update manually if they announce/withdraw something before we can fix the automation tooling. Equally, I can't generate prefix lists for new peers due to rouge AS-SETs, but I can set a prefix limit for the session, apply some basic AS path checks like no Tier 1 ASNs, no bogons, check RPKI, and so no. If they are small enough I can even write the prefix by hand. It's not ideal, but my network doesn't stop working and nor do my peerings. We’re talking about similar impact but due to reversed circumstances: a network can’t process IRR data because the response contains a source tag, not because it is missing a source tag. 3. As I've already said, we wouldn't actually breaking anything if we were to implement the initially [1] proposed change. Things start to break IF, AND ONLY IF an operator updates their AS-SET or Route-Set to use the "::" notation AND their peer or upstream doesn't update their tooling. This networks could actually notify their upstreams/peers proactively and say “hey, we’re going to add source notation to our IRR data in 3 months, please prepare for this”. 4. You seem to be focusing on the operator who doesn't update their tooling as being the victim. If a network makes use of the the "::" notation in their AS-SET, and their upstream who runs IRRd v2 can no longer automatically update their prefix lists towards that customer network, then I think the customer is the victim here. The customer is paying the upstream for a service and the upstream isn't guaranteeing that they are actually using the correct information to deliver the service, even though it is a option available to them. At this point, IMO, the customer network should be pressuring the upstream to upgrade their IRRd. [1] My initial proposal was to make this suggestion supported by default so that as many networks as possible get the benefit of this suggestion. However, a non-breaking method has been proposed:
From: Alexander Zubkov <green@qrator.net> Sent: 10 November 2022 08:07 To: Netmaster (exAS286) Cc: Jared Mauch; James Bensley; routing-wg@ripe.net Subject: Re: [routing-wg] Adding "::" notation to RIPE DB
Maybe we can add some standard mechanism to identifiy the supported "features" by the IRR > server? So client before sending the request can figure out whether the server supports source-tagged as-sets (like bgpq4 now checks if the server supports !a queries). Then the client can add some "flag" in the query that it is willing to receive source-tagged as-sets. On the server side we can strip source prefixes in the reply if the client did not identify its will to receive them. In that case legacy tools should not brake.
Refactoring this slightly: we could add a new non-default query type (to the RIPE DB + whois client, and to IRRd), and if clients don't explicitly use the new query, source tags are stripped from the reply data. This way the client and server don't both need to track if the other supports source tags. I can see two problems though: firstly, this would never become the default, unless we have a due date after which point source tags become included in the default query types of these tools. Secondly, how should the objects be represented in the RIPE DB? If I have a member in my AS-SET which is “RIPE::AS-65534:AS-EXAMPLE” which is an object in the RIPE DB, and a legacy whois client queries the RIPE DB for my AS-SET, they would get the following in the list of members “AS-65535:AS-EXAMPLE”, which isn’t actually an object in the RIPE DB. When the same legacy client then tries to query for that specific object, RIPE would need to know to look for both “AS-65534:AS-EXAMPLE” and “RIPE::AS-65534-AS-EXAMPLE”. The same applies when creating or renaming objects, the RIPE DB would need to know that if I create an object called “RIPE::AS-65534:AS-EXAMPLE” no one else is allowed to create “AS-65534:AS-EXAMPLE” and vice versa. Are there more problems I’ve missed if the RIPE DB returns a different responses to different clients? Cheers, James.
I think the idea is that RIPE::AS-65534:AS-EXAMPLE addresses AS-65534:AS-EXAMPLE object in the RIPE database. Is there reasons to allow to have both RIPE::AS-65534:AS-EXAMPLE and AS-65534:AS-EXAMPLE in the single RIPE database? On Sun, Nov 13, 2022 at 1:50 PM James Bensley <james@inter.link> wrote:
From: Netmaster (exAS286) <netmaster@as286.net> Sent: 09 November 2022 21:01 To: James Bensley; routing-wg@ripe.net Subject: RE: [routing-wg] Adding "::" notation to RIPE DB
James Bensley wrote on Wednesday, November 9, 2022 5:42 PM:
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 upcoming changes and give people a fair warning, we can try to provide resources on what the changes are, why they are beneficial [...]
How many *years* you think is a "fair" warning before others have to accept, that their own tooling breaks? (There's more than bgpq4 and IRRd and code doing !i queries).
Two, six or more than ten?
Don't get me wrong, I like the idea to ensure, the right AS-SET is being used and I know the pain, if not. Getting AS-SETs unique across all RRs or being able to clearly identify the right RR to use would be great. (Even though I would assume adoption might take -after the warning period- still many years for a significant amount of updated AS-SETs to be seen.) ... Breaking things just "because it helps" might not be the best choice ... I think we should try extra hard to maintain backward compatibility and only if most agree, there's no other way and breaking things is the only way to go forward and this saves the world, then it should/might happen.
Thanks for your reply Markus.
I don't see how ten years is the correct order of magnitude here, or any justification for why this needs to "save the world"? Do you have some justification for this claim?
I will provide some thoughts in the opposite direction:
1. We're not talking about updating something like a life support system or auto pilot system which can result in an immediate loss of life. We're talking about updating some software which is important to the daily operations of network operators, which an operator could live without if it totally exploded (it might be painful, even extremely painful, but they could, and that is an important difference).
2. Software related to the daily operation of the Internet already breaks from time to time, and most operators are able to implement temporary fixes until long term ones can be implemented. For example, we already have the current problem being discussed, that rogue AS-SETs result in invalid prefix lists being generated. This means I can't update the prefix list facing an existing peer automatically, but it doesn't mean the peering stops working or that my whole AS goes offline. The peering stays up, but with the existing prefix list, which I can update manually if they announce/withdraw something before we can fix the automation tooling. Equally, I can't generate prefix lists for new peers due to rouge AS-SETs, but I can set a prefix limit for the session, apply some basic AS path checks like no Tier 1 ASNs, no bogons, check RPKI, and so no. If they are small enough I can even write the prefix by hand. It's not ideal, but my network doesn't stop working and nor do my peerings. We’re talking about similar impact but due to reversed circumstances: a network can’t process IRR data because the response contains a source tag, not because it is missing a source tag.
3. As I've already said, we wouldn't actually breaking anything if we were to implement the initially [1] proposed change. Things start to break IF, AND ONLY IF an operator updates their AS-SET or Route-Set to use the "::" notation AND their peer or upstream doesn't update their tooling. This networks could actually notify their upstreams/peers proactively and say “hey, we’re going to add source notation to our IRR data in 3 months, please prepare for this”.
4. You seem to be focusing on the operator who doesn't update their tooling as being the victim. If a network makes use of the the "::" notation in their AS-SET, and their upstream who runs IRRd v2 can no longer automatically update their prefix lists towards that customer network, then I think the customer is the victim here. The customer is paying the upstream for a service and the upstream isn't guaranteeing that they are actually using the correct information to deliver the service, even though it is a option available to them. At this point, IMO, the customer network should be pressuring the upstream to upgrade their IRRd.
[1] My initial proposal was to make this suggestion supported by default so that as many networks as possible get the benefit of this suggestion. However, a non-breaking method has been proposed:
From: Alexander Zubkov <green@qrator.net> Sent: 10 November 2022 08:07 To: Netmaster (exAS286) Cc: Jared Mauch; James Bensley; routing-wg@ripe.net Subject: Re: [routing-wg] Adding "::" notation to RIPE DB
Maybe we can add some standard mechanism to identifiy the supported "features" by the IRR > server? So client before sending the request can figure out whether the server supports source-tagged as-sets (like bgpq4 now checks if the server supports !a queries). Then the client can add some "flag" in the query that it is willing to receive source-tagged as-sets. On the server side we can strip source prefixes in the reply if the client did not identify its will to receive them. In that case legacy tools should not brake.
Refactoring this slightly: we could add a new non-default query type (to the RIPE DB + whois client, and to IRRd), and if clients don't explicitly use the new query, source tags are stripped from the reply data. This way the client and server don't both need to track if the other supports source tags.
I can see two problems though: firstly, this would never become the default, unless we have a due date after which point source tags become included in the default query types of these tools.
Secondly, how should the objects be represented in the RIPE DB? If I have a member in my AS-SET which is “RIPE::AS-65534:AS-EXAMPLE” which is an object in the RIPE DB, and a legacy whois client queries the RIPE DB for my AS-SET, they would get the following in the list of members “AS-65535:AS-EXAMPLE”, which isn’t actually an object in the RIPE DB. When the same legacy client then tries to query for that specific object, RIPE would need to know to look for both “AS-65534:AS-EXAMPLE” and “RIPE::AS-65534-AS-EXAMPLE”. The same applies when creating or renaming objects, the RIPE DB would need to know that if I create an object called “RIPE::AS-65534:AS-EXAMPLE” no one else is allowed to create “AS-65534:AS-EXAMPLE” and vice versa. Are there more problems I’ve missed if the RIPE DB returns a different responses to different clients?
Cheers, James. --
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/routing-wg
From: Alexander Zubkov <green@qrator.net> Sent: 13 November 2022 14:12 To: James Bensley Cc: Netmaster (exAS286); routing-wg@ripe.net Subject: Re: [routing-wg] Adding "::" notation to RIPE DB I think the idea is that RIPE::AS-65534:AS-EXAMPLE addresses AS-65534:AS-EXAMPLE object in the RIPE database. Is there reasons to allow to have both RIPE::AS-65534:AS-EXAMPLE and AS-65534:AS-EXAMPLE in the single RIPE database? ________________________________________ Hi Alexander, That is what I'm saying: I agree, one name needs to point to the other, so that we don't have two objects in the database, only one object. I just wasn't clear about how the pointing would work and if it would affect anything else in the DB beyond get request (like create or delete requests). But I guess there will only every be objects called "AS-65534:AS-EXAMPLE" in the DB (as per my original email to the list), "RIPE::" would be stripped from the front of the query if present, and stripped from responses if the query comes from a legacy client (as per your suggestion). Cheers, James.
Hi James, I think most of us agree, that the situation is more than unsatisfying and solving this -either on the current IRRs "setup" or with something new- would be very beneficial. However, I don't think, breaking current RFCs - and I think the RR:: prefix does violate RFC2622 - is a way to go forward. It's like imple- menting software deviating from specs and never updating these. Putting a software in place, which comes with "features", which - if used - might break other's tooling, is IMHO not the way we should move forward. [The "only if client explicitly requests it"-way would be then preferred, if the underlaying specs allow it.] Just having RIPE DB supporting it, will at the end not solve the issue as it's a global problem. Sure, one needs to start somewhere ... but again, it should be a more "formal" way, others more likely will fol- low. There are more places than as-set objects set names can be used. And there's more than just people querying IRRd. What about DB dumps, what about NRTM of/to other IRRs? Coming back to your original question "what it would take to allow the use of the "::" indicator in the "members" field of an AS-SET and Route-Set so that in my own AS-SET I can specify the correct source for the direct members": I would say, get RFC2622 updated. And I fear, likely this will not going to happen very soon or fast or maybe not at all, as the new notation is not backward compatible. Markus !TOFU! -----Original Message----- From: James Bensley <james@inter.link> Sent: Sunday, November 13, 2022 1:50 PM To: Netmaster (exAS286) <netmaster@as286.net>; routing-wg@ripe.net Subject: Re: [routing-wg] Adding "::" notation to RIPE DB From: Netmaster (exAS286) <netmaster@as286.net> Sent: 09 November 2022 21:01 To: James Bensley; routing-wg@ripe.net Subject: RE: [routing-wg] Adding "::" notation to RIPE DB
James Bensley wrote on Wednesday, November 9, 2022 5:42 PM:
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 upcoming changes and give people a fair warning, we can try to provide resources on what the changes are, why they are beneficial [...]
How many *years* you think is a "fair" warning before others have to accept, that their own tooling breaks? (There's more than bgpq4 and IRRd and code doing !i queries).
Two, six or more than ten?
Don't get me wrong, I like the idea to ensure, the right AS-SET is being used and I know the pain, if not. Getting AS-SETs unique across all RRs or being able to clearly identify the right RR to use would be great. (Even though I would assume adoption might take -after the warning period- still many years for a significant amount of updated AS-SETs to be seen.) ... Breaking things just "because it helps" might not be the best choice ... I think we should try extra hard to maintain backward compatibility and only if most agree, there's no other way and breaking things is the only way to go forward and this saves the world, then it should/might happen.
Thanks for your reply Markus. I don't see how ten years is the correct order of magnitude here, or any justification for why this needs to "save the world"? Do you have some justification for this claim? I will provide some thoughts in the opposite direction: 1. We're not talking about updating something like a life support system or auto pilot system which can result in an immediate loss of life. We're talking about updating some software which is important to the daily operations of network operators, which an operator could live without if it totally exploded (it might be painful, even extremely painful, but they could, and that is an important difference). 2. Software related to the daily operation of the Internet already breaks from time to time, and most operators are able to implement temporary fixes until long term ones can be implemented. For example, we already have the current problem being discussed, that rogue AS-SETs result in invalid prefix lists being generated. This means I can't update the prefix list facing an existing peer automatically, but it doesn't mean the peering stops working or that my whole AS goes offline. The peering stays up, but with the existing prefix list, which I can update manually if they announce/withdraw something before we can fix the automation tooling. Equally, I can't generate prefix lists for new peers due to rouge AS-SETs, but I can set a prefix limit for the session, apply some basic AS path checks like no Tier 1 ASNs, no bogons, check RPKI, and so no. If they are small enough I can even write the prefix by hand. It's not ideal, but my network doesn't stop working and nor do my peerings. We're talking about similar impact but due to reversed circumstances: a network can't process IRR data because the response contains a source tag, not because it is missing a source tag. 3. As I've already said, we wouldn't actually breaking anything if we were to implement the initially [1] proposed change. Things start to break IF, AND ONLY IF an operator updates their AS-SET or Route-Set to use the "::" notation AND their peer or upstream doesn't update their tooling. This networks could actually notify their upstreams/peers proactively and say "hey, we're going to add source notation to our IRR data in 3 months, please prepare for this". 4. You seem to be focusing on the operator who doesn't update their tooling as being the victim. If a network makes use of the the "::" notation in their AS-SET, and their upstream who runs IRRd v2 can no longer automatically update their prefix lists towards that customer network, then I think the customer is the victim here. The customer is paying the upstream for a service and the upstream isn't guaranteeing that they are actually using the correct information to deliver the service, even though it is a option available to them. At this point, IMO, the customer network should be pressuring the upstream to upgrade their IRRd. [1] My initial proposal was to make this suggestion supported by default so that as many networks as possible get the benefit of this suggestion. However, a non-breaking method has been proposed:
From: Alexander Zubkov <green@qrator.net> Sent: 10 November 2022 08:07 To: Netmaster (exAS286) Cc: Jared Mauch; James Bensley; routing-wg@ripe.net Subject: Re: [routing-wg] Adding "::" notation to RIPE DB
Maybe we can add some standard mechanism to identifiy the supported "features" by the IRR > server? So client before sending the request can figure out whether the server supports source-tagged as-sets (like bgpq4 now checks if the server supports !a queries). Then the client can add some "flag" in the query that it is willing to receive source-tagged as-sets. On the server side we can strip source prefixes in the reply if the client did not identify its will to receive them. In that case legacy tools should not brake.
Refactoring this slightly: we could add a new non-default query type (to the RIPE DB + whois client, and to IRRd), and if clients don't explicitly use the new query, source tags are stripped from the reply data. This way the client and server don't both need to track if the other supports source tags. I can see two problems though: firstly, this would never become the default, unless we have a due date after which point source tags become included in the default query types of these tools. Secondly, how should the objects be represented in the RIPE DB? If I have a member in my AS-SET which is "RIPE::AS-65534:AS-EXAMPLE" which is an object in the RIPE DB, and a legacy whois client queries the RIPE DB for my AS-SET, they would get the following in the list of members "AS-65535:AS-EXAMPLE", which isn't actually an object in the RIPE DB. When the same legacy client then tries to query for that specific object, RIPE would need to know to look for both "AS-65534:AS-EXAMPLE" and "RIPE::AS-65534-AS-EXAMPLE". The same applies when creating or renaming objects, the RIPE DB would need to know that if I create an object called "RIPE::AS-65534:AS-EXAMPLE" no one else is allowed to create "AS-65534:AS-EXAMPLE" and vice versa. Are there more problems I've missed if the RIPE DB returns a different responses to different clients? Cheers, James.
/me wrote on Tuesday, November 15, 2022 9:46 AM:
Coming back to your original question
James Bensley asked on Monday, November 7, 2022 10:02 AM:
"what it would take to allow the use of the "::" indicator in the "members" field of an AS-SET and Route-Set so that in my own AS-SET I can specify the correct source for the direct members":
I would say, get RFC2622 updated. And I fear, likely this will not going to happen very soon or fast or maybe not at all, as the new notation is not backward compatible.
Just to be more constructive and as written before (but as stated before, I'll not propose it "officially" as it looks a bit clumsy and is based on "unwritten rules" and I think it's more worth to put some efforts in some better and more formal and final solution than "lifting" IRR): Rather prepending set names with RR::, you could propose to the wider (than RIPE) community to read set names ending in e.g. "-AUTH-IN-RR" or ":AS-AUTH-IN-RR" to be treated as "only valid if source of this object is RR". That will not violate the naming convention of set names / RFC2622. It's backward compatible. Nothing breaks or anyone needs to update anything. Smarter tools (or IRRD if asked to do so) could then verify if the set's source is the stated RR. Even if someone else would register the same set name in another open RR, it wouldn't be considered (by the right tools) as the authoritative one. But it looks ugly (too many letters around your great company name), doesn't prevent some unknowledgeable persons -following some "as-sets for dummies" guides- to register something like AS-FOO:AS-AUTH-IN-RIPE in RADB and shooting themselves in the foot and it requires a more or less informal agreement across a wider group of tool developers and users. [And likely more ...] And -but that's true for any solution- you need to get people update their as set, update upstreams, customers, peers, IXes, various objects, Web entries, [...] and use new tooling, understanding the ending people agreed on. Markus
Hello James,
On 9 Nov 2022, at 17:42, James Bensley <james@inter.link> wrote:
... 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.
Just to confirm, if there is consensus to make this change, the RIPE NCC DB team will provide an impact analysis and an implementation plan. It is not a major change on the back-end, but there is an impact on clients (e.g. IRRd) as discussed. Regards Ed Shryane RIPE NCC
From: Edward Shryane <eshryane@ripe.net> Sent: 11 November 2022 13:26 To: James Bensley Cc: routing-wg@ripe.net Subject: Re: [routing-wg] Adding "::" notation to RIPE DB Hello James, Just to confirm, if there is consensus to make this change, the RIPE NCC DB team will provide an impact analysis and an implementation plan. It is not a major change on the back-end, but there is an impact on clients (e.g. IRRd) as discussed. Regards Ed Shryane RIPE NCC ________________________________________ Thanks Ed! Cheers, James.
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@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
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.
and NTT and ... randy
participants (12)
-
Alexander Zubkov -
Arnold Nipper -
Carlos Friaças -
Cynthia Revström -
Edward Shryane -
James Bensley -
Jared Mauch -
Netmaster (exAS286) -
Radu-Adrian FEURDEAN -
Randy Bush -
Sander Steffann -
Sasha Romijn