>> [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