Hi Markus, Sorry for the delay in my response, I did not intend to be so late, especially considering that you were much more prompt in responding to my last message…
> 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. Yes, and no. There are example of updates which affect the as-set class: - RFC7909 introduces the "signature" attribute for all existing objects. - RFC2725 Section 9.6 "Other Objects" introduces the use of "::" notation to indicate the source of an object. But there are various instances of non-standardised attributes being added to IRR-DBs, including the RIPE DB: -Various RIPE documents [1], [2], [3], make use of the attribute "assignment-size" but, it isn't defined in any RFC. - RFC7485 Section 4 "RIR Objects Analysis" shows us that the presence of attributes in classes as defined in RFC2262 is not followed and even when the attributes are present, the naming is not as per the RFC. - Only hierarchical AS-SETs can be created in the RIPE DB now, this is not RFC2280 Section 5.4 complaint. - RIPE's own documentation states that they don't strictly conform to the RFCs, from: https://apps-test.db.ripe.net/docs/RIPE-Database-Structure/Database-Object/ “The records in the RIPE Database are known as ‘objects'. Routing Policy Specification Language (RPSL) defines the basic syntax of database objects. For further information see RFC 2622 (opens new window). But, over the years, practical operations have resulted in a number of deviations from the basic RPSL definition. Many extensions have also been made to the RIPE implementation of RPSL for the RIPE Database. Some features of RPSL were never implemented and others have been removed as requirements changed.” A recent RFC has made a change to the RPLS but, it has repurposed an existing optional class attribute, rather the adding a new one: RFC9092 Section 3 "inetnum: Class": “The original RPSL specifications starting with [RIPE81], [RIPE181], and a trail of subsequent documents were written by the RIPE community. The IETF standardized RPSL in [RFC2622] and [RFC4012]. Since then, it has been modified and extensively enhanced in the Regional Internet Registry (RIR) community, mostly by RIPE [RIPE-DB]. Currently, change control effectively lies in the operator community” So, whilst I might be willing to go to GROW, I don’t want to spend time in the IETF if I don’t have to. I assume the authors of RFC9092 for example, chose their approach of repurposing the remarks attribute (which is suboptimal when compared to adding a new attribute), because presumably they didn’t want to face the pain of adding a new attribute? I also see plenty of evidence (which I listed above) that plenty of changes are made without engaging the IETF. So this leaves me in the situation, where I see little evidence for needing to punch myself in the groin by trying to go through GROW. What is RIPE’s view here? When do things need to go through the IETF, and when do they not? Clarity on this would be good. > 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. So, let’s do something about it then? > 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. I never said “just do it”. You skipped the conversation forward to implementation but, I started by asking how useful might this feature be, and asked for feedback on the feature/idea itself first. Also, you say “workaround” above. But, currently we don’t have any way to tackle this problem. I am proposing something because, something is better than nothing. Are you suggesting we stick with nothing? I think, if we have a problem, we should try to do something about it. Or, do you have a better idea of how to tackle this problem? > 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. You seem to be stuck on the idea that the inclusion of an AS-SET or ASN in an “exclude-members” attribute is because they are “bad” network. I have said already, there are many reasons to include an entry, not just because they are the source of troublesome routing policy information, it could also be due to a commercial arrangement, a political reason, or regulatory reason. In these cases, neither party has done anything “wrong”. So you seem to be against the idea because, you’re assuming that the presence of a network in “exclude-members” is a bad thing, which is incorrect. > > 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. Let’s do something about it then? [1] https://www.ripe.net/publications/docs/ripe-738 [2] https://www.ripe.net/manage-ips-and-asns/ipv6/documenting-ipv6-assignments-in-the-ripe-database [3] https://www.ripe.net/participate/policies/proposals/2023-04 Kind regards, James Bensley (he/him) Network Team Inter.link GmbH Boxhagener Str. 80, 10245 Berlin, Germany Email: [email protected], Phone (general): (+49) 030577123821 Phone (mobile): (+49) 015792522412 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss ________________________________________ From: Netmaster (exAS286) <[email protected]> Sent: 25 October 2023 18:24 To: James Bensley; [email protected] Cc: Netmaster (exAS286) Subject: RE: 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 -- 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
