On 08/11/2011 19:19, Randy Bush wrote:
what comes to my mind is that NotFound is the default and it is recommended to route on it.
I understand what the manual says (actually, i read it). I'm just curious as to how this is going to work in real life. Let's say you have a router cold boot with a bunch of ibgp peers, a transit or two and an rpki cache which is located on a non-connected network - e.g. small transit pop / AS boundary scenario. The cache is not necessarily going to be reachable until it sees an update for its connected network. Until this happens, there will be no connectivity from the router to the cache, and consequently prefixes received in from the transit may be subject to an incorrect and potentially inconsistent routing policy with respect to the rest of the network. Ok, they'll be revalidated once the cache comes on line, but what do you do with them in the interim? Route traffic to them, knowing that they might or might not be correct? Drop until the cache comes online from the point of view of the router? Forward potentially incorrect UPDATEs to your other ibgp peers, and forward validated updates when the cache comes on-line again? If so, then what if your incorrect new policy takes precedence over an existing path in your ibgp mesh? And what if your RP is low on memory from storing an unvalidated adj-rib-in? You could argue to have a local cache in every pop but may not be feasible either - a cache will require storage with a high write life-cycle (i.e. forget about using lots of types of flash), and you cannot be guaranteed that this is going to be available on a router. Look, i understand that you're designing rpki <-> interactivity such that things will at least work in some fashion when your routers lose sight of their rpki caches. The problem is that this approach weakens rpki's strengths - e.g. the ability to help stop youtube-like incidents from recurring by ignoring invalid prefix injection. Nick