26 Apr
2014
26 Apr
'14
12:07 a.m.
On 04/25/2014 03:41 PM, Michael E Fox - N6MEF wrote:
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
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 ...?