Adding an "exclude-member" field
Hi all, 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. When another network is walking my AS-SET to generate a prefix list or ASN list, the “member” field in my AS-SET is used to include prefixes and origin ASNs in the generated list, by expanding the ASN or AS-SET defined in the member field. I would like to introduce an “exclude-member” field which tells the other network to NOT include prefixes and ASNs which are part of that members AS-SET or ASN. That's the high level view. I have provided a more detailed explanation below. Please let me know what questions you have, and what would be a reasonable why to explore this idea (I've never tried to add a new field to the RIPE DB before). Also, I messaged the DB WG chairs about this ages ago, and they felt that since it's not a major DB change and it relates more to routing, the routing WG is a better place to discuss it. With kind regards, James. ------ Full Problem Statement: There are many reasons to want to exclude an AS-SET or ASN which exists somewhere within in my AS-SET tree, for example: 1 - A member is added to an AS-SET which is simply not connected to the ASN the AS-SET represents, allowing the ASN to announce prefixes they aren’t allowed to originate (this is possibly a hijack). 2 - A member is added to an AS-SET which creates a loop (A contains B which contains A) (this is possibly a config mistake). 3 - A member is added to an AS-SET which is a peer, not a customer, and the ASN owning this AS-SET is not a transit provider for this peer (this is possibly a config mistake). 4 – A member in an AS-SET is an operator who is openly/willing doing something directly against our terms of usage but, they aren’t a direct customer of ours / we have no contact with them and nor do our direct customers because, they’re many levels down the AS-SET tree (this is a T&C or maybe even legal issue). 5 – A member is added in an AS-SET further down in our AS-SET tree, with whom we have a direct connection e.g. a customer or peer, and we don’t want to send traffic via any path, other than our direct connection with them (this is possibly political or regulatory). The result of these different sources of invalid or unwanted members in AS-SETs is that; - Operators generate prefix lists which accept prefixes from customers/peers, those prefixes shouldn’t be announced to the operator by those customers/peers. - Operators are unable to generate prefix lists due to anomalies in the AS-SET tree data that prevents the prefix generation tooling from correctly functioning (e.g., due to AS-SET loops, or AS-SETs that contain an operators own AS-SET/ASN, or AS-SETs which have accidentally included a “Tier 1” or other large network and are simply too massive, and so on). - Operators are providing connectivity to networks they don’t want to, or must not but, the entry is way down the AS-SET tree so they have no influence over this. In all cases, the currently available option is almost always “contact the owner of the AS-SET with the invalid/unwanted member and ask them fix/remove it”. The problem with this approach is: - Some remote operators simply do not response. - Some remote operators simply do not care. - Some remote operators have different opinions/priorities/relationships/regulations and disagree that there is a problem. - The remote operator is so far removed from the local operator, any efforts to put pressure on the local operator’s direct customer/peer, to speak to their customer, to in turn speaker to their customer (ad infinitum) results in a strained relationship between local operator and direct customer/peer for no benefit. To summarise all of the above points; the only solution we have now is a best efforts one. Operators needs a practical solution which they can enact [almost] immediately without having to wait potentially months for an outcome which may not resolve the problem. The problem of prefix generation is an operational problem that affects daily operations of a network so the [almost] immediate requirement for the solution is a crucial point here. Suggested Solution: I propose that we add a new field to an AS-SET called “excluded-members” or “excl-members” or “x-members” or whatever (I’m not precious about the name). The format of this field would be just like the “member” field today, meaning it can contain a single AS number or a AS-SET, or a comma separated list, and there can be multiple “x-members” fields per AS-SET object. The purpose of the “x-members” field in an AS-SET object, is to tell other operators, when expanding this AS-SET object, to not include these members ANYWHERE in the tree starting from the AS-SET which included the “x-members” field. Just as a side note; I've just looked at IRRd and this functionality seems to already exist (the "excludeSets" field in the GraphQL interface). I don't think it would be too difficult to add to tools like bgpq4 or irrtree either (I would be happy to work on PRs for both). Kind regards, James Bensley (he/him) Network Team Inter.link GmbH Boxhagener Str. 80, 10245 Berlin, Germany Email: hello@inter.link, Phone (general): (+49) 030577123821 Phone (mobile): (+49) 015792522412 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss
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
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@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@as286.net> Sent: 23 October 2023 19:31 To: James Bensley; routing-wg@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
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
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-i... [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: hello@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@as286.net> Sent: 25 October 2023 18:24 To: James Bensley; routing-wg@ripe.net 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
Hi James,
sorry for the delay in my response, I did not intend to be so late
We are all busy with something, so don't worry, I didn't waste time in waiting.
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.
And it's a RFC (but beside this, it doesn't alter much of how to read an as-set).
- RFC2725 Section 9.6 "Other Objects" introduces the use of "::" notation to indicate the source of an object.
[Probably badly translated: Sovereignty of interpretation] - I don't read this to make e.g. SOURCE::ASN:AS-CUSTOMER a compliant as-set name (which goes back to the previous discussions for AS-SET naming). But if, I would be more than happy (as that suggestion you made once, was something I'd love to see happening).
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.
And the use outside RIPE is <?>. Compared to assignment-size, you for sure want to have exclude-members accepted/implemented/... by other IRRs. Just "starting in the RIPE island" and hoping others follow is IMHO too optimistic.
[...] - Only hierarchical AS-SETs can be created in the RIPE DB now, this is not RFC2280 Section 5.4 complaint.
RIPE DB supports legacy non-hierarchical as-sets. But in any way, this restriction does not introduce something "new". It's a restriction of what you can enter.
RFC9092 Section 3 "inetnum: Class": [...]
The interesting part follow past the quoted: <<Ideally, RPSL would be augmented to define a new RPSL geofeed: attribute in the inetnum: class. Until such time, this document defines the syntax of a Geofeed remarks: attribute [...] While we leave global agreement of RPSL modification to the relevant parties, we specify that a proper geofeed: attribute in the inetnum: class MUST be "geofeed:" and MUST be followed by a single URL that will vary, but it MUST refer only to a single geofeed [RFC8805] file. inetnum: 192.0.2.0/24 # example geofeed: https://example.com/geofeed.csv
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 don't know, maybe one of them can comment, but to be honest, it reads more like a nice "workaround" to avoid touching RPSL itself, but defining *in a RFC* a new attribute ... by describing the repurposed attribute and defining at the same time, how such attribute MUST be named if ever officially defined in RPSL - that's a definition itself. [Just thinking loud: a template for future added attributes without touching RPSL?]
I also see plenty of evidence (which I listed above) that plenty of changes are made without engaging the IETF.
I see them targeting something different or taking another approach. Maybe others - beside you - see this differently. If you consider exclude-members that valuable and just start with RIPE and without thinking the next steps, it might become an island solution. Just the naming could become an endless discussion, e.g. if RIPE starts using exclude-members: and later others insist on using members-exclude:.
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 implemen- tation but, I started by asking how useful might this feature be, and asked for feedback on the feature/idea itself first.
Quoting your opening:
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.
First part fine with me (discuss the usefulness of such attribute, the pro and cons and alternatives), second part is for me the "just do it" part. I miss the "how to get the broader community now/later following" step before seeing it in RIPE DB. But I hate where we now end, turning words arounds and drifting away from discussing your idea and proposal, if this is of use for the RIPE and -as IMHO otherwise it doesn't make much sense- a wider community, what are obstacles (or just /me seeing problems, which don't exist) and potential alternatives.
But, currently we don't have any way to tackle this problem. I am proposing something because, something is better than nothing.
Sometimes something could be better than nothing, sometimes nothing could be better than something. But this we really don't need to discuss.
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?
No - sticking to nothing. There's a problem - but that doesn't imply /me accepting the first proposal nor forces me to supply an alternative solution. If that's the rule of discussing an idea these days ... uh, back again where I don't want this to end, sorry. Split discussion. Parts of my comments are about the usefulness - as I see it with my current understanding. I understand what you want to achieve (and "bad" networks is one example, expressing commercial implied exclusions [as you wrote in another - not quoted here paragraph] could be another - as Nick wrote much clearer: a set exclusion operator). If you want to achieve it today, explode your members, list all the ASNs -except the ones you don't want to have listed- as members and publish this as to-be-used as-set for you. A few script lines should be enough to make this work (and a few more with proper error handling ;-). [Not sure, if not some tools choke on way-too-many-direct-ASN-members listed, but also this could be solved with some "own-managed" sub-as-sets to list ASNs.] Ugly, true, an exclude operator is much more charming. If of use? I see it for some, for others quite unlikely. If the ones -having a use case for it- are enough to justify this to become real, I can't say. The other part is about the "how to achieve/implement this". And there I have my strong doubts which I brought up. And I still stick to these concerns. But if you/we/whoever gets this "properly" defined, then it's another story. [If the geofeed "way" would work? Not sure, as exclude-members would link back to the semantics of members: - while the geofeed: is "additional information".] If others think this is useful AND the suggested approach is reasonable for the majority - well, who would I be to stop it? By now, with that "many" other comments and input, it's you asking for it and me coming back with some concerns (and Nick putting it in some nicer, clearer words). If that's all, well, I think we should save the time for something else. Markus
James Bensley wrote on 25/10/2023 15:44> 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.
well, not quite true. The RIPE DB implements RPSLng which is defined in rfc4012 and previous rfcs. The best place to get this changed might have been at the IETF, but it's not likely that people are going to be much interested in RPSL updates there because they're really lost interest in RPSL in a big way. Probably GROW would be the best working group if you want to try. [...]> 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?
RPSL is broadly based on set theory, and from this point of view, it would certainly make sense to have an exclusion operator, at least in theory. The problem is more that RPSL is something that doesn't work well in practice for a number of reasons and no amount of tweaking around the edges is going to be able to fix it. Language grammar inflexibility is one of these areas. Another is restriction of object scope to specific IRRDBs. Both of these issues would impact on your suggestion. Nick
Hi Nick, Sorry for the delay in my reply.
well, not quite true. The RIPE DB implements RPSLng which is defined in rfc4012 and previous rfcs. The best place to get this changed might have been at the IETF, but it's not likely that people are going to be much interested in RPSL updates there because they're really lost interest in RPSL in a big way. Probably GROW would be the best working group if you want to try.
See my discussion with Markus. TL;DR: - All of the 5 RIR IRR-DBs have non-standardised stuff in them. - None of them seem to have any clear documentation on how to make changes to their respective DBs (after how many years?) such as; must changes be standardised, how is it decided that a suggested change is valid, who should one talk to about these things, etc. - Having new stuff be standardised in an RFC make sense however... - As I said in my email to Markus, if we pretend I got a new draft into GROW and eventually published, "then what?". How does one get that implemented in the RIR DBs (RIPE to start with)?
RPSL is broadly based on set theory, and from this point of view, it would certainly make sense to have an exclusion operator, at least in theory. The problem is more that RPSL is something that doesn't work well in practice for a number of reasons and no amount of tweaking around the edges is going to be able to fix it. Language grammar inflexibility is one of these areas. Another is restriction of object scope to specific IRRDBs. Both of these issues would impact on your suggestion.
I think the 2nd part is a valid concern about object scope. The first part I find concerning. It reads to me a bit like Markus' response, that (paraphrasing) we shouldn't be trying to improve something that isn't working as well as it could, and just implement hacks to work around it. Kind regards, James Bensley (he/him) Inter.link GmbH Boxhagener Str. 80, 10245 Berlin, Germany Email: hello@inter.link, Phone (general): (+49) 030577123821 Phone (mobile): (+49) 015792522412 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss ________________________________________ From: Nick Hilliard <nick@foobar.org> Sent: 25 October 2023 18:28 To: James Bensley Cc: routing-wg@ripe.net Subject: Re: [routing-wg] Adding an "exclude-member" field James Bensley wrote on 25/10/2023 15:44> 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.
well, not quite true. The RIPE DB implements RPSLng which is defined in rfc4012 and previous rfcs. The best place to get this changed might have been at the IETF, but it's not likely that people are going to be much interested in RPSL updates there because they're really lost interest in RPSL in a big way. Probably GROW would be the best working group if you want to try. [...]> 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?
RPSL is broadly based on set theory, and from this point of view, it would certainly make sense to have an exclusion operator, at least in theory. The problem is more that RPSL is something that doesn't work well in practice for a number of reasons and no amount of tweaking around the edges is going to be able to fix it. Language grammar inflexibility is one of these areas. Another is restriction of object scope to specific IRRDBs. Both of these issues would impact on your suggestion. Nick
JB wrote on Tuesday, November 14, 2023 9:22 AM CET:
See my discussion with Markus. TL;DR:
Does that help?
It reads to me a bit like Markus' response, that (paraphrasing) we shouldn't be trying to improve something that isn't working as well as it could, and just implement hacks to work around it.
Did I? My point - and I'll stick with it until I'm taught better: Improvements (often) do not justify breaking existing rules. Or in this particular case: Adding members-exclude to as-set without defining it somewhere "officially" (syntax and semantic) BEFORE, seems to me NOT the right way. (Esp., as the target is to get this into the complete IRR "eco system" and not just into RIPE.) Markus
Hi Markus;
Or in this particular case: Adding members-exclude to as-set without defining it somewhere "officially" (syntax and semantic) BEFORE, seems to me NOT the right way. (Esp., as the target is to get this into the complete IRR "eco system" and not just into RIPE.)
As I have said multiple times, getting this standardised isn't the sticking point for me. This is:
- As I said in my email to Markus, if we pretend I got a new draft into GROW and eventually published, "then what?". How does one get that implemented in the RIR DBs (RIPE to start with)?
I think, that you think, I'm against documenting and standardising this. I am not. The big questions for me is, what happens after going to the IETF? It's a waste of time getting an RFC published if all I can do is print it off and make paper aeroplanes with it. So the question is, what comes after that? Just because there is an RFC, would RIPE implement? What is required for them to implement it? Do they need any additional documentation or testing? Does the RIPE RIPE DB docs website need updating too? Would I have to request that? There is no point talking about getting this standardised, if RIPE wouldn't implement it, and I can't find any information on what is required in order for RIPE to implement this. Kind regards, James Bensley (he/him) Inter.link GmbH Boxhagener Str. 80, 10245 Berlin, Germany Email: hello@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@as286.net> Sent: 14 November 2023 10:45 To: James Bensley; Nick Hilliard; routing-wg@ripe.net Subject: RE: [routing-wg] Adding an "exclude-member" field JB wrote on Tuesday, November 14, 2023 9:22 AM CET:
See my discussion with Markus. TL;DR:
Does that help?
It reads to me a bit like Markus' response, that (paraphrasing) we shouldn't be trying to improve something that isn't working as well as it could, and just implement hacks to work around it.
Did I? My point - and I'll stick with it until I'm taught better: Improvements (often) do not justify breaking existing rules. Or in this particular case: Adding members-exclude to as-set without defining it somewhere "officially" (syntax and semantic) BEFORE, seems to me NOT the right way. (Esp., as the target is to get this into the complete IRR "eco system" and not just into RIPE.) Markus
Hi James,
On 14 Nov 2023, at 12:14, James Bensley <james@inter.link> wrote:
Hi Markus;
Or in this particular case: Adding members-exclude to as-set without defining it somewhere "officially" (syntax and semantic) BEFORE, seems to me NOT the right way. (Esp., as the target is to get this into the complete IRR "eco system" and not just into RIPE.)
As I have said multiple times, getting this standardised isn't the sticking point for me. This is:
- As I said in my email to Markus, if we pretend I got a new draft into GROW and eventually published, "then what?". How does one get that implemented in the RIR DBs (RIPE to start with)?
I think, that you think, I'm against documenting and standardising this. I am not. The big questions for me is, what happens after going to the IETF?
It's a waste of time getting an RFC published if all I can do is print it off and make paper aeroplanes with it. So the question is, what comes after that? Just because there is an RFC, would RIPE implement? What is required for them to implement it? Do they need any additional documentation or testing? Does the RIPE RIPE DB docs website need updating too? Would I have to request that?
There is no point talking about getting this standardised, if RIPE wouldn't implement it, and I can't find any information on what is required in order for RIPE to implement this.
The DB-WG uses Numbered Work Items to keep track of feature requests: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items Firstly a problem statement is published on the DB-WG for discussion. Once there is agreement on a problem definiton and solution, the RIPE NCC will work on an implementation plan, development and deployment. For example, see the "Geofeed" feature that was implemented in 2021, which was defined in an RFC (https://datatracker.ietf.org/doc/rfc9092/) and tracked in NWI-13. Regards Ed Shryane RIPE NCC
Hi Ed, Thanks for both of your emails. What you have said makes sense. I did actually contact the DB-WG chairs before posting to the routing mailing list. I had seen the same page you linked (https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items) and asked them on how to proceed. They said that my query relates to only a minor DB change, and has more of an impact on routing policy, so I should take it to the routing WG. I will take your advice, and go to the DB-WG, and start again. Kind regards, James Bensley (he/him) Inter.link GmbH Boxhagener Str. 80, 10245 Berlin, Germany Email: hello@inter.link, Phone (general): (+49) 030577123821 Phone (mobile): (+49) 015792522412 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss ________________________________________ From: Edward Shryane <eshryane@ripe.net> Sent: 14 November 2023 17:01 To: James Bensley Cc: Netmaster (exAS286); Nick Hilliard; routing-wg@ripe.net Subject: Re: [routing-wg] Adding an "exclude-member" field Hi James,
On 14 Nov 2023, at 12:14, James Bensley <james@inter.link> wrote:
Hi Markus;
Or in this particular case: Adding members-exclude to as-set without defining it somewhere "officially" (syntax and semantic) BEFORE, seems to me NOT the right way. (Esp., as the target is to get this into the complete IRR "eco system" and not just into RIPE.)
As I have said multiple times, getting this standardised isn't the sticking point for me. This is:
- As I said in my email to Markus, if we pretend I got a new draft into GROW and eventually published, "then what?". How does one get that implemented in the RIR DBs (RIPE to start with)?
I think, that you think, I'm against documenting and standardising this. I am not. The big questions for me is, what happens after going to the IETF?
It's a waste of time getting an RFC published if all I can do is print it off and make paper aeroplanes with it. So the question is, what comes after that? Just because there is an RFC, would RIPE implement? What is required for them to implement it? Do they need any additional documentation or testing? Does the RIPE RIPE DB docs website need updating too? Would I have to request that?
There is no point talking about getting this standardised, if RIPE wouldn't implement it, and I can't find any information on what is required in order for RIPE to implement this.
The DB-WG uses Numbered Work Items to keep track of feature requests: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items Firstly a problem statement is published on the DB-WG for discussion. Once there is agreement on a problem definiton and solution, the RIPE NCC will work on an implementation plan, development and deployment. For example, see the "Geofeed" feature that was implemented in 2021, which was defined in an RFC (https://datatracker.ietf.org/doc/rfc9092/) and tracked in NWI-13. Regards Ed Shryane RIPE NCC
participants (4)
-
Edward Shryane -
James Bensley -
Netmaster (exAS286) -
Nick Hilliard