Bill, |The history of the computing industry is one of regularly encountered |one-time advances. Moore's Law isn't built on the back of purely |evolutionary improvement.
True, but one time advances from the networking industry catching up to the rest of computing are all expended. It now tracks it quite well, albeit with some lag due to the ASIC houses trailing the process houses. You do NOT want router vendors going down the path of building their own fabs and exploring process technology. That's on the order of a $1B investment every year. ;-( |I'm debating it because I'm tired of watching us bounce off the |pinball bumpers. Resolving this issue impacts our work here in three |very important ways: | |1. It affects whether as a group we reject strategy F, and if we |don't, the language with which we present it. That's easy. <co-chair> As the RRG is chartered to deliver a routing architecture, strategy F (no changes to the routing architecture) is out-of-scope. </co-chair> |2. Engineer's maxim: if it ain't broke, don't fix it. If failure does |not loom on BGP's horizon, there is little justification for moving |any disruptive strategy forward from research to engineering. The |desirable output from our efforts is *very* different depending on |whether or not BGP is failing. Again, it's not BGP, it's the number of prefixes. Any other protocol would have to deal with the implications of a DFZ with a full set of prefixes as well. Thus, it's the architecture that must change. And, once again, if you don't believe that it needs to be fixed, I refer you to the problem statement. |However frightful the monsters under the bed may be, there is |insufficient proof of their existence to justify giving your toddler a |shotgun. Hopefully there are better solutions than that regardless of motivation. My toddler has horrible aim. ;-) Tony _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
