On Mar 22, 2013, at 9:08 AM, "Osterweil, Eric" <[email protected]> wrote: > On Mar 22, 2013, at 9:57 AM, Randy Bush <[email protected]> wrote: > >>> past experience points to the hosted model eventually looking like >>> distinct repositories per customer, which looks like 'number of >>> repositories == number of ASN allocated'. >> >> actual experience is five large hosted repositories. > > Randy, sound _engineering_ is predicated (in large part) on evaluation and > reducing risks. Using predictive models (especially those based on sound > reasonable or observable assumptions) to estimate unknowns is pretty common, > among conscientious engineers (and scientists, fwiw). This is particularly > true during the early phases of design work and requirements analysis (the > latter of which, I think we are still missing?). It seems to me that Chris > is practicing very advisable prudence. Conversely, the ready-fire-aim > approach is… well, an odd position to be advocating here… > > I'd suggest that if you don't like Chris' model, you propose one that you > have more faith in. I (for one) would greatly appreciate seeing your > insights in that regard.
To add to Eric's excellent points above. _Capacity_Planning_ of networks, (which we've done since the dawn of time), depends on observations of historical utilization of physical/logical paths across the network. However, historical utilization does not tell you the whole story, due to (as just one example) [very] large, but *pending* (i.e.: not turned up) customer wins. In that case, we apply sound engineering to /forecast/ and then input that forecast into __models__ to determine what will be the growth of the network and then plan/execute augments appropriately. In some circumstances, these exercises are performed over much longer time-scales, particularly when the operator is facing the need to actually build and/or move physical infrastructure to accommodate for the predicted growth, (i.e.: build new facilities, move from old to new facilities, lay new conduit/cable, etc.). In any of these exercises, sometimes you are "surprised" by the results, (typically costs), and need to explore alternatives ... exploration of those alternatives is part of trying to 'reduce risks', as Eric points out. So, +1 to "sound engineering" comment, above. -shane _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
