On 12/7/12 10:28 AM, "Eric Osterweil" <[email protected]> wrote:
> >> 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. The rest we have beaten to death so I won't try again. I was not suggesting/discussing loading a RIB from DNS queries. I was thought we were discussing information systems that might allow me to validate the origin of an router's RIB. That problem is O(500K) at time zero. > >> 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)... ;-} Actually the Spruce Goose floated fine, but was completely ill designed / engineered to fly. The Titanic sank because of the poor, under spec metal quality used in its rivets. A NIST metallurgist proved this some number of years back and got a lot of press for it. > >> 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
