21 Jul
2019
21 Jul
'19
8:03 a.m.
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:
1) 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)
2) *** 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.
3) 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