On 04/25/2014 03:41 PM, Michael E Fox - N6MEF wrote:
So how do you do it now? You use an IPIP tunnel (another type of VPN), nothing changes for the end user except, his tables get much smaller, she routes local 44.x.x.x traffic locally and uses an IPIP tunnel to a tier or border router.
So you're creating multiple new single points of failure. With your plan, I can get to a few other local gateways. Anything else has to go through this new single point of failure locally, plus, presumably, and another single point of failure near my destination. So most worldwide connectivity would now have to traverse two single points of failure that currently don't exist. This is good because ...?
I'd like to keep the IPIP mesh (perhaps enhanced with other protocols laid on top of each IPIP), since it is the fastest way of getting from network A to network B, where both are non-Internet-BGP'd 44nets.
What I would like to see in addition though are VPN dial-ins (perhaps IPIP based, perhaps not) that provide the Internet transit, not inter-44net transit. This is so 44net users aren't having to spend lots of money arranging Internet BGP peers. A heirarchy of such gateways can be established. For example, Western Washington can run a gateway that serves its populace and announces 44.24/16. This is less-specific than user announcements but more-specific than the UCSD announcement. So it would simultaneously not deprive end-users of Internet BGP, and jump in front of UCSD needing to handle the traffic. Should UCSD fail, the Western Washington gateway stays up and any 44net<->Internet traffic for Western Washington users is unaffected by the UCSD failure. Should the Western Washington gateway fail, UCSD can take over (via its 44/8) and relay packets to users as it gets them. Users would need to hold connections with both gateways.
I think this is how my proposal and John's proposals differ. I'd like to keep the IPIP mesh, not replace it with VPN concentrators. I'd just like to augment the UCSD single point of Internet transit with additional regional Internet transit points.
Lastly, it's also possible for a regional gateway like the Western Washington one, to also announce 44/8 and provide Internet transit for all 44nets. It would then compete (based on a least-hop basis, and some other BGP attributes) with other such gateways (eg: UCSD) for the duty of delivering Internet traffic. This fixes the single point of failure right now @ UCSD. There are some open design questions in the implementation of these 44/8 gateways, but those details can be worked out.
--Bart