[161568] in North American Network Operators' Group
Re: routing table go boom
daemon@ATHENA.MIT.EDU (Luigi Iannone)
Wed Mar 20 07:42:43 2013
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <5148F377.90704@necom830.hpcl.titech.ac.jp>
Date: Wed, 20 Mar 2013 12:42:26 +0100
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi Masataka,
On 20 Mar. 2013, at 00:23 , Masataka Ohta =
<mohta@necom830.hpcl.titech.ac.jp> wrote:
> David Conrad wrote:
>=20
>> One of the advantages I see in LISP(-like) solutions is that it
>> allows multi-homing without having to do BGP...
>=20
> By having a lot larger table than BGP.
>=20
> =
http://datatracker.ietf.org/doc/draft-ietf-lisp-architecture/?include_text=
=3D1
>=20
> It should be noted that the caching spoken of here is likely not
> classic caching, where there is a fixed/limited size cache, and
> entries have to be discarded to make room for newly needed entries.
> The economics of memory being what they are, there is no reason to
> discard mappings once they have been loaded (although of course
> implementations are free to chose to do so, if they wish to).
LISP will not have huge caches:
(1) http://www.ietf.org/proceedings/69/slides/RRG-4.pdf
and more recently:
(2) https://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf
>=20
> Worse, the table is updated so frequently.
>=20
FIrst of all the table a cache is filled on-demand, so you update only =
what you need, secondly (1) shows that this refresh traffic is in the =
same order of magnitude of DNS requests. If you are able to support DNS =
you are able to deal with LISP cache update traffic.
> =
http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/?include_text=
=3D1
>=20
> A node may have more than one
> RLOC, or its RLOC may change over time (e.g. if the node is mobile),
> but it keeps the same EID.
>=20
> Assuming that there are 4G mobile devices in the world, the
> mapping table has more than 4G entries each updated every
> minute or second.
This is true in a push model like BGP not in LISP, which is a pull model =
(on-demand).
>=20
> The problem of LISP is that it breaks the end to end principle
> to introduce intelligent intermediate entities of ITR and ETR.
true
>=20
> Mobility can best be handled end to end by end systems of MN,
> HA and, optionally, CN.
>=20
which rely on intelligent anchor nodes spread in the network, where is =
the difference?=20
Luigi
> Masataka Ohta
>=20
> PS
>=20
> Considering that the Internet is connectionless because all the
> routers have routing tables covering all the IP addresses in
> realtime, LISP won't be operational unless most of routers
> in DFZ have full mapping table in realtime.
>=20
