re: Brute force can handle random net assignment

Tony Hain <ALH@eagle.es.net> Tue, 27 October 1992 17:52 UTC

Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa03999; 27 Oct 92 12:52 EST
Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa11488; 27 Oct 92 12:52 EST
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03991; 27 Oct 92 12:52 EST
Received: from eagle.nersc.gov by IETF.NRI.Reston.VA.US id aa03964; 27 Oct 92 12:50 EST
Date: Tue, 27 Oct 1992 09:50:03 -0800
Sender: ietf-request@IETF.NRI.Reston.VA.US
From: Tony Hain <ALH@eagle.es.net>
Message-Id: <921027095003.636@EAGLE.ES.NET>
Subject: re: Brute force can handle random net assignment
To: ietf@IETF.NRI.Reston.VA.US
X-Vmsmail-To: SMTP%"ietf@IETF.NRI.Reston.VA.US"

Aaron,

I agree with you that a brute force approach could work, but I what I see the
router vendors building has about 1/10 the capacity of your omniscient router.
There is also a lead time to deploy any new routers that puts us in a very bad
place right now. If we continue to assign class B's we run out before the end
of the year, and if we switch to class C's we kill the deployed router base in
about the same amount of time. There is an implicit hope in RFC1366 that a
CIDR based routing protocol can be deployed before the routers die. This does
not imply provider based because just the aggregation of blocks of C's will
put us back to the same order problem as assigning B's. For the cases where it
makes sense (and I can only come up with a few of those) the additional 
aggregation from provider based assignments will only help. 

Basicly I think we can take an approach that ALLOWS but does not require 
provider based addressing and find a big win.

Tony