Support for "::" notation in the "members" field
Dear Working Group, I want to discuss a format change to 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 to raise this. Specifically, I want to discuss adding supported for the "::" source notation in the "members" field of an AS-SET or Route-Set. 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 the prefix lists towards me (AS4200000011), they need to generate a prefix list for my entire AS tree/route set tree. The problem is that historically objects with the same name have been registered in different IRR databases. This causes a problem because it's not clear which IRR DB should be used to pull the prefix list for a given ASN. For example, AS-GOOGLE current exists in 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. 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 we can't establish a new peering session with a customer/peer/upstream or update our prefix list facing an existing customer/peer/upstream because we can't generate the prefix towards them. 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
I want to discuss a format change to 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 to raise this. you're not wrong about the problem statement. The difficulty is that your proposal is not backwards compatible. As there's no versioning in RPSL, it would probably need a new rpsl key to implement. Probably also
James Bensley via db-wg wrote on 04/11/2022 08:46: this is routing-wg territory rather than db-wg. Nick
Hi Nick, Thanks for the tip re; "Probably also this is routing-wg territory rather than db-wg." I will report to the routing-wg list. Regarding backwards compatibility; it breaks backwards compatibility with what? Within the scope of the IRR DB itself, I guess we need to ensure that an AS-SET or Route-Set can be called "RIPE::AS4200000011:AS-EXAMPLE-11" and that the same syntax is allowed in the members field. I think the problems you thinking off are external to the IRR DB (i.e., with irrd, bgpq3/4, irrtree, and similar tooling), or is there something else within the RIPE DB you think would break? If the former, I agree there will be issues with external tooling, but I want to address one thing at a time starting with the RIPE DB itself. If the later, what are you thinking? 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
participants (2)
-
James Bensley
-
Nick Hilliard