I'm not sure I am following the rationale here: "As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close to routers that require these data and services. ...
Peering with two or more, at least one local and others remote, is recommended." I agree with the recommendation of using more than one cache for redundancy. Further, I understand the idea of close proximity when we're talking about things like route-reflectors, but the data associated with an origin validation cache is pretty geographically independent, and I wouldn't think that propagation delay would have a material impact on the performance of the system. If there's additional rationale behind recommending the use of a local cache over a remote one, I'm not finding it in the document. I think we maybe could get away with simply noting that operators SHOULD ensure proper geographic redundancy of the caches, perhaps with a comment similar to what I said above regarding the relative insensitivity of distance between the cache and the router, if indeed that is accurate. In other words, if there is a reason why a provider should NOT use simply an east and a west cache (suitably sized, of course), or one per region of the country/world, please explain it in this section. "While a an operator using RPKI data MAY choose any polling frequency they wish for ensuring they have a fresh RPKI cache. However, if they use RPKI data as an input to operational routing decisions, they SHOULD ensure local cache freshness at least every four to six hours." If we're going to make a recommendation (even as a should) of a minimum refresh time, should we also be making a recommendation as to a maximum staleness that is considered acceptable before the router should simply ignore the data from that cache and treat any routes it doesn't have a better set of information about (from another cache) as unknown? I would figure it would be something like a multiple of the refresh time. Note that I am not talking about declaring a cache dead because the router can't talk to it, but the router making a decision as to the validity of the data it is receiving from the cache. For example - cache has lost connectivity to the outside world, but is still reachable from the router, and the appropriate software is running. It continues to respond, but its data is getting more and more stale as time goes on. That may be something better handled within rpki-router (6.4 talks about "cache has no data"), but that section implies that this is primarily b ecause the cache has just reset and hasn't recovered a complete picture yet, not necessarily the case where the cache has what it believes to be a complete picture, but it happens to be 24 hours out of date. If we're going to mention staleness here, it's perhaps worth also saying something within this document. Also, there appears to be an editing error in that first sentence. Other than those two items, I say ship it. Thanks, Wes > -----Original Message----- > From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of > Christopher Morrow > Sent: Friday, October 14, 2011 9:37 AM > To: sidr@ietf.org; sidr-cha...@ietf.org > Subject: [sidr] WGLC: draft-ietf-sidr-origin-ops > > SIDR Folk, > Please see the subject, draft-ietf-sidr-origin-ops is at version 11, > it's gotten some significant feedback over it's lifetime and is now > stabilized. Let's re-read and consider passing this up to the IESG for > their review, eh? > > Tools page for doc: > <http://tools.ietf.org/wg/sidr/draft-ietf-sidr-origin-ops/> > Draft link: <http://tools.ietf.org/html/draft-ietf-sidr-origin-ops- > 11.txt> > > Please consider this draft in WGLC at this time, we'll end that in 2 > weeks time (10/28/2011). > > -Chris > <co-chair> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
