Damian, sorry for the delay, meant to get to this today. - Lisp architecture facilitates routing in environments where there is little to no correlation between network endpoints and topological location. In service provider environment this use is evident in a range of consumer use cases which require an inline anchor in-order to deliver a service to a subscribers. Inline anchors provide one of three types of capabilities:
(1) enable mobility of subscriber end points (2) enable chaining of middle-box functions (3) enable seamless scale-out of functions - Without using the Lisp architecture operators are forced to centralize service anchors in custom built special boxes. This means that end-points can move as long as their traffic ends up on the same mobile gateway, functions can be chained as long as all traffic traverses the same wire or the same dpi box, and capacity can scale out as long as traffic fans out to and form a specific load balancer. - By using the Lisp architecture service providers are able to distribute, virtualize, and insatiate subscriber-service anchors anywhere in the network. In addition to the efficiency and flexibility of elastic allocation there is also great deal of additional efficiency in combining these anchors and applying multiple considerations; ID-Location, Subscriber-Service, Service-Instance, in one "Map&Encap" shot, or Lisp point of indirection. - Typical use cases that Virtualize inline anchors and network functions include: Distributed Mobility and Virtualized Evolved Packet Core (vEPC), where centralization makes way to distributed and virtualized inline anchoring of mobility, Virtualized Customer Premise Equipment or vCPE, where functionality previously anchored at customer prem is now dynamically allocated in-network, Virtualized SGi LAN, where value added mobile services previously anchored inside full-stack boxes or anchored to physical wires with permutation setups aka "Rails", Virtual IMS and Virtual SBC, etc. --szb > On Oct 6, 2014, at 15:15, Damien Saucez <[email protected]> wrote: > > Dear all, > > As the impact draft aims at documenting operational points, we would be happy > to > have some feedback from people. > > From the discussions and mails, we identified that some of you could directly > help in the document, more precisely, in addition to Sharon: > > - Ron on the change w.r.t. BGP > - Ed on the problem of middle boxes and NATs > > Would you both be ready to provide a little paragraph on this? > > Any other volunteer? > > Thank you, > > > Damien Saucez > > > > >> On 29 Sep 2014, at 19:01, Sharon <[email protected]> wrote: >> >> Hi Damian, our experience applying the lisp architecture is focused on >> service providers network under the umbrella of what we call Lisp Flow >> Mapping - Subscriber to Services . >> Is this domain of interest to your impact document? >> If so will be happy to help. >> >> >> The Lisp Flow Mapping use cases fall into two main blocks: >> (1) Consumer Services and (2) Managed Network Services >> >> In the Consumer use cases the Lisp architecture addresses the need to >> distribute the "anchors" used by carriers to pin subscriber inline services >> - mobility services, value add services, media services.. >> Context is pervasive using mapping, flows are mapped to wherever anchors & >> states are. >> >> In Managed network services the Lisp architecture is used to augment >> deficiencies in VPNs for supporting virtualization, hosting, and broadband >> access. CEs are freed from enterprise prefixes and WAN functions, PEs are >> freed from running per enterprise routing, and Ps are freed from per >> location LSPs. >> >> Please let know if the above is of interest and in charter so we can >> perhaps incorporate. >> >> >> --szb >> >>> On Sep 29, 2014, at 04:28, Damien Saucez <[email protected]> wrote: >>> >>> Dear All, >>> >>> The charter makes a clear distinction between the LISP architecture and its >>> impact (see charter excerpt below) so we would greatly appreciate to have >>> feedback on draft-saucez-lisp-impact-06 that aims at summarising what are >>> the potential implications of a LISP deployment in today’s Internet. This >>> draft >>> can be seen somehow as a companion of the -intro- document that focuses >>> on the architecture and mechanisms. >>> >>> Thank you for you collaboration, >>> >>> Damien Saucez >>> >>> >>> - Architecture description: This document will describe the >>> architecture of the entire LISP system, making it easier to read the >>> rest of the LISP specifications and providing a basis for discussion >>> about the details of the LISP protocols. The document will include >>> a description of the cache management and ETR synchronization >>> essential characteristics needed to ensure the correct operation >>> of the protocol. >>> >>> - A description of the impacts of LISP: This document will describe >>> the problems that LISP is intended to address and the impacts that >>> employing LISP has. While the work on LISP was initiated by Internet >>> routing scaling concerns, there has also been an interest on >>> improved solutions to a number of different problems, such as >>> traffic engineering. This document should describe problem areas >>> (such as scaling or traffic engineer) where LISP is expected to have >>> a positive effect, as well as any tradeoffs that are caused by >>> LISP's design. >>> >>> Begin forwarded message: >>> >>>> From: [email protected] >>>> Subject: New Version Notification for draft-saucez-lisp-impact-06.txt >>>> Date: 29 Sep 2014 13:21:29 GMT+2 >>>> To: "Damien Saucez" <[email protected]>, "Luigi Iannone" >>>> <[email protected]>, Florin Coras <[email protected]>, >>>> Damien Saucez <[email protected]>, Luigi Iannone >>>> <[email protected]>, "Florin Coras" <[email protected]>, >>>> Albert Cabellos <[email protected]> >>>> >>>> >>>> A new version of I-D, draft-saucez-lisp-impact-06.txt >>>> has been successfully submitted by Damien Saucez and posted to the >>>> IETF repository. >>>> >>>> Name: draft-saucez-lisp-impact >>>> Revision: 06 >>>> Title: LISP Impact >>>> Document date: 2014-09-29 >>>> Group: Individual Submission >>>> Pages: 15 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-saucez-lisp-impact-06.txt >>>> Status: https://datatracker.ietf.org/doc/draft-saucez-lisp-impact/ >>>> Htmlized: http://tools.ietf.org/html/draft-saucez-lisp-impact-06 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-saucez-lisp-impact-06 >>>> >>>> Abstract: >>>> The Locator/Identifier Separation Protocol (LISP) aims at improving >>>> the Internet scalability properties leveraging on three simple >>>> principles: address role separation, encapsulation, and mapping. In >>>> this document, based on implementation, deployment, and theoretical >>>> studies, we discuss the impact that deployment of LISP can have on >>>> both the Internet in general and for the end-users in particular. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>> >>> _______________________________________________ >>> 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
