Re: [44net] Time to restructure the network?

Rob, Then you weren't paying attention this past week. The spectacular failure of the volunteers who manage DNS to speak up and address the problem (with ARIN, as it turns out) was astounding. Again, I have yet to see a written proposal of what you're trying to do. I can only guess, based on what you've said in emails. And from what you have said, you would eliminate the central portal, which would dismantle the existing mesh and force all connectivity to pass through hubs managed by people with no service level agreement with those they serve. I certainly want no part of that. Maybe. It also creates a bunch of problems, which you STILL haven't addressed. Also, you haven't identified the problem you're trying to solve. It would help to have a clear statement of the problem. Completely wrong. Nobody is objecting to adding new folks, perhaps using a different technology. I already said I'm for anything that's more standard and easier. But you're ALSO proposing doing away with the existing connectivity. That's throwing the baby out with the bathwater. As you say below, there are over 500 gateways working just fine. But to offer connectivity to others, your proposal would presumably remove the existing connectivity from all of the existing sites, and force them to go through some hub somewhere (typically two - one at each end). That's a big step back for the 500 existing gateways. It doesn't matter how many are in use. If my ampr routing table has 50 or 500 or 5000 routes, who cares? What matters is that anyone can register on the portal, and after the next update (RIP-44, file download, whatever), all other gateways will automatically be configured with a tunnel to the new gateway/subnet. No one has to do anything. And if there is a problem, the two endpoints can diagnose directly. tcpdump on each end is all you need. Do you have evidence for your statements? https://qrznow.com/us-amateur-radio-population-grows-slightly-in-2018/ It looks like from 2014 to 2018, the US ham population only grew 4%. And I haven't monitored it closely. But it seems to me that the size of amprnet has remained about the same (+/- 100 or so) for the last 10 years. So who/where are these 49,500 other gateways? Why would a bunch more tunnels be a problem? I heard you the first time. But you still haven't addressed the problems they introduce: -- increased latency and jitter -- increased troubleshooting complexity (no end-to-end troubleshooting by the two endpoints) -- very few existing gateways will have a BGP connection to their ISP, so most will lose direct connectivity to other gateways and be at the mercy of some hub operator somewhere -- hubs are operated by volunteers with no service level agreement with their users, no consequences whatsoever if they don't want to help during dinner or when they are out at a movie or sick or on vacation or whatever. No consequences if they simply decide they don't want to do it anymore. But they don't today. Register your subnet and gateway with the portal and all other gateways will be configured on the next update (RIP or file). And they don't require any middle-men/hubs in between. Yet your proposal would presumably throw all of that away and force everyone through hubs. Those who don't want that would be left to figure out some other manual cross-connect solution on their own. BOTTOM LINE: 1) If you want to provide a solution for folks who can't use IPIP, then that's awesome. Go for it. Build a hub (or multiple hubs) and offers VPN connections or whatever/however you want. In fact, I think some people already do that. 2) Getting started on the IPIP mesh is difficult. So, if you have a better solution for **DIRECT** connections than the existing IPIP mesh, then let's hear that. But once you're up on the mesh, there's literally nothing to do and it works great. So until you have a better solution for **DIRECT** connections, it makes no sense to destroy the direct connectivity that 500 gateways currently enjoy, along with the automated configuration, ease of troubleshooting, etc. and, above all, ZERO dependence on some other volunteer's operation of a hub. Michael, N6MEF