> From: christopher.morrow@xxxxxxxxx [mailto:christopher.morrow@xxxxxxxxx] > > [CLM] > In the RPKIcache example, 'consumer' is 'routers in your network'. > 'Close' is 'close enough that bootstrapping isn't a problem', balanced > with 'gosh, maybe I don't want to put one on top of each router! plus > associated management headaches to deal with these new > systems/appliances'. [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 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 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 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. The question is, does the propagation/convergence delay for an IGP in an average network (let's call it somewhere between subsecond and 5 seconds) make a non-trival difference in RPKI's bootstrap behavior, especially since BGP convergence is also dependent on IGP convergence? Can we make a clearer recommendation of the performance envelope we're shooting for so that people can design accordingly? I'm not sure I buy a general "faster(or closer) is always better" recommendation - at some point, we hit diminishing returns, given that this is mostly a human time-scale system. The document doesn't provide clear guidance on how to balance that tradeoff. > > > [CLM] > I guess one way is to say: "People should understand the dependencies > and engineer appropriately" ... which you kind of asked to not say in > the original comment. (or is the issue that the dependencies aren't > clear?) [WEG] The issue is that the dependencies aren't clear. I'm not expecting the text to be too prescriptive here, because all networks are different, but I need enough technical discussion to properly "understand the dependencies and engineer accordingly". This is an operational considerations document, so it needs to tell operators what breaks if they don't do it as recommended. If this is about bootstrapping, then we need to be clearer about the relationship between bootstrapping and network convergence (since recommending that the cache is directly connected to the router is impractical) and how it impacts RPKI cache-router communication and performance. If it's about reducing latency via proximity, then we need to explain how much latency is too much latency and why. If it's about proper geographic diversity within a network's topology, then we need to say that. If we don't actually know if it makes a difference, and so are defaulting to recommendations that most folks agree are generally a good idea, we should say that. But right now we're assuming too much, IMO. Wes This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.