Hi Noel, couple of comments inline.
On 13 Dec. 2012, at 17:09 , Noel Chiappa <[email protected]> wrote: >> From: "Joel M. Halpern" <[email protected]> > >> By assumption, the cache is not big enough to hold the whole mapping >> table (otherwise it would not be subject to overflow). > > I'm not sure this is accurate (but I concede it will depend on the > implementation). > > The chief reason (at least, in my mind) that LISP uses a pull-based control > plane is not the sheer size of the mapping database (memory is, after all, > cheap and plentiful these days), but rather the control traffic overhead > implications - in particular, the issue of the overhead required to maintain > (in particlar, updating, which is not a one-time-only cost) never-used > entries. > > The local copy of mapping information in the ITRs is described as a cache > because it is demand-loaded. Many (most?) caches that people come across are > size-limited, so I think there is an _assumption_ on people's parts that the > LISP cache is also size-limited, but I don't think there is any particular > reason that this must always be so. > I understand your point and I agree with. Yet, no matter how much memory you put in your device there is always a hard limit, hence, the need to discuss it (at least in this document). > If nothing else, size-limiting the cache means one has to code up a discard > algorithm, etc. Now, it may be that the wise programmer will have some > mechanism for running out of memory for the cache (and I wonder what, e.g., > BGP implementations do for this circumstance), and perhaps forcing a box into > that operating regime is an attack vector. > > Can people who maintain existing implementation tell us if they do in fact > have a maximum cache size, and if so, something about what their > retention/discard algorithm is? Also, how do they deal with running out of > memory? In OpenLISP there is no specific mechanism. If memory is not available new mappings cannot be allocated and are dropped (with an error sent to the control plane). There is no specific design rationale behind this choice is just that it comes for free in the BSD kernel. On the other points you raise I think that are covered in the document, but if you manage to read the draft your review is always welcome. Luigi _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
