On Tue, Sep 24, 2013 at 2:53 PM, Randy Bush <randy@xxxxxxx> wrote:
hi wes,
are you really saying that i should be comfortable configuring a seattle
> 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.
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