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
- Re: Brute force can handle random net assignment Bob Stewart
- re: Brute force can handle random net assignment Tony Hain
- Brute force can handle random net assignment Aaron Leonard
- re: Brute force can handle random net assignment C. Harald Koch
- Re: Brute force can handle random net assignment Karl Denninger