28 Jul
2021
28 Jul
'21
11:53 a.m.
On 28 Jul 2021, at 13:48, Rob PE1CHL via 44Net
<44net(a)mailman.ampr.org> wrote:
On 7/28/21 1:35 PM, Janko Mivšek via 44Net wrote:
First of all, let me say that we would like to see IPIP Mesh go away too some day, but we
definitely need a robust Global PoP infrastructure first. I think we have many years until
we can completely shut down IPIP mesh (at least the official ARDC one, anyone could set up
their own). But this can happen gradually. As more and more users are available via the
PoPs, then it will be easier to look into the future of IPIP Mesh. We have not discussed
anything related to it so far.
Rob PE1CHL via 44Net je 28. 07. 21 ob 13:18
napisal:
Yes. If I was not clear: my proposal is to make a new backbone of PoPs instead of the
current IPIP mesh
(as was discussed end of last year) where a user can choose to: I really think that "we should accomodate
static routes" is a very weak reason for the proposed changes.
We should move away from static routes, if anything.
Yet having a 'static route only' as a least common denominator is not a bad idea
either. Certainly comparing in complexity to IPIP mesh or BGP. Next common denominator
should be a VPN to POPs.
BGP is something we need to avoid for end users. It has a illusion of a simple setup,
but to understand and manage BGP, this is certainly out of reach for most of radio
amateurs. - make a simple VPN connection with a local subnet and
everything else is at the other end of the VPN.
users can decide themselves if they want the local side of that VPN to be an isolated
network of radio
stuff and set a default route to the VPN, i.e. everything else than local is routed to
the PoP and the router
there decides how to further route that (to another PoP, to another user, to
internet).
user has to do no routing at all. everything static. is even possible in a Fritzbox
and some other routers
which can setup a IPsec VPN (or OpenVPN or Wireguard in some other routers).
This comes with the following issue: how do I know as a sender that you are making this
available to the Internet? I will be able to send you packets, but your systems would just
send the responses back over the Internet, and I would never get them, as I am
Intranet-only. This can also lead to very difficult troubleshooting scenarios.
- second alternative is an "intranet only"
version of that where the user only routes 44.0.0.0/9 and
44.128.0.0/10 to the PoP and routes all the remainder to their own ISP. That is the
variant that is like
what is done in Germany. User can use NAT in their router if they want to access
AMPRnet from their
RFC1918 network.
- third option is to run BGP over the VPN and receive and advertise AMPRnet subnet routes
over that.
this allows advanced users to become a gateway for others, or to setup multiple VPNs to
different
PoPs and have redundancy. extra VPNs to fellow amateurs for direct routes withoud
dependency on
the backbone are possible as well. Standard routers like MikroTik can do this, ISP
routers of course cannot.
This all can work with some technical solutions and trying to think about a little bit
more. As I said many times today, finding a technical solution to connect all users by the
same means is easy. We don’t want that. That’s not the problem we try to solve. The
problem we try to solve is to allow you, that want to use the ARDC PoPs, to talk to me,
that I want to set up my own PoP concept globally, and connect users to my PoPs instead of
ARDC’s. And of course we also want us to be able to talk to a radio-only network in the
Bermudas that is connected via BGP.
We do not want to force anyone to use the PoPs. Yes, they will make it easier to connect,
but only for the people that want a production-grade connection. Not for the ones that
want to learn BGP or like to set up antennae, etc. It’s not just one category of people
that want the same thing in this network. It’s many, and we should serve them all.
This is what was discussed and we got entangled in
implementation decisions (like "are those PoPs to
be hardware routers supplied by ARDC or is it better to use VPSes in the cloud") and
at some time the
discussion was taken offline by the TAC, never to be heard about again.
In this solution, there is no reason at all to artifically split the network in intranet
and internet sections
because the decision how to route can be delegated to the PoP, which obviously runs
software capable
of dynamic- and policy routing.
Yes, in the network you describe, if you add a few rules and a few additional technical
solutions, you could solve “a” / “your” problem. But not everyone else’s. The ARDCs PoPs
don’t solve for how I want to connect to this network. So if we just go ahead and force a
single way, a single technical solution for a social problem, then I personally believe
that we will fail. We’re going to leave many more users either completely excluded or
unhappy.
And that’s something that the TAC and ARDC probably do not want to do. This is a resource
for all of us, and we should support all the use cases. Not just the ones we want to use,
or consider useful, or important.
That’s the main argument here.
I hope that helps,
Antonis