On Mar 11, 2010, at 9:06 AM, Scott Brim wrote: > Pekka Savola allegedly wrote on 03/11/2010 08:52 EST: >> FWIW, yes, it certainly was ambiguous, but it was apparent that lots of >> folks interpreted it their own way. > > I never got around to responding because of the ambiguities. Also I > don't see how it really matters. If it means what I think it means, > it's a truism.
I'm not sure how to respond because the "current path" antecedent in both questions is a non-possibility. More important still, I suspect that the scalability of any/every conceivable site multihoming mechanism will ultimately be contingent on the bounding conditions that dictate what a "site" is, and what features/advantages "sites" enjoy that distinguish them from "non-sites." To put this in more generalizable terms, I think of the "current path" as combining: 1. A protocol-level architecture that links some (potentially) universally advantageous capabilities -- "multihoming" being just one of many possible examples -- to particular non-universal properties, e.g., "site" status, 2. Hardware technology-imposed limits on collective DFZ RIB/FIB carrying capacity, which is incrementally encumbered by each additional "site" and each instance of multihoming, 3. Formal, collectively imposed (institutionalized) limits on "site" definition, implemented through consistent but contingent (i.e., not unique but not arbitrary) policies and administrative practices, 4. Informal, individually and collectively imposed back-pressure on per-"site" multihoming (ala the CIDR report, bilateral inter-provider bargaining, etc.), and 5. Enough protocol resources (IPv4) to sustain all of the above, at least for "a few more years." If (5) continued to be true, I suspect that the overall "current architectural path" (1-5) would in fact continue to be scalable and viable, perhaps indefinitely. But given that (5) is no longer true, and one response to that development has been the weakening/abandonment of (3), reference to the "current architectural path" in Question A doesn't seem to me to be coherent. Granted, some may not feel that (3) should be considered an "architectural" element -- but then that would imply the equally incoherent position that the now very large and still-expanding Internet has been equally nonviable and non-scalable for the last twenty years ago, if not from day one. That view would also seem to invalidate Question B as leading. But setting that point aside for the moment, I think that the real challenge for the foreseeable future -- including all of the candidate solutions under discussion -- is reconciling (1), and the possibility of unbounded demand for whatever advantageous features distinguish certain participants, sites, or whatever from others, with the existence of whatever hard limits the future system imposes, i.e., that the future architecture cannot eliminate. My own view, biased, impressionistic, and under-informed though it may be, is that much time and effort has been spent on rationalizing (or alternately avoiding) the question of whether, how, and why demand for certain potentially advantageous roles/capabilities in the future arch will be (and will remain, indefinitely) low and bounded by exogenous factors, so that scalability problems at that particular level could never arise. I would personally feel much more confident (or at least much less skeptical) about candidate solutions if they gave equal time, space, and consideration to fallback mechanisms that might preserve scalability *even if such assumptions about externally imposed constraints turn out to be wrong.* One lesson that we've learned -- or should have learned -- from the last decade-plus of experience is that so long as the Internet continues to be supported and maintained primarily by competing commercial entities, *no* role, feature, or capability that might provide one network operator with a competitive advantage over another will remain immune to endogenously-generated scalability pressures for very long. TV _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
