> The issue is less a matter of being in lock-step between a pair of > caches. My concern is that if a cache is out of step with the policy > server that is used to populate that cache.
i have no idea what a policy server is. > 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. there are no redundantly configured caches. there are no database version numbers. read the draft. > I think I see my confusion. I wouldn't have expected a provider to > operate multiple pieces of infrastructure to gather RPKI objects and > generate policy from them. Since consistency of policy is important, > this scenario didn't occur to me. and a globaly consistent view of the dns is important. it just happens not to exist. and global bgp never really converges. from section 5 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. i could add a lot of words, but i don't think it would make things much clearer. i am thinking of including the roll slide from the maastricht preso in the next version. but some folk have pointed out that there are other recipies that are as good. > Given the assumption above of more than one RPKI object collector and > policy generator, I can see how a domain-wide policy serial number > would be problematic. how about the assumption of multiple object collectors and no policy generator(s)? > 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. > 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. randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
