Re: Why?

> > 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf