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