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
