[133490] in North American Network Operators' Group
Re: Start accepting longer prefixes as IPv4 depletes?
daemon@ATHENA.MIT.EDU (Luigi Iannone)
Fri Dec 10 09:56:58 2010
From: Luigi Iannone <luigi@net.t-labs.tu-berlin.de>
In-Reply-To: <201012101130.oBABUkcp008409@mail.r-bonomi.com>
Date: Fri, 10 Dec 2010 15:56:46 +0100
To: Robert Bonomi <bonomi@mail.r-bonomi.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Dec 10, 2010, at 12:30 , Robert Bonomi wrote:
>> =46rom nanog-bounces+bonomi=3Dmail.r-bonomi.com@nanog.org Wed Dec 8 =
15:36:44 2010
>> Date: Wed, 08 Dec 2010 15:34:47 -0600
>> From: Jack Bates <jbates@brightok.net>
>> To: David Conrad <drc@virtualized.org>
>> Subject: Re: Start accepting longer prefixes as IPv4 depletes?
>> Cc: NANOG list <nanog@nanog.org>
>>=20
>> On 12/8/2010 3:12 PM, David Conrad wrote:
>>> Cameron,
>>>=20
>>> On Dec 8, 2010, at 12:01 PM, Cameron Byrne wrote:
>>>> I believe a lot of folks think the routing paths should be tightly
>>>> coupled with the physical topology.
>>>=20
>>> The downside, of course, being that if you change your location
>>> within the physical topology, you have to renumber. Enterprises =
have
>>> already voted with their feet that this isn't acceptable with IPv4
>>> and they'll no doubt do the same with IPv6.
>>>=20
>>>> In a mature IPv6 world, that is sane, i am not sure what the real
>>>> value of LISP is.
>>>=20
>>> Sanity is in the eye of the beholder. The advantage a LISP(-like)
>>> scheme provides is a way of separating location from identity,
>>> allowing for arbitrary topology change (and complexity in the form =
of
>>> multi-homing) without affecting the identities of the systems on the
>>> network. Changing providers or multi-homing would thus not result in
>>> a renumbering event or pushing yet another prefix into the DFZ.
>>>=20
>>=20
>> I think the issue, and correct me if I'm wrong, is that LISP does not=20=
>> address issues of traffic engineering? A lot of the additional routes =
in=20
>> DFZ are there specifically to handle traffic engineering.
>=20
LISP has TE properties based on priority of the locators and weight (for =
load balancing).
You can read:
http://inl.info.ucl.ac.be/system/files/inm08.pdf
Luigi
> The primary thing that a LISP-like approach accomplishes is the =
'de-coupling"
> of infrastructure and leaf networks. You can mess with either one, =
w/o
> having any effect on the other.
>=20
>=20
>=20
