It should always be possible to have multiple options,
we should not wire the possibilities into the network design.
Rob
Making 2 sandbox to play with is not limiting the choice, it is creating choice. Right now
there are no choice or almost no choice.
First choice connect with ipip tunnel to the ampr ipip mesh network. Be isolated on a high
latency network with a high level of difficulty that the average ham have difficulty to
connect to. and it is an outdated solution to say the least.
Second choice connect to the internet, have VPS or server in a datacenter that can
advertise by bgp your /24 at a minium and then with a vpn or other tunneling methode bring
back those advertise ip address to your device or computer. Again, a pretty heavy task to
do for the lambda ham. the entry level is steap to say the least.
Next choice, IF you are are lucky someone have already done the heavy lifting and a RF
link is possible for you to connect to net 44. but you dont know if that net will let
anyone on the internet reach you and if you can connect to ham only content or provide ham
only content securely and in concordence with your country law.
That's it. not a lot of choice, lot of maybe, lots of complication.
The TAC proposition is doing a simple thing.
Provide 2 sand box. one where ham's and the rest of the world can interact with each
other in a very simple thight utilisation of the address space to limit the route number
and have a low latency for everyone. That would be 44.0/10
Next sand box is a place where ham's intercat with ham's , they all get to build
their own little sand castle just as they like, again with an easy to program routing
system low level of entry for beginner and the best, a low latency. now I am talking about
44.128/10
And to do such thing there would be a need for some pop's all over the globe to handle
idying and intenal/external routing table for all pop connected networks.
The pop's would do all the heavy lifting to have simple networkconfiguration AND
assurance of source of traffic. This would really help people in country that have strict
laws for relaying traffic and other such limitation.
This would also help in creating and developping RF network for occupation and utilisation
of our microwaves bands.
And this would bring ham digital radio communication into the 21 first century.
Pierre
VE2PF
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de Rob
PE1CHL via 44Net <44net(a)mailman.ampr.org>
Envoyé : 11 août 2021 10:05
À : 44net(a)mailman.ampr.org
Cc : Rob PE1CHL
Objet : Re: [44net] A new era of IPv4 Allocations : Agree
On 8/11/21 3:23 PM, Toussaint OTTAVI via 44Net wrote:
Le 11/08/2021 à 15:03, pete M via 44Net a écrit :
the backbone is the POP ardc are proposing to
build.
In my idea :
- POPs are the equivalent of our current regional gateways. They are managed locally by
us (sysadmins, coordinators, local teams...), not by ARDC ! Basically, we migrate
independent and different systems to a common standardized model.
- ARDC provides backbone for interconnecting POPs all over the world. This includes
network links (to be defined), portal, all required back-office tools, administration, and
support for POP maintainers.
I think ARDC can offer end-user PoP access to their backbone themselves, and regional
groups can always decide to setup their own access which connects to such a PoP and allows
their own end-users to connect.
The reason I think it would be best to support both these models is:
- some countries already have the infrastructure to connect end-users and to route their
traffic, no need to de-comission that and have people migrate
- some countries have no access points and no active local teams wanting to setup such
things, and they can connect directly to an ARDC PoP.
Some users also may not think their local access point is reliable enough and want to
connect to an ARDC PoP or even more than one.
It should always be possible to have multiple options, we should not wire the
possibilities into the network design.
Rob
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net