Dear Heiner, Thanks for your time, On 19 Aug 2013, at 20:54, [email protected] wrote:
> 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. > depending on the way it is deployed, you might not eat IP addresses as anyway they are already assigned to interfaces today. > 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 ! > could you clarify, I don't understand if it is a question, a remark, or a note. > 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 ? > 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. > 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 ? > The question is not here. This work shows the feasibility of LISP with current setup, 14MB is perfectly affordable with today's equipment. > 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 ? > this is why we added the word "ease" in this revision, as you can see with the diff. > 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 ? > 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. > 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. 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 > 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
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
