On Oct 5, 2014, at 5:46 PM, Albert Cabellos <[email protected]> wrote:
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.
On Thu, Oct 2, 2014 at 1:53 AM, Albert Cabellos
<[email protected]> wrote:
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
