Hello, Thanks for the input.
I guess you have such deployment, do you have some figure (numbers) that could become public to show the competitive advantage of LISP? Damien Saucez On 07 Oct 2014, at 01:16, Sharon <[email protected]> wrote: > > 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
