On Thu, Mar 21, 2013 at 5:42 PM, Danny McPherson <da...@tcb.net> wrote: > >> so, to me, this is just 'more objects with a tight(er) timeframe on >> delivery' right? >> >> meaning: today you have (for sake of the conversation) relatively >> static content in the repository, where data changes 1/2/3 >> objects/day, and it's important to get the data distributed, but >> (again, for the conversation) 24hrs is 'fine' as a timeline between: >> "publish object" and "rendered onto the router". >> >> but: tomorrow if you followed (for the sake of the conversation) >> Sriram's model of 'roll router keys hourly to ensure ttls on routes' >> (loosely paraphrased and with times I don't even think he put into his >> slides/discussions), you'd be talking about #-of-routers * 24 objects >> changing every day, and with a timescale for: "publish" to "render" on >> the order of 1hr. (likely less than 1hr, something closer to 5-10 >> minutes has been discussed previously). >> >> right? > > > Yeah, I think so under steady state. > > It gets more interesting when the RIR is attacked and I can't reach them, or > I have a failure of a control card or systems where I cache them locally, or > something to that effect. > > AND I have to know when *everyone* else in the system picks them up and > pushes them out to their routers in preparation for validation so that I > know when it's safe to starting signing with them, etc..
true, but the repository conversation stops at: "all gatherers in the system have the data" inside each ASN it's really up to the ASN operator to get from gatherer -> cache -> router in a 'timely fashion'. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
