The disadvantage of the IPIP mesh it that it cannot cope with node outages or rerouting to users. So, when the IPIP mesh would be used as the backbone between the PoPs, the functions of PoP failover and redundancy by connecting to multiple PoPs or using a fallback mechanism (connect to an alternative PoP when one is unreachable) cannot be realized.
To have that, we need a (possibly partial) tunnel mesh between the PoPs, where a routing protocol like BGP is used between the PoPs so they can tell eachother about the connected users and their subnets, instead of the "static" system that the IPIP mesh uses. (where routing of a subnet to a PoP/gateway is fixed and determined by configuration only, not by network state)
So I think to have a real improvement in the network, the IPIP mesh as it exists now should be abandoned. Of course first the PoP network can be built first, then the users can be encouraged to move over, then the IPIP mesh can be shut down. Large announcements on the IPIP mesh would be moved first, end-users can follow later.
Rob
On 5/27/22 12:26, Marius Petrescu via 44net wrote:
But the use of POPs does not preclude keeping the current mesh.
From the point of view of the existing users, POPs are just gateways in the mesh, announcing a bigger network, like e.g. a /16 for national services, maybe even a /16 via BGP if possible. Nothing changes at first, and established setups will continue to work, and there is no change needed to their configurations. Of course, if they want, they can alter their setup later on.
It is not changing/replacing existing functionalities, but adding to them.
At least this is how I would see such a development.
Marius
On 27/05/2022 13:04, Rob PE1CHL via 44net wrote:
Marius,
I fully agree with that. But as you have seen, when suggestions are made here to change towards such a network, there always is negative feedback from some people who just do not want to change, and bring up "advantages" of the current IPIP mesh to explain why we should keep it like that. That is why I tried to provide solutions to enable those people to come on board.
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org