On 30 Mar 2015, at 03:50, Ross Callon <[email protected]> wrote: > I suppose that there are two options: > > 1. Admit that we have no clue what the cache size or control overhead will be. >
See [CCD12], this document provides a generic model that works for any desegregation assumption as long as the map-cache is implemented with LRU. Damien Saucez > 2. Repeat the cited studies, but with a pessimistic (worse case) rather than > optimistic (better than best case) assumption about cache granularity. > > The second option would allow us to actually have some idea what would happen > if LISP were deployed on an Internet-wide scale, but would of course take > more time and more work. > > Ross > > PS: I will be offline at meetings all of this week, so I might be a bit > slower to respond for the next few days. > > -----Original Message----- > From: Joel M. Halpern [mailto:[email protected]] > Sent: Sunday, March 29, 2015 9:36 PM > To: Ross Callon; Luigi Iannone; LISP mailing list list > Cc: [email protected] > Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 > > Putting aside the TBD (which of course needs to be fixed), I have > trouble figuring out what you want us to say about the main issue in > your review. On the one hand, this is the very issue that we have been > asked to comment on, and on the other hand you say that we don't know. > What do you think it is reasoanble to say? > > Yours, > Joel > > On 3/29/15 9:03 PM, Ross Callon wrote: >> Generally I think that this document needs more work before it will be >> ready to submit for publication. Some comments on draft-ietf-lisp-impact-01: >> >> First of all, I assume that the TBD at the end of section 3 will be >> fixed. This reads: >> >> TBD: add a paragraph to explain the operational difference while >> >> dealing with a pull model instead of a push. >> >> Also in section 3, the third paragraph begins: >> >> In addition, Iannone and Bonaventure [IB07] show that the number of >> >> mapping entries that must be handled by an ITR of a campus network >> >> with 10,000 users is limited to few tens of thousands, and does not >> >> represent more than 3 to 4 Megabytes of memory. >> >> Reference [IB07] is of course: >> >> Iannone, L. and O. Bonaventure, "On the cost of caching >> locator/id mappings", In >> >> Proc. ACM CoNEXT 2007, December 2007. >> >> This paper states: >> >> In our analysis, we assume that the granularity of the >> >> EID-to-RLOC mapping is the prefix blocks assigned by >> >> RIRs. We call it /BGP granularity. In particular, we >> >> used the list of prefixes made available by the iPlane >> >> Project [15], containing around 240,000 entries. Using >> >> /BGP granularity means that each EID is first mapped >> >> on a /BGP prefix. The cache will thus contain /BGP >> >> to RLOC mappings.2 This is a natural choice, since >> >> routing locators are supposed to be border routers. >> >> The authors should be aware that there is some aggregation / >> summarization being done in the operation of BGP routing, and that the >> granularity of routes which appear in the default-free BGP routing >> tables is fundamentally different from the granularity of enterprise >> network / ISP boundaries across which traffic is exchanged. >> >> The same paragraph cites Kim et al. [KIF11], which is Kim, J., Iannone, >> L., and A. Feldmann, "Deep dive into the lisp cache and what isps should >> know about it", In Proc. IFIP Networking 2011, May 2011. From this >> document: >> >> In addition, we use a local BGP prefixes >> >> database, fed with the list of BGP prefixes published by the iPlane >> Project [17]. >> >> The database is used to group EID-to-RLOCs mappings with the >> granularity of >> >> existing BGP prefixes, because, as for today, there is no >> sufficient information >> >> to predict what will be the granularity of mappings in a >> LISP-enabled Internet. >> >> I agree that "there is not sufficient information to predict what will >> be the granularity of mappings in a LISP-enabled Internet". However, not >> knowing what the mapping granularity will be does not justify using an >> extremely optimistic guess, and then acting as if the results are >> meaningful. These assumptions are clearly off by some number of orders >> of magnitude, but how many orders of magnitude is unknown. We will note >> that the current internet default-free routing table includes a few >> hundred thousand entries (roughly twice the 240,000 entries that existed >> when this study was done). >> >> For example, we might assume that the intended global deployment model >> involves xTRs at the boundary between enterprise networks and service >> providers, and might note that there are several million companies in >> the USA alone (most of these are relatively small companies, of course). >> Thus there may be very roughly on the order of a hundred million or so >> companies worldwide. If each one had a separate entry in the mapping >> table, then the number of entries will be nearly 1,000 times larger than >> BGP-prefix granularity. >> >> Section 4 mentions as one possible use of LISP: "enable mobility of >> subscriber end points". If individual end points are advertised into >> LISP, then the granularity of the mapping table may be on the order of >> individual systems. In this case the number of mapping table entries >> that could exist globally might be on the same order of magnitude as the >> number of people in the world, or very roughly 7 Billion entries. This >> would suggest that the mapping table might be roughly 30,000 times finer >> grained than was assumed in the referenced studies. >> >> I don't see how we can accurately predict the control plane load of LISP >> without some sense for what the granularity of the mapping table will >> be. It should however be possible to bound the control plane load. The >> referenced studies give a lower bound on possible control plane load (it >> won't be any less), but give neither an accurate measurement nor an >> upper bound on the potential control plane load. I don't think that the >> document can claim to explain the impact of LISP without there being an >> attempt to measure an upper bound on the control plane load. >> >> Finally, perhaps I missed it but I didn't see any discussion of the >> volume of overhead related to OAM traffic used for liveness detection >> (the need for ITR's to determine the reachability of ETR's). >> >> Thanks, Ross >> >> *From:*lisp [mailto:[email protected]] *On Behalf Of *Luigi Iannone >> *Sent:* Monday, March 09, 2015 10:22 AM >> *To:* LISP mailing list list >> *Cc:* [email protected] >> *Subject:* [lisp] WG Last Call draft-ietf-lisp-impact-01 >> >> Hi All, >> >> the authors of the LISP Impact document >> [https://tools.ietf.org/html/draft-ietf-lisp-impact-01] requested the >> Work Group Last Call. >> >> This email starts a WG Last Call, to end March 30th, 2015. >> >> Because usually the pre-meeting period is already overloaded, the LC >> duration is set to three weeks. >> >> Please review this updated WG document and let the WG know if you agree >> that it is ready for handing to the AD. >> >> If you have objections, please state your reasons why, and explain what >> it would take to address your concerns. >> >> Any raised issue will be discussed during the WG meeting in Dallas. >> >> Thanks >> >> >> Luigi & Joel >> >> >> >> _______________________________________________ >> 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
