Subject: Re: Why?

From: [email-masked] (Noel Chiappa)
Date: Sun, 13 Mar 2005 07:09:13 -0500 (EST)

> From: Keith Moore <[email-masked]>

    > 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.

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 13 Mar 2005 14:22:10 +0100

>modifications for scalability - if you like NAT.

May I venture a silly question? What is a NAT today?

I prefer speaking of coreboxes with (among others) a NAT service (*) (as 
edge smart boxes opposed to middleboxes) and of telemates or endboxes for a 
non host boxes (sensors, actuators, appliances, etc.).

There are 3 billions telephones,1.3 billions mobiles, 3 billions of TV, 4 
billions of radio listeners. Each of them needs an IPv6 address today with 
10 to 1000 extensions to support their SNHN (small network/home network) 
and their "endboxes". Only IPv6, as an IPv4 with longer address" can 
support them. In that sense I understand IPv6 as the scalability of the 
initial IPv4 deployment (this has actually nothing todo with IPv6, just 
with the availability of the numbers for the necessary scaling and 
directory/routing organization).

Obviously a "user" point of view. Where am I wrong?
jfc

PS (*) as many other services like firewall, application protection, email 
servers, local NIC and nameservers, OPES, webserver, backup manager, CVS, 
creditcard transaction, encryption, etc.

---

From: Keith Moore <[email-masked]>
Date: Sun, 13 Mar 2005 11:58:03 -0500

> 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.