> IMHO they address the architectural issue, by pointing out that while the > there are architecturally different in the abstract, for the purpose they > are being designed/discussed, this architectural difference makes very > little difference in performance.
Seriously Doug, this totally misses the point. If there is a fundamental difference, all the engineering in the world will only be masking the fact that the architecture is different, has different scaling properties, different usage models that it is suited for, etc. Can a model that is inapt for certain requirements be buffed up to service them anyway? Sure. Does that make it ideal? Doubtful, but ymmv... > No you completely missed my point, what I am saying is that when a demand > based system (say DNS) first comes on line with no cached state, and a > router with a full BGP table, it will need to do O(500K) queries > immediately. Lets say DNS is the model for a query based system. O(10s > to 100s msec) per query? Lets look at a range of a reverse DNS query > (with DNSSEC?) taking from 10msec (very optimistic) to 500msec. That > means a cold starting DNS based system would take between 1.4 hours and 69 > hours to gather enough origin mappings to support a running DFZ router. > Note that is dangerous not to have all the state necessary to verify a > full RIB because of "prefer valid" like policies, where the relative > validity state of multiple entries in the RIB matter. I.e., you better > stall the BGP decision process until you have the validation state for all > entries. > > So if the query model takes 69 hours to gain enough state to be useful, > why is it architecturally interesting that it did that through 500K > individual queries instead of batch downloads? I think I see the disconnect here... I don't know why you'd presume that _I_ think loading a router's RIB from DNS queries is a good idea. I certainly don't recall saying that, and I am certainly not advocating that. > Not sure the pithy digs with smilies helps the clarity of these > discussions ... But OK I will give it a shot... Just because the Spruce > Goose's architecture did not sink, it is not clear to me it was any better > suited for the job it was designed for that the Titanic. :^) .... Nah, > I still don't think these help. But the Spruce Goose was killed by yellow journalism, and the Titanic just couldn't manage the open seas with such a tiny rudder (point, iceberg)... ;-} > Seem my comment above. I suspect their behavior relative to the > architectural differences you point out ... Will be of no operational > significance in the application they are designed to support. *sigh* Apparently, this will just be a point where we have to agree to disagree. I feel that (as engineers) we should strive to find the right tool for the right job, but ymmv. > I was talking about when the systems designed to support the distribution > of authorization information (e.g., RP/RPKI or some DNS based system?) > were in steady state ... I.e., they have booted up and done their initial > data loads. Right, and my response was that (even though I have not done any specific analysis on this, in this context), BGP tends to defy the notion of being in steady state, so without a precise comment like the above, it is hard to agree. Also, I'd argue that after a router boots, I've _heard_ they tend to face a lot of churn that isn't steady. I was suggesting a study be done, but that's just my 0.02. > If you don't locally cache the results of querying some system for each > prefix origin pair from a neighbor ... You will have to multiply the time > to query 500K such lookups for each peering session that gives you a full > table. If you do cache them for some amount of time. Set the polling > interval of a batch pull based system to that same time span. Now, how > fast do each react to changes in the authoritative data? Yes, caching is good, but I also think the model that the caching is overlaid on matters. Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
