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

["George, Wes" <[e-mail]>]

Randy, I think I know why you keep calling me Shane - we tend to raise similar concerns on your drafts ;-)

See also http://www.ietf.org/mail-archive/web/sidr/current/msg03408.html
Shane articulates it better, but consider this a +1 on his comments regarding the -12 proposed text. The only other place I could see this background info being is in the design rationale draft, which could then be referenced from this document. Otherwise, this is critical guidance for operators trying to determine the best way to implement this in their networks.

Ditto for the 4-6 hour recommendation and Danny's comments. Rationale, please.

Wes

> >> 3)  Granted, the following text is only a "SHOULD", but the text
> offers no reasoning as to why caches should be placed close to routers,
> i.e.: are there latency concerns (for the RPKI <-> cache protocol), or
> is it that a geographically distributed system is one way to avoid a
> single-point-of-failure, or something else entirely?  As a start, just
> defining "close" would help, e.g.: same POP, same (U.S.) state, same
> country, same timezone ... but, then a statement as to any latency or
> resiliency requirement for geographic deployment of RPKI caches wold be
> useful.
> >
> > we tried to go down this path and found it just got more and more
> > complex with no real improvement.  you probably want them in some
> > diameter of transport trust.  you probably want them in some diameter
> > of routing bootstrap reach.  you probably want them with reasonable
> > latency characteristics.  and there are probably more concerns.
> > that's why you get the big bucks. :)
>
> I'm more concerned for the 100's or 1000's of engineers that were not
> participating in this initial development effort and will be left
> wondering what, at a high-level, the thinking/background/concerns were
> that went into these guidelines.  With that information, future
> engineers can then weigh those criteria for themselves to decide if
> they are applicable to their environment, how they are applicable to
> their environment, etc.
>
> Remember, ultimately what you're laying out here is going to be read by
> engineers who are going to look at buying actual server HW, and network
> ports to attach them to, to set-up an RPKI in their network.  The more
> background material you give them the more confident they will be on
> putting together a budget estimate to start such a project ...
>
> >    <t>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.  'Close' is, of course,
> complex.
> >      One should consider trust boundaries, routing bootstrap
> >      reachability, latency, etc.</t>
>
> While I appreciate the attempt, I don't think the above satisfies my
> concern.  What 'trust boundaries' are you referring to, e.g.: within
> your ASN, not within your ASN but within your organization or
> neither/other?  With respect to latency, is what you're attempting to
> say that it's recommended to engineer for a high BW x low delay
> product, in order to achieve fast xfers of data between RPKI caches and
> also data between the RPKI cache to the routers?  If so, then aren't
> you conceding that low latency is necessary in order to _strive_ to
> attain "good [enough]" synchronization between all RPKI caches in the
> network so that 'new' RPKI data that affects BGP policy gets uniformly
> applied across all routers in the network at roughly the same time?
>


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.