[155399] in North American Network Operators' Group
Re: IRON vs. BGP (was Re: BGPttH. Neustar can do it, why can't we?)
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Aug 7 14:41:32 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <jvrkho$pro$1@dough.gmane.org>
Date: Tue, 7 Aug 2012 11:37:18 -0700
To: Wes Felter <wmf@felter.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Aug 7, 2012, at 10:50 , Wes Felter <wmf@felter.org> wrote:
> On 8/6/12 8:04 PM, Owen DeLong wrote:
>=20
>> The goal here was to make this as simple and cost-effective as the =
NAT-based
>> IPv4 solution currently in common use. There's no reason it can't be =
exactly that.
>>=20
>> It does provide advantages over the NAT-based solution (sessions can =
survive
>> failover).
>=20
> What do people think about Fred Templin's IRON multihomed tunneling =
approach (or LISP, I guess it can do it)? IRON should give you =
multihoming with stable IPv4 and IPv6 PA prefixes, even for incoming =
traffic. It's less reliable than BGP in theory since you'd be virtually =
single-homed to your IRON provider but that might be a worthwhile =
tradeoff since staying up is pretty much their purpose in life.
>=20
> You'd have to pay a third provider to terminate your tunnels, but that =
might be cheaper than paying an extra BGP tax to both of your physical =
providers. IRON appears to require much less configuration than BGP and =
it can also provide IPv6 over v4-only providers (good luck finding *two* =
broadband providers in the same location that provide IPv6 and BGP).
>=20
> --=20
> Wes Felter
> IBM Research - Austin
>=20
>=20
>=20
I think IRON has some promise as well and might be interesting in some =
scenarios.
I think developing both is worth while. Different tools for different =
jobs.
Owen
