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

JB wrote on Wednesday, October 25, 2023 4:45 PM CEST:
>> 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.

Haven't said that. But as-set with members and mbrs-by-ref are defined.
True, we see additional fields, but - beside source: - none of them have
a meaning in the context of as-set and it's purpose. But exclude-member
would introduce such. And this should then IMHO also reflected in the RFC. 

But that's my opinion. If the extended community thinks differently, fine
by me.

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

We all give up "control" here by including AS-SETs defined by others. The
most control you could get is list all ASNs, but even then, open IRRs 
gives freedom for "creative" approaches to get prefixes in (AS-SETs).

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

Reality what you do vs. what is documented. AS-SETs are IMHO not suitable
to reflect more complex things ... and AUT-NUMs no one really makes use
of.

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

And I give my comments, which aren't in line with your idea - sorry. You
can believe me or not, I understand the problem, faced the same pain and
frustration over the years. 

You are always free to filter announcements. And it's a nice thing, if you
(would) tell this your upstream/peers to help them to keep the filters "short
and clean" and not polluted by "questionable" things, causing most of the
DFZ included (and challenge your own and upstream's router).

But I think exclude-member wouldn't fix the root problem and that's in
most cases some AS-SETs down the tree, including IX AS-SETs, upstream AS-SETs
or one of these lately way too often seen DDOS-provider AS-SETs, including
again half of the DFZ. (Oh, there are indeed sometimes good reasons, like
for the DDOS providers, but it's a pain and some of them often ask for 
complete "whitelisted" sessions, as they know, their AS-SET explodes to
too many entries.)

Your proposal is IMHO a workaround. Not totally wrong, but the approach
"just do it" is wrong. Like introducing a new BGP code for something "very
useful", but never getting it officially somewhere documented. 

And there are always special cases

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

By mentioning in the public (some would call it blaming) "AS64511:AS-IMSOCOOL"
to include AS<pure-upstream-of-AS64511> - which they shouldn't and after not
being able to contact them or them not understanding the issue -, there's no
innocent involved. However, as said, trusting such information published,
is difficult ... but maybe makes them finally correct it to avoid -1 karma.

[pure = AS<pure-upstream-of-AS64511> is not getting upstream from AS64511;
that's a valid setup and sometimes seen between smaller ASNs, helping out
each other ... and would be a valid, legitime reason for "looped" AS-SETs]

> As operators, we need a method to take responsibility for our own AS-SET(s).

Yep. Again, as soon as you include someone's else AS-SET, you aren't under 
control anymore. If everyone would care ... the world would be a better one.


Markus