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 protected]> wrote: > 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 >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
