[142807] in North American Network Operators' Group
Re: in defense of lisp (was: Anybody can participate in the IETF)
daemon@ATHENA.MIT.EDU (Fred Baker)
Wed Jul 13 13:28:54 2011
From: Fred Baker <fred@cisco.com>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3C65077@EMBX01-WF.jnpr.net>
Date: Wed, 13 Jul 2011 13:28:04 -0400
To: Ronald Bonica <rbonica@juniper.net>
Cc: North American Network Operators' Group <nanog@nanog.org>,
Scott Brim <scott.brim@gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 13, 2011, at 12:02 PM, Ronald Bonica wrote:
> At this point, it might be interesting to do the following:
>=20
> - enumerate the operational problems solved by LISP
> - enumerate the subset of those problems also solved by RFC 6296
> - execute a cost/benefit analysis on both solutions
I'll let a LISP advocate state the values of LISP. My perception: it's a =
lot of overhead for what you actually get, comparable to building what =
Cisco once called "fast switching" into the network.
In looking at 6296, I was trying to find a way to make edge networks be =
willing to use PA addresses instead of PI. If you have one ISP and never =
want to change ISPs, PA is wonderful; if you have multiple ISPs, the =
prevailing multihoming model in the IETF calls for you to have a subnet =
from each of your upstream prefixes on each LAN and to have your host =
divine which address pair implies the most acceptable route to your =
destination. If you have any ISP's prefix on your LAN and you want to =
remove the ISP (change to a different one, stop using one, whatever), =
you are somehow buried in renumbering (See RFC 4192). Edge networks are =
not crazy about renumbering, and they're not crazy about having a prefix =
per ISP on each LAN - hence PI. So, to get edge networks to use PA =
addresses, I reason that the edge network needs an address that is not =
derived from its upstream, and it has to be translated to the prefix of =
the upstream. The other factor (how to not require a change to TCP/UDP =
checksums) is the checksum update.
So to my way of thinking, NPTv6 provides a way to statelessly (e.g. =
scalably) enable any host to talk with any host and at the same time =
make the edge network look PA to the upstream, has the managability =
characteristics of PI in the edge network, and not have to change =
TCP/UDP.
LISP, to my knowledge, provides no way to push back on route table =
growth (it moves it from the transit network to the edge network, but =
the edge network still has to deal with it).
To my mind, if you liked stateful NAT in IPv4, you'll like stateless =
NPTv6 in IPv6 better.
With that, I'll return you to your more operational musings. I'm with =
the IETF. Please feel free to inform the world on how clueless I am =
operationally. I'm already convinced of the fact; that's why I talk with =
and listen to operators.=
