[routing-wg] Adding an "exclude-member" field

> Another attempt to have tools do more than defined in the standards

What are you talking about? There are no standards I am aware of which states how third part open source tools (irrd/bgpq4/irrtree) must operate. Equally for IRR DBs. The RIPE team are able to add/edit DB fields, based on community demand (they have done this in the past and are open do going it again), and it is not restricted by any standards I know of.

> and get this implemented just in RIPE DB? ;-)

Nobody said that. You assumed that. Implementing it in multiple DBs simultaneously would simply be too difficult and you know that. Everyone knows, start with one, show that it works (if it works), then move to the next DB, on one at a time.


> It would be a "give others hints about -in most cases- brokenness of
> included (sub-*) members in your AS-SET", right?
>
> Now you telling others "what is right and what is wrong" for the mem-
> bers of your AS-SET (and their included members, ...).
>
> Not sure if I like that.

Why? That is exactly the point. Only I know what should or should not be in my AS-SET but, I have no control over it. Other networks don't know that certain ASN or AS-SETs should NOT be accepted from me, they just expand my AS-SET into a prefix list or ASN list and accept whatever they expanded to (minus whatever fails RPKI checks).

> And you just telling this from your perspective, but without any rea-
> son (e.g. because of your needs or because you think sub-sub-sub-sub
> AS-SET Z is "broken").

I have listed multiple reasons in my initial email, and I brought the idea to this list to getter wider community perspective, not just mine. Do you have some sort of attitude problem or understanding problem?

> I feel the pain you have. We all have this. Some (I think) achieve
> similar by exploding the AS-SETs level by level and dropping e.g.
> IX-AS-SETs, questionable AS-SETs and Tier-1/certain ASNs. But that's
> for their own use.

Yes, I have seen this, and we also do it but, that only helps me and not my peers or upstreams: I can use the method you described (hard code certain entries in my internal tooling) so that I don't accept those prefixes/ASNs but, my upstreams and peers will build prefix lists towards me which do include those entries. One problem we have seen semi-regularly is “AS-SET explosion”, where our AS-SET expands to almost the entire DFZ, and our peers/upstreams can no longer build prefix lists towards us. I can hard code an exclusion in my internal tooling so that I can still build the prefix lists toward my customer with the explosive AS-SET but, no upstream or peer can expand my AS-SET.

> Sharing information on "which AS-SET is obviously broken and owner is
> not willing to cleanup (or explain, why it's not broken)", could be
> indeed of use - if trustful and transparent. But always have in mind:
> there are also not-so-nice players out there.

This is not an option in my opinion. There may be a problem due to a genuine mistake but, the responsible party can't be reached, so this only serves to bring negative attention to an innocent party in my opinion. As operators, we need a method to take responsibility for our own AS-SET(s). Currently, anyone can add anything they like further down in my AS-SET tree, and there is nothing I can do about it. That is very bad.

I'm interested to here if other people are in favour of this idea or not, and what they like / don't the like about it. Also, is it worth discussing in person at RIPE87?

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

Boxhagener Str. 80, 10245 Berlin, Germany
Email: hello at inter.link,
Phone (general): (+49) 030577123821
Phone (mobile): (+49) 015792522412
Registry: Local court Charlottenburg, HRB 138876
Managing directors: Marc Korthaus, Theo Voss

________________________________________
From: Netmaster (exAS286) <netmaster at as286.net>
Sent: 23 October 2023 19:31
To: James Bensley; routing-wg at ripe.net
Cc: Netmaster (exAS286)
Subject: RE: Adding an "exclude-member" field

JB wrote Monday, October 23, 2023 5:38 PM CEST:
> I am thinking about the usefulness of adding a new field to the RIPE
> database which is an AS-SET "exclude-member" field, to compliment the
> "member" field.

Another attempt to have tools do more than defined in the standards
and get this implemented just in RIPE DB? ;-) [Just remember the ::
notation.]


It would be a "give others hints about -in most cases- brokenness of
included (sub-*) members in your AS-SET", right?

Now you telling others "what is right and what is wrong" for the mem-
bers of your AS-SET (and their included members, ...).

Not sure if I like that.

And you just telling this from your perspective, but without any rea-
son (e.g. because of your needs or because you think sub-sub-sub-sub
AS-SET Z is "broken").

I feel the pain you have. We all have this. Some (I think) achieve
similar by exploding the AS-SETs level by level and dropping e.g.
IX-AS-SETs, questionable AS-SETs and Tier-1/certain ASNs. But that's
for their own use.

Sharing information on "which AS-SET is obviously broken and owner is
not willing to cleanup (or explain, why it's not broken)", could be
indeed of use - if trustful and transparent. But always have in mind:
there are also not-so-nice players out there.

Markus