[WEG] that's part of my issue - the only way that you get "close
enough that bootstrapping isn't a problem" is when the cache and
router are directly
there's some baseline that's acceptable, you intimate that IGP comes
up before EGP below. that makes some sense, and thus maybe the target
is 'in your igp, close enough that fiber failures won't be a problem'
then?
but do we want to go to that level of detail? it's just nit-pick fodder
connected. Otherwise there *is* going to be some amount of time while
the router is coming up that it can't talk to its configured caches
e.g. while
but the data in the cache only REALLY matters for bgp validation... so
your IGP clue below isn't unreasonable.
and the folk who smoked the "use ibgp for your igp" dope at&t handed out
to customers?
i really don't think we want to get into the nitty gritty of how folk
should configure their networks. way to many styles, variables, corner
cases, ...
explain the underlying physics and what's prudent and let the network's
engineers design their network.
but yes, 'close' may be a bit so loose, and seems to be major
nit-picking fodder.
it learns the route(s) to the cache(s). I think that supports a
recommendation to put the caches in your IGP instead of BGP, so that
you get faster
I actually didn't note a [ie]GP recommendation in the doc.
not because i ran out of ink (credit to nw)
convergence of those routes and therefore have access to the cache
when BGP comes up and starts converging, rather than once BGP is
partially converged. But the draft doesn't say that.
ok
"but i only have that one router. and if bgp does not come up, then the
cache can not load up."
do you *really* want to go down these myriad twisty passages?
i think a bunch of this really also depends on the operator deploying
though... 'its hard to get server people to do X for me' or 'gosh,
these appliances can be managed by network-operations! and they are
cheap-ish' or 'gosh, we don't have 1gbps ports anymore in general,
crap...'
yes, makes one want to go back to running a small network.
I do think the original intent was to not dictate: "Must be 5ms from
the router, or else!!" and rely upon the operator to do the tradeoff
you just made above. Each network is different in it's expectations
from the infra, and each has different igp/egp designs as well as
fiber plant restrictions. I think it's going to be rough going making
a recommendation much more than:
i agree up to here
1) make sure the cache is available before BGP starts to converge
for a device
you can't. cache may need routing to fill its little tummy.
and I actually can't come up with something else that's super helpful
which is why i stopped where i did. though i think one could amplify a
bit on 'close'. your paragraph is not bad
"As RPKI-based origin validation relies on the availability of RPKI
data, operators SHOULD locate caches close enough to routers that
require these data and services such that failures in local device
routing domain do not impact cache availability. One should consider
trust boundaries, routing bootstrap reachability, latency, etc"
i would modify slightly (e.g. s/do not impact/are unlikely to impact/)
but can stitch it in. and latency may be a red herring. but i eat
herring, so wth.
randy