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 protected]> 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 > >> On 10/5/14 3:07 PM, Chad Hintz (chahintz) wrote: >> 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 protected]> wrote: >>> >>> >>> >>> >>>> 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? >>> 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 >>> >>>> 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 >>> _______________________________________________ >>> lisp mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lisp >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
