Tony, > Hi Ross, > > |> We already know that we're growing the table faster than technology > |> can keep up. That much is clear. (Tony Li) > | > |First the question: What do you mean by "we're growing the table faster > |than technology can keep up". Are you referring to Forwarding Table > |size, BGP processing and traffic loads, or something else? > > > I'm referring to the growth rate of the full set of prefixes and the > capabilities of the control plane to support it. > > Note that I've been saying this pretty consistently for two full years now. > > |Do you mean > |"with a table of 100,000,000 entries, there will need to be at > |a minimum > |some incremental update to existing deployed implementations" (to which > |my teenage daughter might say "duh!"), or do you mean "it won't be > |economically reasonable to build products unless we make some localized > |internal (within a router) change to a few algorithms?", or do you mean > |"it will be financially too expensive to build products that can handle > |some future table size", or do you mean "it will not be technically > |possible to build the routers", or do you mean something else? > > > Once again, with feeling: > > The growth rate of prefixes that are circulating within the DFZ exceeds the > rate of speed improvement in the underlying DRAM that we use to implement > the control plane. This will undoubtedly result in architectural changes > and cost increases. The concern then becomes that over the long term, as > this continues, the cost increases must be absorbed somewhere in the system, > and it is most likely to propagate to the end users, with a net detriment to > the growth of the network.
Few points: - The above assumes that DRAM will continue to be used to implement control plane memory. As had been discussed before on this list, DRAM is not the only option - another alternative is RLDRAM. - Even if one assumes that the growth rate of prefixes exceeds the rate of speed improvements in the underlying DRAM that is used to implement control plane, and that, in turn, would result in cost increases, let's not forget that deploying new routing architecture may have its own cost, thus resulting in cost increases. Moreover, these increases may be higher relative to what would result from the growth rate of prefixes exceeding the rate of speed improvements in the underlying DRAM. These increases, just like the increases you mentioned above, would need to be absorbed by the system, and "most likely to propagate to the end users, with a net detriment to the growth of the network". Moreover, these increases would need to be absorbed by the system in the short/medium term, well before we will reach "the promise" of the cost reduction in the *long term*. Would the industry be willing to buy into the *promise* of "a paradise" in the *long* term at the price of fairly certain cost increases in the *short/medium* term ? All of the above means that a "promise" of cost reduction in the *long* term may not be sufficient - the new routing architecture needs to deliver in the *short/medium* term sufficient *tangible* benefits to justify its *short/medium* term cost. - One may argue that the real problem is not in the cost increases, but in the way how these increases are absorbed by the system. Namely, the real problem is that those who do not benefit are still required to pay for covering the cost imposed by those who do benefit. That applies both to the current system, as well as to any proposal for a new routing architecture. Yakov. _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
