cool Damien Saucez On 08 Oct 2014, at 01:05, Sharon Barkai <[email protected]> wrote:
> We showed this slide publicly last week in TC3. > The catch is that current deployments are using the pre standards > (Designed 2006) based architecture equivalent almost 1:1 to Lisp. > There's a total of 100M subscribers now footprint for this architecture. > Next major release and current trials are lisp RFC based and interoperable. > > <image1.PNG> > > > --szb > >> On Oct 7, 2014, at 14:44, Damien Saucez <[email protected]> wrote: >> >> 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
