Subject: Re: [lisp] All Things LISP materials

From: [email-masked] (Noel Chiappa)
Date: Mon, 5 Aug 2013 10:59:46 -0400 (EDT)

> From: [email-masked]

    > LISP ... does not buy us a single spare IPv4 address!

It does not expand the namespace, no. But it could allow more efficient and
complete use of it (which is almost as good as an expansion). EIDs can be
allocated more densely from a fixed-size namespace than addresses (which
necessarily cannot be tightly packed) can.

	Noel

---

From: Sharon Barkai <[email-masked]>
Date: Mon, 5 Aug 2013 15:07:21 +0000

Sounds right.
It's just like saying that the invention of pointers in software engineering did not add RAM, nor did it intend to, but it did allow for the evolution of strong abstraction models and significant optimizations. 

--szb

On Aug 5, 2013, at 8:00 AM, "Noel Chiappa" <[email-masked]> wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: [email-masked]
Date: Mon, 5 Aug 2013 11:49:15 -0400 (EDT)

Thanks for confirming my point: 
LISP-DDT relies on globally unique Pv4 addresses and does not multiply the IPv4's unicast address space by the number of LISP-Locators.
That would only be possible if a FQDN were mapped (of course by DNS) into a unique pair {EID IPv4 unicast address; LISP Locator} which in return requires the user side to be involved.

..."EIDs can be allocated more densely"...  Well that is nothing compared with 64800 times 2^30 additional unicast addresses.Isn't it ?
..."Done: Proved that the solution can be purely network based".... If you carry a letter to your post office, which is destined for  Mr. Smith being the receiver, you wouldn't ask the service man to  add Mr. Smith'address all by himself, right ? 

But my email was questioning IPv6 in the first place. 16 Bytes address space that do NOTHING for routing !!! Which would rather rely on LISP-in-LISP locators (eventually)!
Having another huge multicast address space and yet relies on source unicast address (according to PIM) in addition to the multicast address! Plus LISP-Locator ???: (BTW: How is the LISP-multicast-locator designed (= info question)? Is there some LISP-Multicast-Locator FIB ? certainly not) . Furthermore: IPv6 defines anycast addresses without scopes !!! Why is LISP so sensitive to IPv6 and doesn't try to abolish/replace it?

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Noel Chiappa <[email-masked]>
An: lisp <[email-masked]>
Cc: jnc <[email-masked]>
Verschickt: Mo, 5 Aug 2013 5:00 pm
Betreff: Re: [lisp] All Things LISP materials

	Noel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Aug 2013 10:03:05 -0700

> LISP-DDT relies on globally unique Pv4 addresses and does not multiply the IPv4's unicast address space by the number of LISP-Locators.

If you register (IID, EID-prefix) 2-tuples to the mapping database, then you expand the private IPv4 address space. These 2-tuples map to globally allocated IPv4 or IPv6 RLOCs.

> That would only be possible if a FQDN were mapped (of course by DNS) into a unique pair {EID IPv4 unicast address; LISP Locator} which in return requires the user side to be involved.

Private addresses assigned to client machines typically are not servers, so they do not need DNS names assigned to them.

> ..."Done: Proved that the solution can be purely network based".... If you carry a letter to your post office, which is destined for  Mr. Smith being the receiver, you wouldn't ask the service man…

I don't get your point.

> But my email was questioning IPv6 in the first place. 16 Bytes address space that do NOTHING for routing !!! Which would rather rely on LISP-in-LISP locators (eventually)!

In RLOC space, an IPV6 can be aggregated in PA space just like IPv4 can.

> Having another huge multicast address space and yet relies on source unicast address (according to PIM) in addition to the multicast address! Plus LISP-Locator ???: (BTW: How is the LISP-multicast-locator designed (= info question)? Is

The size of the IPv6 multicast address space was not chosen by LISP. LOL. But the advantage of the size of the address can allow random allocation without the risk of collision and a central directory.

> there some LISP-Multicast-Locator FIB ? certainly not) . Furthermore: IPv6 defines anycast addresses without scopes !!! Why is LISP so sensitive to IPv6 and doesn't try to abolish/replace it?

Yes, an RLOC can be unicast or multicast and you can encapsulate a multicast packet sourced by an EID that can have an outer unicast or multicast header. Read RFC 6831 for more detail.

Dino