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: [email protected], Phone (general): (+49) 030577123821 Phone (mobile): (+49) 015792522412 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss -- 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
