On Tue, Sep 24, 2013 at 2:53 PM, Randy Bush <ra...@psg.com> wrote: > hi wes, > > > 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. > > 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? >
Why shouldn't it just be "in the cloud" and you not care about where? Oh, because RPKI-RTR isn't an application, it's infrastructure! > 1 r0.sea.rg.net (147.28.0.4) 0.189 ms 0.306 ms 0.230 ms > 2 r1.sea.rg.net (147.28.0.5) 0.307 ms 0.259 ms 0.221 ms > 3 sea001bf00.iij.net (206.81.80.237) 0.336 ms 0.383 ms 0.348 ms > 4 tky008bf00.IIJ.net (206.132.169.110) 88.723 ms 94.377 ms 124.044 ms > 5 tky001bb10.IIJ.Net (58.138.80.18) 83.639 ms 83.701 ms 89.133 ms > > 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. > Following this line of reasoning (which is not unreasonable); if the router requires the cache to arrive at correctness, maybe the cache should be _inside_ the router. I'm not trying to be snarky, I know all the bootstrapping concerns have been hashed and re-hashed. To me, this funkiness seems like a holdover from that. Tony
