ietf
[Top] [All Lists]

RE: [sidr] Last Call: <draft-ietf-sidr-origin-ops-21.txt> (RPKI-Based Origin Validation Operation) to Best Current Practice

2013-09-24 11:27:53
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 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.

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.

<Prev in Thread] Current Thread [Next in Thread>