Damien, see my responses inline. Heiner
-----Ursprüngliche Mitteilung----- Von: Damien Saucez <[email protected]> An: heinerhummel <[email protected]> Cc: lisp <[email protected]> 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, 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. ==>: 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: 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. ==> You do know that already being another contributer yourself for Med Boucadair's book "Solutions for Sustaining Scalability in Internet Growth" 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. ==>: Thank you for confirming that the dual stack principle is still in place. 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. ==> ... 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 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
