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: he...@inter.link,
Phone: +49-030-577123821
Registry: Local court Charlottenburg, HRB 138876
Managing directors: Marc Korthaus, Theo Voss
-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/db-wg

Reply via email to