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..
-danny
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
