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 <albert.cabel...@gmail.com> 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 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
