At Wed, 4 Aug 2010 15:33:22 +0000, Jeffrey Haas wrote: > > Could the authors comment on the expected behavior of a single router with a > pair of sessions to cache servers operated by the same provider which > implement the same RPKI policy? > > The use-case I have in mind is that a given provider may have a number of > cache servers deployed within their network. A given router may wish to > have a session with two servers for redundancy purposes.
Yes, the protocol is designed to support that. > Given the current protocol, the best a router can do is know that it has all > of the records from a given cache server. There is no way to tell that > the caches are in sync with each other or not. If it really cares whether the caches are exactly in sync, it could compare the results, but I doubt that doing so would be particularly useful. This protocol is presenting a live view of a loosely consistent distributed database, there is no way to force two caches into lock step that does not involve fate sharing, which would defeat the point of using redundant caches. > By somewhat poor analogy, there's no way for me to check for the equivalent > of a DNS SOA record to see which cache may be more up to date and to "do > something" about that. There is no concept equivalent to a DNS zone in the RPKI system. Given that the state of each RPKI cache is a composite of the states of each of the however many objects it might be tracking (best guess for fully deployed system is tens or hundreds of thousands of objects, collected from an arbitrary number of publication points worldwide), the answer to your question is probably "mu", even before factoring in fat fingers problems such as clock or trust anchor skew. About the only useful thing i can see the router doing here is to compare the cache update times (as perceived by the router). If one cache is reporting frequent updates and the other is not, odds are that the first one is healthy and the second one is not, but even that's just guessing, the first might just have horrible intermittent connectivity to the outside or a whacked clock, so you might also want to check size of the respective databases. To a first approximation, a router using this protocol just has to trust the cache. There's nothing (other than CPU and storage hits) to prevent a router that doesn't trust caches from maintaining its own, but the point of this protocol is to get something we can deploy cheaply on current generation hardware. Tracking multiple caches in case one of them dies is probably wise; attempting to get clever about hopping from one to another in an attempt to be smarter than any of your caches is probably beyond the intended scope of this protocol. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
