On Tue, Sep 24, 2013 at 12:26 PM, George, Wes
<wesley(_dot_)george(_at_)twcable(_dot_)com> wrote:
From: Randy Bush [mailto:randy(_at_)psg(_dot_)com]
i think the two paragraphs you would like to see improved are
[snip]
i am not against further explanation, send text. but short text. :)
[WEG] just the first paragraph really, and as I'll note below - I'd love to
send text, but I don't understand one of the recommendations
experiments have shown that latency between cache and router, and
between caches in a cache dag, is not an appreciable issue.
[WEG] ok, so why is "close" important then?
i thought bootstrap reachability would be fairly obvious to an operator.
but if simple routing and no dns dependency were not obvious to you,
then a few words are indeed needed. or am i missing your point here?
[WEG] yes, completely obvious. Though the last two sentences of your
suggested text in the other email is a useful addition
what is missing from the second paragraph?
[WEG] I'm actually happy with second para
i am not sure it would be useful to go into the general issue of why
caches should be proximal to the consumer as it is a rather well-
explored area, from akamia and limelight to dns. but if you have a
sentence or two that communicates this, send it over.
[WEG] Generally, I understand why closer is better for content caches
(Akamai/llnw) and DNS, but not for RPKI caches. You're making a link between
the two that I'm not following. Both of the
[CLM]
this is about the consumer of the data, right? (and convenience to the
operator that hosts the cache).
In the akamai/cdn example 'consumer' is 'cable/dsl/etc' user. "Close"
is convenient-to-the-operator close to the 'cable/dsl/etc' user.
Perhaps 'metro' is close enough for CDNs, balancing latency and
backhaul requirements.
In the RPKIcache example, 'consumer' is 'routers in your network'.
'Close' is 'close enough that bootstrapping isn't a problem', balanced
with 'gosh, maybe I don't want to put one on top of each router! plus
associated management headaches to deal with these new
systems/appliances'.
former benefit from proximity because it reduces latency and reduces
unnecessary backhaul and potentially allows for a geographically
customized service, resulting in improved user experience. If latency
isn't a factor (at least in the average-sized propagation domain), and
RPKI caches aren't particularly bandwidth intensive, why does
proximity matter? Is this just an extension of the trust domain and
limited dependence on routing protocols? If so, I'd dispense with
recommending "close" because it confuses the issue and just keep the
discussion about secondary dependencies and trust domains.
[CLM]
I guess one way is to say: "People should understand the dependencies
and engineer appropriately" ... which you kind of asked to not say in
the original comment. (or is the issue that the dependencies aren't
clear?)
Thanks
Wes George
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sidr