But you also say "There is no need for a portal that registers the
subnets,
they only need to be configured in the gateway routers."
I haven't seen a technical write-up of what you propose. But the
statement
above tells me that those who aren't interested in the putting up
with the
new problems the overlay hubs would create have lost the simplicity
we have
now.
The routing of the subnets is not something the user would have to manage, that is what BGP does automatically. There is no need to register them. Every gateway tells its neighbors what subnets it has locally, and this information is passed around the entire overlay network.
It's easy enough to say things like "you can set up crosslinks to
wherever
you like". But without the central registry, we lose the simplicity
we have
today. Today, we download a file and run a script. Done. Direct connections to everyone else. No middle men. No added latency. No
added
complexity. No added troubleshooting difficulty. No added dependence on some volunteer at the hub who may or may not be available when needed.
As I wrote, to have that it would require an additional protocol like Cisco DMVPN which unfortunately is proprietary and not available in most (if not all) of the inexpensive routers that radio operators want to use.
Now if your proposal included the following, it would truly be solving a problem for some people with causing a problem for others:
- For folks who can't support direct connections, let them use a VPN
connection to a hub of their choosing (as you appear to be proposing)
- *** BUT *** leave the central registry in place, and augment it so
that
when you sign up for a hub, your subnets are still published to all other gateways as reachable through the hub.
- Therefore, those who can support direct connects but are not a hub can
still see a full registry and automatically create direct
links/tunnels to
all other gateways (whether they are individual gateways or hub gateways) and routes to all subnets behind all other gateways.
I think the minor problem of "now some paths are two hops while they would have been direct in the current system" is very minor compared to the many issues there are with the current system. When we want a system that anyone can easily connect to without being a network export, the system I propose provides that. When you do not want that, because it takes away the artificial hurdles "that everyone has to overcome", of course you could object to such changes. It is similar to the situation of no-code licenses. People who already had passed the CW exam were objected to removing the requirement for new licensees, with similar reasoning.
Again, while there are over 500 gateways in the current network with tunnels between all of them, there is no way they are all going to be in use. Wiring them up for everyone really makes no sense, and introduces a scalability problem that would become real when it were easier to use the system and we had like 50000 participants instead of 500. A system with regional hubs, while still offering the capability to cross-connect, is much more extensible.
Cross-connects require manual intervention because the situation has to be examined. As the new system does not require the IP address of the participants to be static, allows them to be behind NAT, behind a firewall, etc, it has to be decided what type of connection is made, which direction the connection is made, etc. E.g. when one of the two has a static address and the other one dynamic, it is best to connect from the dynamic to the static address (and re-make the connection when the dynamic address changes). When they are behind NAT, it is possible to use a VPN that can cross NAT. Right now, such stations simply cannot participate, and with a new system they can.
Rob