On Wed, Aug 04, 2010 at 08:37:07PM +0200, Randy Bush wrote: > there are no redundantly configured caches.
: 7. Router-Cache Set-Up : [...] : A router may be configured to peer with a selection of caches > there are no database version numbers. That was my proposal and not my assertion that your protocol included this. > read the draft. Aside from my sloppy verbiage, you're mistaken if you think I haven't. It's why I'm asking questions. > As caches can not be rigorously synchronous, a client which changes > servers can not combine data from different parent caches. > Therefore, when a lower preference cache becomes available, if > resources allow, it would be prudent for the client to start a new > buffer for that cache's data, and only switch to those data when that > buffer is fully up to date. And the crux of my question is, why can't they be synchronous at least within a given provider domain? Or at least synchronous enough? > how about the assumption of multiple object collectors and no policy > generator(s)? The default policy is your choice of trust anchors. > > I'd say I'm still concerned about redudannt cache integrity and that > > the WG should spend a few cycles considering reasonable and > > inexpensive to implement solutions. > > when you actually have a proposal, do make it. What I had said in a prior e-mail was: > What I had in mind was a simple message from the cache server noting what > its database version number was from the policy server and the last update > time. This would permit a router to note when a cache has become radically > desynchronized from its redundantly configured cache. At this point, the deployment model that appears to be documented (Section 8) seems to presume that it's okay to have inconsistent RPKI policy within a provider. If everyone is cool with that, we're done. If not, then we have more work to do, even if it's not a simple database version number. > > As I pointed out to Randy, a single point of failure for such a > > stateful mechanism is problematic. > > what single point of failure? and please refer to the draft and do not > invent components which are not there. This was in response to your original comment: On Wed, Aug 04, 2010 at 06:49:16PM +0200, Randy Bush wrote: > > 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. > > do not do it If you can't have a session with more than one server, you have a single point of failure. > randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
