Subject: [lisp] Updated Intro section for lisp-introduction

From: Albert Cabellos <[email-masked]>
Date: Thu, 2 Oct 2014 01:53:37 +0200

Hi all

This is the proposed Introduction following the comments on the list:

This document introduces the Locator/ID Separation Protocol (LISP)
[RFC6830] architecture, its main operational mechanisms and its design
rationale. Fundamentally, LISP is built following a well-known
architectural idea: decoupling the IP address overloaded semantics.
Indeed and as pointed out by [Chiappa], currently IP addresses both
identify the topological location of a network attachment point as
well as the node's identity.  However, nodes and routing have
fundamentally different requirements, routing systems require that
addresses are aggregatable and have topological meaning, while nodes
require to be identified independently of their current location.

LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
RLOCs (Routing LOCators), both are -typically, but not limited to-
syntactically identical to the current IPv4 and IPv6 addresses.  EIDs
are used to uniquely identify nodes irrespective of their topological
location and are typically routed intra-domain. RLOCs are assigned
topologically to network attachment points and are typically routed
inter-domain.  With LISP, the edge of the Internet -where the nodes
are connected- and the core -where inter-domain routing occurs- are
architecturally separated and interconnected by LISP-capable routers.
LISP also introduces a publicly accessible database, called the
Mapping System, to store and retrieve mappings between identity and
location.  LISP-capable routers exchange packets over the Internet
core by encapsulating them to the appropriate location.

By taking advantage of such separation between location and identity,
LISP offers Traffic Engineering, multihoming, and mobility among
others benefits. Additionally, LISP’s approach to solve the routing
scalability problem [RFC4984] is that with LISP the Internet core is
populated with RLOCs which can be quasi-static and highly
aggregatable, hence scalable [Quoitin].

It is important to note that this document does not specify or
complement the LISP protocol.  The interested reader should refer to
the main LISP specification [RFC6830] and the complementary documents
[RFC6831],[RFC6832],[RFC6833],[RFC6834],[RFC6835], [RFC6836] for the
protocol specifications along with the LISP deployment guidelines
[RFC7215].

Albert

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 1 Oct 2014 17:36:58 -0700

The text content looks good but why so much mid sentence hyphenation?

Dino

> On Oct 1, 2014, at 4:53 PM, Albert Cabellos <[email-masked]> wrote:
> 
> Hi all
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Albert Cabellos <[email-masked]>
Date: Thu, 2 Oct 2014 02:39:36 +0200

I copied it from Word, will be removed for the draft.

Thanks!

Albert

---

From: Christian Cassar <[email-masked]>
Date: Thu, 02 Oct 2014 15:45:37 +0100

Hello Albert,

I have been through the current version of the document, and it reads well - thanks!

I have added a few nits below - feel free to pick and choose:

2.3 Data-plane

In "This header is created by the source end-host and remains unchanged."
"remains unchanged" -> "is left unchanged by LISP data plane processing on the ITR and ETR". (TTL processing, as part of IP forwarding, is done on that header as usual.)

3.2.  RLOC Reachability

You describe RLOC probing in this section which is expected. However, you may also want to allude to RLOC probing in the previous Cache Management section too; an ITR implementation can exploit RLOC probing to infer instances where it might be sensible to refresh entries in a map cache.

3.4. MTU Handling

The Stateless comment is a tad misleading. I think the salient point in the stateless mechanism is that the effective MTU is assumed from ITR's perspective. The fact that ITR fragments packets that are too big, and can be fragmented is common across both stateless and stateful mechanisms.

Couple of typos in here (defeines and framgented).

====

The rest are exclusively style/spelling comments - feel free to pick and choose. Oh, and I should add that English is my second language (as if it weren't obvious already) - so you would do better to get some one with a good command of the language to give it a once over.

2.1.  Design Principles:

"allowing to deploy new protocols" -> "allowing deployment of"
"resulting from a low deployment cost." -> "resulting in low cost of deployment"

In the overlay section you might want to extend the Overlay Architecture with "as well as other decoupling benefits arising from deployment of an overlay architecture". I am sure the ability to experiment with new protocols over existing infra is an important benefit of overlays, but perhaps not the most important one.

2.2 Overview of the architecture

"The edge are LISP sites" -> "The edge consists of LISP sites"

"EIDs can be are typically
   Provider Independent (PI [RFC4116]) addresses and can be thought as
   they don't contain intra-domain topological information. "

-> "EIDs are typically Provide Independent (PI [RFC4116]) addresses and can thought of as devoid of intra-domain topolical information."

"has a strong emphasis in" -> " emphasizes"

"packt" -> "packet"

"lookup key, in turn it" -> "lookup key. In turn it". Fullstops are free. Would be good to sprinkle a few more in that paragraph.

2.3. Data-Plane

"that connect the EID with the RLOC space (ITR) and viceversa (ETR)"

->

"that connect the EID to the RLOC space (ITR) and the RLOC to the EID space (ETR)"

"that it is not verified in reception"

->

"such that it is not verified on reception"
 
"The Instance ID field is used to
   distinguish traffic that belongs to multiple tenants inside a LISP
   site, and that may use overlapped but logically separated addressing
   space."

->

"The Instance ID field is used to distinguish traffic to/from different tenant address spaces at the LISP site."

2.3.2.  LISP Forwarding State

I would drop "to increase the forwarding speed of subsequent packets addressed to the same EID prefix."

"set by the ETR" -> "advertised by ETR"

2.4.2 Mapping System Interface

"Please note that a Map-Reply may contain a negative reply if the queried EID is not part of the LISP EID space."
->
"Please note that a Map-Reply may contain a negative reply, for example, if the queried EID is not part of the LISP EID space."

2.4.3. Mapping System

"responsible of storing mappings"
->
"responsible for storing mappings."

"may be used store" -> "may be used to store"

"The LISP WG has discussed for the Mapping System architecture the
   four main techniques available in distributed systems, namely:"

->

"The LISP WG has explored application of the following distributed system techniques  to the Mapping System architecture:"

2.5 Internetworking Mechanisms

"Proxy Engress Tunnel Router (PETR)" -> "Proxy Egress Tunnel Router (PETR)"

"allows to overcome " -> "overcomes"

"Finally, the RLOC of PETRs must be statically configured in ITRs." -> "There is no specified provision for the distribution of PETR RLOC addresses to the ITRs"

One more inline....

> architecturally separated and interconnected by LISP-capable routers.

The word 'architecturally' doesn't seem to add much here, and 'are' might be replaced by 'can be' - for example my IPv6 host may be reachable over LISP over IPv4 and directly over IPv6.

Thanks again
Christian

> others benefits. Additionally, LISPâ€™s approach to solve the routing

---

From: Albert Cabellos <[email-masked]>
Date: Sun, 5 Oct 2014 23:30:58 +0200

Hi Christian

Thanks, see inline my comments:

> "remains unchanged" -> "is left unchanged by LISP data plane processing on the ITR and ETR". (TTL processing, as part of IP forwarding, is done on that header as usual.)

Ok, thanks.

> You describe RLOC probing in this section which is expected. However, you may also want to allude to RLOC probing in the previous Cache Management section too; an ITR implementation can exploit RLO…

What about adding the following sentence at the end of section 3.1:

Finally it is worth noting that in some cases an entry of the
map-cache can be proactively refreshed using the mechanisms described
in the section below.

> The Stateless comment is a tad misleading. I think the salient point in the stateless mechanism is that the effective MTU is assumed from ITR's perspective. The fact that ITR fragments packets that…

What about this:

Stateless:  With this mechanism the effective MTU is assumed from the
ITR's perspective, in case that a packet is too big reassembly is
typically performed at the destination host.

> The rest are exclusively style/spelling comments - feel free to pick and choose. Oh, and I should add that English is my second language (as if it weren't obvious already) - so you would do better…

Thanks! We´ll apply all your suggestions.

> The word 'architecturally' doesn't seem to add much here, and 'are' might be replaced by 'can be' - for example my IPv6 host may be reachable over LISP over IPv4 and directly over IPv6.

Agreed, what about logically?

> Christian

Thanks

Albert

---

From: Albert Cabellos <[email-masked]>
Date: Sun, 5 Oct 2014 23:46:09 +0200

Hi all

I would like to ask the WG about this section, should we we describe
the problem that LISP is trying to solve in the Introduction section?

Some people suggest that we should while others that it provides too
many details.

Below you can find a sample description of the problem statement.

Thanks

Albert

   There is a rough consensus that the Internet routing and addressing
   system is facing severe scalability issues [RFC4984].  Specifically,
   the growth in the size of the routing tables of the Default-Free Zone
   (DFZ) is accelerating and showing a supra-linear slope [DFZ].  The
   main driving force behind this growth is the de-aggregation of BGP
   prefixes, which results from the existing BGP multihoming and traffic
   engineering mechanisms that are used -at the time of this writing- on
   the Internet, as well as non-aggregatable address allocations.

   This issue has two profound implications, on the one hand Internet
   core routers are exposed to the network dynamics of the edge.  For
   instance this typically leads to an increased amount of BGP UPDATE
   messages (churn), which results in additional processing requirements
   of Internet core routers in order to timely compute the DFZ RIB.
   Secondly, the supra-linear growth imposes strong requirements on the
   size of the memory storing the DFZ FIB.  Both aspects lead to an
   increase on the development and production cost of high-end routers,
   and it is unclear if the semiconductor and router manufacturer
   industries will be able to cope, in the long-term, with such
   stringent requirements in a cost-effective way[RFC4984].

   Although this important scalability issue is relatively new, the
   architectural reasons behind it are well-known many years ago.
   Indeed, and as pointed out by [Chiappa], IP addresses have overloaded
   semantics.  Currently, IP addresses both identify the topological
   location of a network attachment point as well as the node's
   identity.  However, nodes and routing have fundamentally different
   requirements, routing systems require that addresses are aggregatable
   and have topological meaning, while nodes require to be identified
   independently of their current location.

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 5 Oct 2014 17:48:07 -0400

> Finally it is worth noting that in some cases an entry of the

"... an entry in the map-cache ..."  

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 5 Oct 2014 17:52:37 -0400

> On Oct 5, 2014, at 5:46 PM, Albert Cabellos <[email-masked]> wrote:
> 
> Hi all
> 

I think LISP solves multiple problems and adds many new capabilities. It would be hard to include all of them. Including the original problem statement is just that, the first problem that LISP solved. But as LISO evolved we found other, arguably, more important than the original problem statement. 

So I vote for less detail. If the group really wants to identify the problems, I would suggest doing it Inna couple of statements and simply list the problems LISP solves rather describing all of them (or describing the original problem statement). 

Dino

---

From: "Chad Hintz (chahintz)" <[email-masked]>
Date: Sun, 5 Oct 2014 22:07:05 +0000

I agree, I would vote to less detail and maybe listing some of the problems its solves but mention they will not be covered in detail. It always a good idea to list why it was created or the original problem it was aimed at fixing. 

Chad Hintz

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

> On Oct 5, 2014, at 5:52 PM, Dino Farinacci <[email-masked]> wrote:
> 
> 
> 
>

---

From: Sharon Barkai <[email-masked]>
Date: Mon, 6 Oct 2014 01:56:33 +0000

We could look at the "original" problem as early signs of the reduced correlation between end-point IP identity and topological locations.

Initially the toll was just bigger and bigger routing tables, these were in retrospect just early signs. As more network evolution factors start to way-in (virtualization, mobility, things..) the non correlation situation becomes unsolvable without the specified LISP IP indirection architecture.

--szb

> On Oct 5, 2014, at 2:52 PM, Dino Farinacci <[email-masked]> wrote:
> 
> 
> 
>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 5 Oct 2014 22:15:38 -0400

> On Oct 5, 2014, at 9:56 PM, Sharon Barkai <[email-masked]> wrote:
> 

Yes, agree. 

Dino

---

From: Florin Coras <[email-masked]>
Date: Sun, 05 Oct 2014 20:31:40 -0700

My take is less details as well. Being an intro document, focus should 
be on the problem LISP was originally chartered to solve. Having said 
this, let us know if you have specific use cases we didn't mention in 
draft-saucez-lisp-impact.

Florin

---

From: Sharon Barkai <[email-masked]>
Date: Mon, 6 Oct 2014 05:48:19 +0000

We could state the topo-id correlation as the problem, prefix fragmentation and growing routing tables as first symptoms. 

At 0 correlation routing == switching, no scale. Something needs to be done, hence the draft.

Can connect the dots for those who try to address network virtualization using lisp as in the newer drafts.

--szb

> On Oct 5, 2014, at 8:31 PM, Florin Coras <[email-masked]> wrote:
> 
> My take is less details as well. Being an intro document, focus should be on the problem LISP was originally chartered to solve. Having said this, let us know if you have specific use cases we didn't mention in draft-saucez-lisp-impact.
> 
> Florin
>

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 6 Oct 2014 01:01:27 -0700

Hello Albert,

epic task - I appreciate your work :-)
And I agree with Florin and others that less may be more. What I mean is:

- I think it's generally accepted that stopping or reversing the constant 
growth of routing tables is a good thing. No need to explain the potential 
problems of large(r) tables.

- no doubt it's a good idea to refer to this original reason why LISP was 
started

- I would tend towards statements that are less fundamental, e.g.

    However, nodes and routing have fundamentally different
    requirements,

is IMHO not correct as a general statement. There are millions of nodes that 
are happy with the address they get from their DSL or cable provider - which 
is solely based on the provider's routing plan. These nodes simply don't care 
about topology vs. identity.

True is that newer phenomena like multihoming, mobility, over-the-top, [...] 
can be addressed by this view that node location != node identity. And yes, 
this shows that LISP is chasing something bigger than "just" Internet routing 
table size.

Still have to read more of your document :-)

Regards, Marc

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Mon, 6 Oct 2014 10:18:08 +0200

IMHO we should make clear for readers that LISP is now beyond its original
scope, and even without explicitly listing them, implicitly point newcomers
to the latest use-cases. In that sense I agree with Sharon that pointing to
topo-ID as the problem is a good step towards that direction.

Alberto

On Mon, Oct 6, 2014 at 7:48 AM, Sharon Barkai <[email-masked]>
wrote:

> We could state the topo-id correlation as the problem, prefix
> fragmentation and growing routing tables as first symptoms.
>
> be on the problem LISP was originally chartered to solve. Having said this,
> let us know if you have specific use cases we didn't mention in
> >> I agree, I would vote to less detail and maybe listing some of the
> problems its solves but mention they will not be covered in detail. It
> always a good idea to list why it was created or the original problem it
> was aimed at fixing.
> >>
> >> Chad Hintz
> >>
> >>> I think LISP solves multiple problems and adds many new capabilities.
> It would be hard to include all of them. Including the original problem
> statement is just that, the first problem that LISP solved. But as LISO
> evolved we found other, arguably, more important than the original problem
> statement.
> >>>
> >>> So I vote for less detail. If the group really wants to identify the
> problems, I would suggest doing it Inna couple of statements and simply
> list the problems LISP solves rather describing all of them (or describing
> the original problem statement).
> >>>
> >>> Dino
> >>>

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 6 Oct 2014 10:41:52 +0200

Hi,

In my personal opinion (and similar to what other people already stated) less text is better.

A couple of sentence stating what triggered the LISP design and a couple of sentences stating the flexibility LISP introduce in the overall Internet architecture would be enough.

May be the current text could be partially shifted in the appendix describing the history of LISP.

ciao

Luigi

On 06 Oct 2014, at 10:18, Alberto Rodriguez-Natal <[email-masked]> wrote:

> IMHO we should make clear for readers that LISP is now beyond its original scope, and even without explicitly listing them, implicitly point newcomers to the latest use-cases. In that sense I agree with Sharon that pointing to topo-ID as the problem is a good step towards that direction.
> 
> Alberto
> 
> On Mon, Oct 6, 2014 at 7:48 AM, Sharon Barkai <[email-masked]> wrote:

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 6 Oct 2014 01:57:13 -0700

if you have a hammer, everything looks like a nail :-)
(also known as "Maslow's hammer")

Seriously, LISP is about identity/topology separation. This doesn't mean 
every problem you address with LISP is a topo-id problem nor is topo-id 
necessarily the fundamental underlying problem - if such exists at all.

An example is virtualization/multi tenancy. To address this, one adds the 
Instance-ID field to the LISP data header. But the fundamental aspect is that 
you attach an "ID" to the packet, not that you separate EID from RLOC. MPLS 
labels can do this job (assuming your network know how to handle labels).

> scope, 

I do agree with this statement.

Regards, Marc

---

From: Christian Cassar <[email-masked]>
Date: Mon, 06 Oct 2014 11:08:38 +0100

Hello Albert,

inline...

> map-cache can be proactively refreshed using the mechanisms described

Looks good (with Dino's comment incorporated).

More...

> typically performed at the destination host.

Looks good... perhaps broken into two sentences.

Stateless:  With this mechanism the effective MTU is assumed from the
ITR's perspective. If a payload packet is too big for the effective MTU, and
can be fragmented, the payload packet is fragmented on the ITR, such that
reassembly is performed at the destination host.

More...

<snip>
 
> Agreed, what about logically?

Fine.

Thanks

Christian

> .