On Tue, Sep 24, 2013 at 2:53 PM, Randy Bush <randy(_at_)psg(_dot_)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