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-25 11:36:20
From: Randy Bush [mailto:randy(_at_)psg(_dot_)com]

are you really saying that i should be comfortable configuring a seattle
router to use a cache in tokyo even though both are in my network and
there is a pretty direct hop?
[WEG] not necessarily. But I'm also not saying that there would *never* be a 
scenario where that makes sense.

i am willing to hack the text.  but i am just not sure that proximity is
not a good attribute.  the longer the wire the greater the likelihood of
it being cut.
[WEG] Proximity is generally a good attribute, but it's not free, so help the 
reader understand the tradeoffs so that they can justify spending money to get 
better proximity. The draft hasn't provided a good explanation of how proximity 
improves RPKI (or what problems a lack of it creates), nor how to determine 
whether the level of proximity in a given design is "good enough" to provide 
the perceived benefit.

Your statement about long wires being cut is an argument for redundancy and 
geographic diversity, not proximity. Of course an operator needs to take into 
account the topology of their network when considering geographic diversity, 
but that's not necessarily going to translate to a need for proximity.

The draft says one should consider latency, but never explains how increased 
latency impacts RPKI, nor gives any guidance on how much might be too much, 
especially when one considers that RPKI is an asymmetric system that changes on 
mostly human time-scales (order of hours or days). Most places where latency 
matters, it's a function of what RTT does to throughput or the perception of 
speed for interaction (how long it takes between when I click and when 
something happens). This isn't an interactive system. What is latency-sensitive 
in this system on the subsecond scale such that it can be affected by moving 
the cache closer? Even on systems configured for very frequent synchronization, 
are we expecting anything to change on that timescale?

See my other response to CMorrow for questions around bootstrapping.

Wes

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>