On Sun, Dec 21, 2008 at 3:38 PM, PAPADIMITRIOU Dimitri <[email protected]> wrote: >> On Sun, Dec 21, 2008 at 10:55 AM, PAPADIMITRIOU Dimitri >> <[email protected]> wrote: >> >> Are you aware of any examples of a cache coupled with a BGP RIB? >> > Cisco Express Forwarding (CEF) to give one of the best >> known example. >> >> No, CEF is an example of a full FIB database. Don't expand the >> definition of a cache to the point where it is indistinguishable from >> the database to which it is subservient. You would render any >> conclusions you reach into gibberish and we'd be right back where we >> started with no way to evaluate the efficacy of LISP's route caching >> proposal. > > I do not understand anymore where the objection is in your arguments: > > - is it the issue of whether CEF or alike itself is not associated to a > caching system ? in my view a system that "routes the first packet and > switches the next packet of a given data flow" relies on a mechanism > where there is an intermediate entity storing a subset of the > information and that can be accessed faster than from its initial > location. As a matter of comparison in LISP: if the first packet arrives > at the ITR but no local mapping entry in the mapping cache, lookup is > performed to populate the mapping cache.
Hi Dimitri, My objection is that you've expressed a misunderstanding of the difference between a cache and a database. CEF creates an authoritative database. When a packet is routed, the lookup occurs directly on that database; no cache is involved. By comparison, LISP and several of the other map-encap proposals have a small cache which contains a working set of destinations presently in use. When no cached entry matches a packet's destination, lisp queries the database to find the destination and then adds the result to its cache. One is caching. One is not. You described both as caching, hence my objection. Here's the problem: you've described a cache in a way that is identical to the database on which the cache operates. You're conclusions will be constrained by that definition. Because you've made the terms equivalent, you won't be able to draw meaningful distinctions between them. >> Elements of some of the proposed solutions on RRG place a supposed >> cache at the top level of the database distribution hierarchy. In >> reality, the top of the hierarchy ends up functioning as a remote >> central database of routes from which each encoder caches a working >> set. >> >> When evaluating those proposals, you will want to understand the >> implications of a central versus distributed database. You'll also >> want to be able to recognize when part of what the author has proposed >> is not functionally a cache at all, even though he describes it that >> way. > > I view this as a particular structure of a distributed set of remote > databases (in the form of distributed hierarchy). By central database > one usually refer to a single repository. This is a subtle but very important point. If the top of the hierarchy has a full database then it isn't a cache. And if the top of the hierarchy is the only set of nodes with a full database then it isn't a distributed database, it's a central database and the other levels of the hierarchy are caches. >> I propose that this associativity issue is unique to the PC memory >> management domain. Issues which appear in only one caching problem are >> a property of that problem domain, not a general property of caching >> systems. Because we don't want to confuse the issue with irrelevant >> information, we should not consider associativity as part of the >> report on caching systems. >> >> I ask you to falsify this proposal by offering a concrete example of >> one associativity issue in a well known caching problem domain other >> than PC memory management. > > Associative caches for IP routing is one example here among others. Concrete example please. Is there an XYZ cache in IOS 12.9? Does JunOS have a competing cache that works differently? >> Accordingly, Dimitri's section 3.4 push acquisition of cache data from >> the BGP RIB is invalid. No such system ever existed, so any >> description of it's operational properties would be false. > > This is not what I suggest (referring to my previous post): > > "...the working set is extracted/derived from the BGP routing > database. > > To remove the confusion, I suggest to consider i) pull from > local database (e.g. BGP RIB) - one could refer to local pull," > > Reason: the RIB is the source of information for where cache entries are > derived whereas the pull operations are traffic driven from these > "derived" entries. If you replace 3.4 push/pull/hybrid with 3.4 pull local-central, pull local-distributed, pull remote-central and pull remote-distributed, you'll be closer. However, the BGP RIB still isn't an example of a database supplying a local-central pull cache. In Cisco fast switching, the cache is pulled from the router FIB, *not* the BGP RIB. Nor is the FIB a direct derivative of the BGP RIB. The router FIB is constructed from *multiple* protocol RIBs including the connected RIB, the static RIB, the OSPF RIB, etc. I am aware of no caching mechanisms which refer directly to the BGP RIB. If you cite one that doesn't confuse the difference between a cache and a database, I'll withdraw my objection. Incidently, it's possible to build a small FIB cache instead of a complete FIB. On a cache miss, you'd consult each of the RIBs including the BGP RIB in order to compute a next hop to insert into the cache. That would be an example of local-distributed-pull. The problem is, no such system exists so we can't very well offer observations about our operational experience with it. If BGP is not a red herring here, I want you to demonstrate that with the data. Regards, Bill Herrin -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
