if you have a hammer, everything looks like a nail :-) (also known as "Maslow's hammer")
Seriously, LISP is about identity/topology separation. This doesn't mean every problem you address with LISP is a topo-id problem nor is topo-id necessarily the fundamental underlying problem - if such exists at all. An example is virtualization/multi tenancy. To address this, one adds the Instance-ID field to the LISP data header. But the fundamental aspect is that you attach an "ID" to the packet, not that you separate EID from RLOC. MPLS labels can do this job (assuming your network know how to handle labels). > IMHO we should make clear for readers that LISP is now beyond its original > scope, I do agree with this statement. Regards, Marc On Mon, 6 Oct 2014 10:18:08 +0200, Alberto Rodriguez-Natal wrote: > 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
