Subject: [lisp] draft-ietf-lisp-introduction - Design Principles and Use Cases

From: Ronald Bonica <[email-masked]>
Date: Sat, 11 Oct 2014 23:51:15 +0000

Folks,

In Section 2.1, we say that LISP is built on top of four basic design principles:

   - Locator/Identifier split
   - Overlay architecture
   - Decoupled data and control-plane
   - Incremental deployability

However, none of these design principles are unique to LISP. The IETF has produced many overlay architectures over the years and nearly all of them share these characteristics. 

Oddly, the one design principle that *is* truly unique to LISP is omitted from the list. That is, the route pull model.

Likewise, In Section 7, we site several use cases to which LISP might be applied. However, we say nothing about why LISP might provide a better solution than any of the other overlay architectures that the IETF has produced in years gone by. Does LISP provide a superior solution because of its one unique characteristic? 

In order to fix these problems, I suggest that we make the following changes to Section 2.1:

- add a bullet concerning route pull
- add a sentence saying that route pull is the only principle that is unique to LISP

A use case should be included in Section 7 only if route pulling makes the LISP solution superior to existing solutions.

Ron Bonica

---

From: Florin Coras <[email-masked]>
Date: Sat, 11 Oct 2014 17:58:29 -0700

Hi Ron,

> However, none of these design principles are unique to LISP. The IETF has produced many overlay architectures over the years and nearly all of them share these characteristics.

I could stand corrected, but out of the ones mentioned in RFC 6115, and 
which have also become RFCs, LISP is the only one with this set of 
properties.
> Oddly, the one design principle that *is* truly unique to LISP is omitted from the list. That is, the route pull model.

Nothing precludes the use of a "push model"  mapping system. That is, 
BGP could be used as a mapping-system as long as an adaptation layer as 
per RFC6833 is implemented.

> - add a bullet concerning route pull

Agreed.
> - add a sentence saying that route pull is the only principle that is unique to LISP

With this however, considering the points above, I disagree.

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

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 11 Oct 2014 21:01:34 -0400

> On Oct 11, 2014, at 7:51 PM, Ronald Bonica <[email-masked]> wrote:
> 

You left out one that is really important:

- A Mapping Database System

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 12 Oct 2014 01:20:05 +0000

Dino,

That too!

However, the mapping database system is not entirely unique to LISP. Every architecture that maps one address space to another needs a data base to maintain mapping information. The part that is unique to LISP is how the data is distributed

                                                                     Ron

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Saturday, October 11, 2014 9:02 PM
> To: Ronald Bonica
> Cc: [email-masked]
> Subject: Re: [lisp] draft-ietf-lisp-introduction - Design Principles and Use
> Cases
>

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 11 Oct 2014 21:32:34 -0400

Well everything tends to look the same but not in this case. This is the first mapping database that is really fully specified and tested at the network layer. 

Dino

> On Oct 11, 2014, at 9:20 PM, Ronald Bonica <[email-masked]> wrote:
> 
> Dino,
> 
> That too!
>

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 13 Oct 2014 00:05:15 +0200

Hi Ronald

Thanks for your comment.

I agree that none of such design principles are unique to LISP, but -I
think- you are reading them independently and they should be
considered the four of them *at the same time*. With this I expect
that the reader gets -very quickly- LISP's big picture.

I don´t think that pull is such a unique characteristic, DNS works
based on exactly the same principle: "pull locators".

Albert

---

From: "Chad Hintz (chahintz)" <[email-masked]>
Date: Sun, 12 Oct 2014 22:43:58 +0000

Hi Albert,

While it is not unique as you mentioned it is unique in comparison to traditional routing techniques. In addition the ability from the owner of the EID having the ability to specify how load balance/distribute inbound traffic is also a benefit we get from the pull model. I do agree we need to hit all 4 as you mentioned, but most end users who evaluate LISP in my experience usually highlight that the pull model and being able to control traffic inbound is a key reason the decide on LISP. With that said I believe it should be considered for addition in your document based on this. 

My 2 cents,

Chad Hintz

Sent from my mobile device, please excuse the spelling mistakes. 

> On Oct 12, 2014, at 6:05 PM, Albert Cabellos <[email-masked]> wrote:
> 
> Hi Ronald
> 
> Thanks for your comment.
>

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 13 Oct 2014 11:16:56 +0200

Hi,

I wonder how much is important to clarify whether or not a principle is unique to LISP.

I  tend to agree with Albert’s viewpoint, the document should give the list of principles LISP is based on so to provide the reader the big picture of LISP in a nutshell.

The only remaining question is whether or not we want to add a bullet concerning the push/pull model & Mapping database.

ciao

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 13 Oct 2014 11:16:56 +0200

Hi,

ciao

Luigi

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 13 Oct 2014 10:31:11 -0400

> 
> The only remaining question is whether or not we want to add a bullet concerning the push/pull model & Mapping database

Well since a large portion of the document discusses the mapping system, I would say yes. 

Dino

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 13 Oct 2014 18:22:40 +0200

Hi all

What about this (as a new item in section 2.1)?

* Pull Architecture: With this principle the network state is stored
at the control-plane -in a potentially distributed database- and
retrieved on-demand by the data-plane. Pull architectures allow to
push important routing mechanisms such as Traffic Engineering to the
control-plane, alleviating the data-plane. At the same time they
require of additional techniques to handle data-plane events, such as
network failures.

Albert

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 13 Oct 2014 13:18:42 -0700

> require of additional techniques to handle data-plane events, such as

Well even though we like to stress a Pull architecture with LISP, we all know well that if xTRs run LISP-ALT that it is very much a push archtecture. 

See (I hope Alia is listening), it is not about a LISP versus BGP control-plane, because one of the RFC documented mapping database transport system is LISP-ALT which IS BGP.

LISP is indeed a "cached architecture" which means the FIB needs to be populated on demand. But if the state is local in a database, LISP-ALT BGP RIB, then the information is available locally.

When I was at cisco, we did some customer testing where the customer wanted to use BGP as the mapping database so FIB hardware lookups cache-missed, then the BGP RIB was consulted. They had requirements to not go outside of the box to get the cache populated. Turns out they wanted small hardware FIBs and had large software RIBs, hence using LISP to push via BGP was a naturual fit.

Dino

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Oct 2014 00:51:09 +0200

Hi Ron,

Route pull is not unique to LISP. Just take a look at RTC or ORF ..
those are classic route pull mechanisms already deployed in many
networks for BGP today for various AFs.

What I however find positively unique to LISP is a boundary less (read
no domain/as boundary) IP encapsulation for various kinds of data
traffic + as Dino already mentioned an overlay mapping plane to
distribute the bindings.

The only alternative I see for the analogy of such boundary less
encapsulation would be ILNP, but both are a bit different in their
respective architectures. As we know ILNP is host based and LISP is
network based solutions. Each have their pros and cons and I we have
already went in RRG on pages of discussions reg both.

Sure as we speak there are efforts to carry remote next hops in BGP to
sort of allow for similar boundary less encapsulation, but carrying
those inbound of BGP is subject to be filtered anywhere in the path
sort of breaking the game. Hence having separate mapping plane does
solve that problem quite well.

Best,
R.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 16 Oct 2014 16:08:38 -0700

> networks for BGP today for various AFs.

How about a more obvious example. ARP.  ;-)

> solve that problem quite well.

The LISP-ALT was an overlay control-plane so filtering COULD HAVE been less of an issue because less parties would be involved in running it versus the number of people/organizations that run BGP today.

Dino