if one of your constraints is scalability and the other is deployability, you generally want to optimize for deployability first. ... it's easier to deploy first and make incremental modifications for scalability than it is to do the opposite.
<Image of JNC rolling eyes...>
Keith, that's *exactly* the thinking that got us NAT to begin with!
I mean, we went through a long series of scalability "upgrades"; first to
A/B/C, then subnets, then CIDR, but eventually we just couldn't get any
more s*&^ in the 5-pound sack.
That's when the lack of any *real* scalability (the kind you put in the *architecture* to begin with) brought us your favourite kludge.
So, yeah, it *is* easier to deploy first and then later make incremental
modifications for scalability - if you like NAT.
OTOH, if we had insisted that IPv4 be perfectly scalable before deploying it, IP would now be a historical curiosity, and we'd all be using X.25 over ISDN to access our X.400 email from our telcos.
If routing scalability were the most significant limitation of Internet today, we would find a way to make networks renumber. The huge demand for Internet access would justify the cost of developing tools to do that. Renumbering is actually not that difficult a problem to solve, it's just that we don't have good tools to do it (and support for those tools in routers, hosts, firewalls, proxies, etc.) due to a current lack of demand.
You do have to build upgrade paths into the architecture if you want it to last awhile. But the existence of NATs in IPv4 is due entirely to the decision to use fixed-width 32-bit addresses in IPv4 - not to the lack of an ID/Loc split or any other feature. If IPv4 had an ID/Loc split NATs would still be a problem.
So I remain convinced that I listed the constraints in the correct order - deployability first, scalability second. Both are important, but the order is more important. Making an architecture last is all about understanding where the energy to effect necessary changes will reside, and creating interfaces for the rest of the system that can be stable across drastic changes in technology.
Keith
p.s. Another problem with foresighted solutions is that it's harder to get mindshare for them. Such a small number of people can understand them, that the extra complexity and/or extra discipline required to preserve their future functionality won't seem justified to everyone else. But the market, and deployability of the solution, depend entirely on "everyone else" who aren't in a position to evaluate the foresight of either the design or the designer. The only way you manage to get foresight into a design is to sneak it in and then hope that it's not compromised.
Basically, it sucks to be on the tail end of the foresight distribution curve.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf