Subject: [lisp] Fwd: I-D Action: draft-saucez-lisp-impact-02.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 19 Aug 2013 04:38:11 -0400

This document is one of our blocking charter items.
My thanks to the authors for revising the document.
Have WG members read it?
Have you commented on it?
Do you think it is sufficiently complete and accurate?

Yours,
Joel

-------- Original Message --------
Subject: I-D Action: draft-saucez-lisp-impact-02.txt
Date: Mon, 19 Aug 2013 01:30:44 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : LISP Impact
	Author(s)       : Damien Saucez
                           Luigi Iannone
                           Florin Coras
	Filename        : draft-saucez-lisp-impact-02.txt
	Pages           : 13
	Date            : 2013-08-19

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-saucez-lisp-impact

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-saucez-lisp-impact-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-saucez-lisp-impact-02

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 19 Aug 2013 15:27:12 +0000

Joel,

I did a quick read, and I think its a great start, but I can see that I will have substantial comments.  I'll add this to my work queue this week.

-Darrel
On Aug 19, 2013, at 1:38 AM, Joel M. Halpern <[email-masked]> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : LISP Impact
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: [email-masked]
Date: Mon, 19 Aug 2013 14:54:37 -0400 (EDT)

draft-saucez-lisp-impact-02.txt:
RLOCs are assigned from  the address space of the Internet service providers (PA).
HH:  I.e. it eats up IPv4 addresses rather than generating such ones.   
 
draft:   Quoitin et al. show in [QIdLB07] that the separation between locator and identifier roles at the network level improves the routing scalability by reducing the RIB size (up to one order of magnitude)    and increases the path diversity and thus the traffic engineering  capabilities. 
HH: What is a reduction by one magnitude compared to a reduction down to zero, while providing a path diversity which not even scratches at detour capabilities 
a là Columbus routing ! 
 
draft:
In addition, Iannone and Bonaventure show in [IB07] that the number of mapping entries that must be supported at an ITR    of a campus network is limited and does not represent more that 3 to    4 Megabytes of memory. 
HH: What is this compared to 3000 entries only ? 
 
draft: 
Similarly, Kim et al. show that    the EID-to-RLOC cache size should not exceed 14 MB for an ITR    responsible of more than 20,000 residential ADSL users 
at a large ISP    [KIF11].
HH: What is this compared to cache size zero ?   
 
draft:
   The LISP encapsulation mechanism is designed to support any  combination of locators and identifiers address family.  It is then
   possible to bind IPv6 EIDs with IPv4 RLOCs and vice-versa.  This allows transporting IPv6 packets over an IPv4 network (or IPv4
   packets over an IPv6 network), making LISP a valuable mechanism to  ease the transition to IPv6.
HH: Question: But it does not overcome the dual stack hurdle, right ?
 
draft: 
   Indeed, the transition requires to setup proxy tunnel routers (PxTRs).  PxTRs do not cause particular technical issue.  However, by
   definition proxies cause path stretch and make troubleshooting  harder. 
HH: What will be the path stretch factor ?Why is path stretch accepted although there wouldn’t be any need/reason for doing it ? 
 
draft: 
 Business:  the IETF is not aiming at providing business models.  However, even though [IL10] shown that there is economical incentives to migrate to LISP, 
some questions are on hold.  For example, how will the EIDs be allocated to allow aggregation and hence scalability of the mapping system?  Who will operate
 the mapping system infrastructure and for what benefit?
 
HH: This causes enormous political dependencies, hence enormous political worries. 
Heiner 

-----Ursprüngliche Mitteilung----- 
Von: Darrel Lewis (darlewis) <[email-masked]>
An: Joel M. Halpern <[email-masked]>
Cc: lisp <[email-masked]>
Verschickt: Mo, 19 Aug 2013 5:27 pm
Betreff: Re: [lisp] I-D Action: draft-saucez-lisp-impact-02.txt

Joel,

I did a quick read, and I think its a great start, but I can see that I will 
have substantial comments.  I'll add this to my work queue this week.

-Darrel

directories.

---

From: Damien Saucez <[email-masked]>
Date: Mon, 19 Aug 2013 21:15:48 +0200

Dear Heiner,

Thanks for your time,

> HH:  I.e. it eats up IPv4 addresses rather than generating such ones.   

depending on the way it is deployed, you might not eat IP addresses as
anyway they are already assigned to interfaces today.
> HH: What is a reduction by one magnitude compared to a reduction down to zero, while providing a path diversity which not even scratches at detour capabilities 

could you clarify, I don't understand if it is a question, a remark, or a note. 

> HH: What is this compared to 3000 entries only ? 
I am not sure that this document is the place to make comparisons with other
techniques. However, feel free to propose us references to drafts or peer-reviewed
research papers with such solution and we will be happy to cite them.

> HH: What is this compared to cache size zero ?   
The question is not here. This work shows the feasibility of LISP with current setup, 14MB is perfectly affordable with
today's equipment.
> HH: Question: But it does not overcome the dual stack hurdle, right ?

this is why we added the word "ease" in this revision, as you can see with the diff.

> HH: What will be the path stretch factor ?Why is path stretch accepted although there wouldn’t be any need/reason for doing it ? 
The question is not here. The path stretch will depend the placement of PxTRs, what we
pinpoint here is that this placement must be thought carefully to make transition phase
usable in practice.

> HH: This causes enormous political dependencies, hence enormous political worries. 

So as IP prefix allocation today on the one hand or DNS root on the other hand.

There is solutions such as LISP+ALT or the several chord-based mapping systems
that can avoid this sort of dependency. However, those have shown to have some
performance or manageability issues.

Thank you,

Damien Saucez

---

From: [email-masked]
Date: Tue, 20 Aug 2013 03:16:21 -0400 (EDT)

Damien, see my responses inline.
Heiner

-----Ursprüngliche Mitteilung----- 
Von: Damien Saucez <[email-masked]>
An: heinerhummel <[email-masked]>
Cc: lisp <[email-masked]>
Verschickt: Mo, 19 Aug 2013 9:15 pm
Betreff: Re: [lisp] I-D Action: draft-saucez-lisp-impact-02.txt

Dear Heiner,

Thanks for your time,

==>: Certainly, it is not up to LISP, instead up to Distance-Vector and up to the IETF-state-of-art handling of Dijkstra that disables detour routing to which ever useful degree.
          Once I was told that ECMP provides more than enough alternative paths, as to state that there is no need for being able to handle any further detours. The point however is:    	There are cases where crankback or other forms of detours via more remote nodes are the only possible routes! 
I know, I would repeat myself, but the "LISP's adventages beyond scalability " are repeated too. But on the other side my point might be naive: Current news unveil that routes from Germany place A to Germandy place B few miles away from A are already perfectly detoured via abroad to make spying legal.

draft:

==> You do know that already being another  contributer yourself for Med Boucadair's book "Solutions for Sustaining Scalability in Internet Growth"

draft: 

draft:

==>: Thank you for confirming that the dual stack principle is still in place.

draft: 

draft: 

==> ... which no one wouldn't have either following a system where everyone on earth would understand by {longitude x/ latitude y) the very same without any further discussion.

Thank you,

Damien Saucez

Heiner 

-----Ursprüngliche Mitteilung----- 
Von: Darrel Lewis (darlewis) <[email-masked]>
An: Joel M. Halpern <[email-masked]>
Cc: lisp <[email-masked]>
Verschickt: Mo, 19 Aug 2013 5:27 pm
Betreff: Re: [lisp] I-D Action: draft-saucez-lisp-impact-02.txt

Joel,

-Darrel

directories.