Re: [sidr] WGLC: draft-ietf-sidr-origin-ops-

I think we're ready to move this on, and I commend Randy for his work on it.

The only substantive comment I have is something that I believe Shane and I raised in previous versions' review and is not addressed yet. In section 3, where it discusses location of cache relative to routers "...'close' is of course complex..." - the current text still does not adequately explain why 'close' is a recommendation, or how latency might affect performance of the chosen deployment. This is a system that is by nature a loosely synchronized system, asymmetric in distribution of information, where elsewhere in this doc we say that the clock has to be accurate to the hour, which isn't exactly a high bar. If latency is a consideration, we need a bound on that - how much is too much latency such that the cache should be closer to the consuming router(s)? If there isn't a definite recommendation, what is the consideration that operators should be using to determine latency's impact? Is this just about latency's impact on TCP throughput, or is there something more complex to be considered?
I'd suggest text, but I still don't understand why geographic proximity matters. Reachability, sure, but not proximity.

Similarly with "consider trust boundaries..." - what should one be considering here? How are trust boundaries related to a cache's proximity to a given router?

I understand why bootstrap reachability between router and cache is important, but a few additional words about the reason might be helpful for the intended audience (that is, operators implementing RPKI for the first time)
Suggested text: "If the cache is not reachable via IGP or even locally, this will delay initial synchronization with the RPKI cache on boot, and may cause multiple BGP convergence events, first without RPKI data, and then again once RPKI data is synchronized."

Generally, if we are recommending that there should be some sort of proximity, we need to provide some rationale or a view into the considerations that went into that recommendation so that operators can make their own informed decision about placement, justify standalone equipment instead of VMs, etc. Otherwise, I can see having the following discussion with our systems folks internally:
"This RPKI cache thingy is just a server with an app running on it, right?"
"yeah"
"ok, we're going to stick it in a VM on our two national data center compute infrastructures like the rest of our servers, we can spin up more instances if you need to scale it"
"but RFC mumble mumble says that we shouldn't do that..."
"ok, why? And where do you want to put it?"
"ummm... 'close' to the routers? Because...reasons"

Thanks,

Wes George

> -----Original Message-----
> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of
> Christopher Morrow
> Sent: Friday, August 17, 2012 11:03 AM
> To: sidr@ietf.org; sidr-chairs@ietf.org; sidr-ads@tools.ietf.org
> Subject: [sidr] WGLC: draft-ietf-sidr-origin-ops-
>
> Hello WG folk,
> This draft has undergone 9 revisions since the last WGLC, which seemed
> to end with requests for changes by the authors.
> Can we now have a final-final-please-let's-progress WGLC for this draft
> now? Let's end the call: 08/31/2012 (Aug 31 2012).
>
> Htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19
>
> Abstract:
> "Deployment of RPKI-based BGP origin validation has many operational
>    considerations.  This document attempts to collect and present the
>    most critical.  It is expected to evolve as RPKI-based origin
>    validation is deployed and the dynamics are better understood."
>
> Thanks!
> -Chris
> <co-chair-2-of-3>
> _______________________________________________
> 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.