On 12/6/12 5:57 PM, "Eric Osterweil" <[email protected]> wrote:
> >On Dec 6, 2012, at 5:42 PM, Richard Barnes wrote: > >> DNSSEC requires you to have up-to-date information on all the things >>you care about. It's just that in BGPSEC, everyone cares about >>everything :) > >Uh... big difference. DNSSEC doesn't require you to care about anything >before you need it (on demand). RPKI is prefetching... I can't really >outline the architectural difference better than that. So this seems to be about sub-system behavior in various transient states. Cold start of a relying party, when there are no other "hot" instances in contact. While some will argue that one can engineer redundant systems, and smart RPs (e.g., that initialize with last running check-pointed state at boot), still I will admit that one could envisions firing up a new RP, just out of the box, for the first time and it taking time to load its initial state. Won't a demand driven system will experience something very similar when first fired up and and a full table dump comes across the wire in BGP? If a demand driven system wasn't smart enough to use a hot standby with significant cached state, it too will suffer the latency of pulling a significant portion of the data it needs instantly. While I see the architectural differences in those two, it is not clear to me that the end result to a running BGP system that uses them is all that different. Once either approach has achieved steady state, assuming there was some caching done in the demand based system, if the cache holding time of demand queries was the same as the poling interval of the RP, do you think the responsive ness of a change of authoritative info is all that different? Or do you not assume there will be any caching in a demand based system? And if so, would you be concerned about the peers * full_table number of queries that would result from a router reboot? Truly just asking to understand ... Dougm _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
