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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Randy Bush [mailto:randy@xxxxxxx]
>
> 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.





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]