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 protected]>
An: Joel M. Halpern <[email protected]>
Cc: lisp <[email protected]>
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
On Aug 19, 2013, at 1:38 AM, Joel M. Halpern <[email protected]> wrote:

> 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 protected]
> Reply-To: [email protected]
> To: [email protected]
> 
> 
> 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 protected]
> 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
> 
> 
> 
> _______________________________________________
> 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

Reply via email to