> 1) It's amazing how many threads end up ending in the (correct) summary that making an even minor global change to the way the internet works and/or is configured to enable some potentially useful feature isn't likely to happen.
My biggest take-away from this is that software and network engineering design decisions should be more thoughtful and methodical when setting address space, number space, name space and size/expandability of whatever is being configured when designing new things. Even if you think whatever you've created is inexhaustible for your own purposes. Once something has been put into widespread use it's extremely difficult to come back and fix it later. Such as for ISP internal purposes, like thinking about "okay what if we take this DNS zone delegation for our internal management network and set it aside for a vast number of CPEs in the future, hierarchically organized by where they're going to be installed geographically, for our internal hostnames and reverse DNS". I'm sure that the vast global address space of ipv4 looked incredibly large when put into use as a standard... Or if you've ever seen an organization that internally set up its accounting/billing/customer circuit ID system with a namespace/number-space that didn't scale to meet future needs, or categorization of customers, or integration of circuit IDs into automation systems. On Tue, Jan 24, 2023 at 8:13 PM Forrest Christian (List Account) < li...@packetflux.com> wrote: > I have two thoughts in relation to this: > > 1) It's amazing how many threads end up ending in the (correct) summary > that making an even minor global change to the way the internet works > and/or is configured to enable some potentially useful feature isn't likely > to happen. > > 2) I'd really like to be able to tag a BGP announcement with "only use > this announcement as an absolute last resort" so I don't have to break my > prefixes in half in those cases where I have a backup path that needs to > only be used as a last resort. (Today each prefix I have to do this with > results in 3 prefixes in the table where one would do). > > And yes. I know #2 is precluded from actually ever happening because of > #1. The irony is not lost on me. > > > On Tue, Jan 24, 2023, 7:54 PM John Levine <jo...@iecc.com> wrote: > >> It appears that Chris J. Ruschmann <ch...@scsalaska.net> said: >> >-=-=-=-=-=- >> >How do you plan on getting rid of all the filters that don’t accept >> anything less than a /24? >> > >> >In all seriousness If I have these, I’d imagine everyone else does too. >> >> Right. Since the Internet has no settlements, there is no way to >> persuade a network of whom you are not a customer to accept your >> announcements if they don't want to, and even for the largest >> networks, that is 99% of the other networks in the world. So no, >> they're not going to accept your /25 no matter how deeply you believe >> that they should. >> >> I'm kind of surprised that we haven't seen pushback against sloppily >> disaggregated announcements. It is my impression that the route table >> would be appreciably smaller if a few networks combined adjacent a >> bunch of /24's into larger blocks. >> >> R's, >> John >> >
