Subject: Re: [lisp] New Version Notification for draft-saucez-lisp-impact-06.txt

From: Damien Saucez <[email-masked]>
Date: Tue, 7 Oct 2014 00:15:21 +0200

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-masked]> 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-masked]> 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-masked]
>>> Subject: New Version Notification for draft-saucez-lisp-impact-06.txt
>>> Date: 29 Sep 2014 13:21:29 GMT+2
>>> To: "Damien Saucez" <[email-masked]>, "Luigi Iannone" <[email-masked]>, Florin Coras <[email-masked]>, Damien Saucez <[email-masked]>, Luigi Iannone <[email-masked]>, "Florin Coras" <[email-masked]>, Albert Cabellos <[email-masked]>
>>> 
>>> 
>>> 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-masked]
>> https://www.ietf.org/mailman/listinfo/lisp

---

From: Sharon <[email-masked]>
Date: Mon, 6 Oct 2014 16:16:53 -0700

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-masked]> wrote:
> 
> Dear all,
>

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 7 Oct 2014 12:17:01 +0000

Hi Damien,

I am on vacation this week, but will take a look at it as soon as I return.

                                                         Ron

> -----Original Message-----
> From: Damien Saucez [mailto:[email-masked]]
> Sent: Monday, October 06, 2014 6:15 PM
> To: LISP mailing list list; Ronald Bonica; [email-masked] Lopez; Sharon
> Barkai
> Cc: [email-masked]
> Subject: Re: [lisp] New Version Notification for draft-saucez-lisp-impact-
> 06.txt
> 
> Dear all,
> 
> As the impact draft aims at documenting operational points, we would be
> happy to have some feedback from people.
> 
> > 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 .
> > 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..
> > 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.
> >
> >> 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.
> >>
> >> 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.
> >>
> >> 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:
> >>
> >>> To: "Damien Saucez" <[email-masked]>, "Luigi Iannone"
> >>> <[email-masked]>, Florin Coras
> >>> <[email-masked]>, Damien Saucez <[email-masked]>, Luigi
> >>> Iannone <[email-masked]>, "Florin Coras"
> >>> <[email-masked]>, Albert Cabellos <[email-masked]>
> >>>
> >>>
> >>> 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.
> >>>
> >>> 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
> >>

---

From: Damien Saucez <[email-masked]>
Date: Tue, 7 Oct 2014 23:44:23 +0200

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

---

From: Damien Saucez <[email-masked]>
Date: Tue, 7 Oct 2014 23:44:47 +0200

Great, Thank you and happy holidays.

Damien Saucez

---

From: Sharon Barkai <[email-masked]>
Date: Tue, 7 Oct 2014 23:05:07 +0000

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.

---

From: Damien Saucez <[email-masked]>
Date: Wed, 8 Oct 2014 13:42:22 +0200

cool

Damien Saucez 
On 08 Oct 2014, at 01:05, Sharon Barkai <[email-masked]> wrote:

>> On Oct 7, 2014, at 14:44, Damien Saucez <[email-masked]> wrote:
>> 
>> Hello,
>> 
>> Thanks for the input. 
>>

---

From: Damien Saucez <[email-masked]>
Date: Fri, 24 Oct 2014 18:41:35 +0200

Thank you, -07 has just be uploaded taking your contribution.

Damien Saucez