Thomas, one major and some minor comments on the document.
The discussion of IPv6 routing table size in section 4.6 seems misleading. The discussion seems to have no component to represent the present and increasing demand for PI addresses in order to support multi-homing and ease of renumbering. If we do not have a routing architecture and system which addresses those pressures, and if we do not manage to keep in place an artificial barrier to such PI assignments, the size of the tables will grow dramatically. Some stimates place the expected number of multiohomed enterprises in the ballpark of 10,000,000. That would represent a significant growth in the control plane, the RIB, and the FIB.
Section 3.3 is titled "Alignment of Incentives". It then begins with a partial description of the pressures that Multihoming and Traffic Engineering put on the system. It would seem that the document would be clearer if there were a section describing the need to support multihoming and traffic engineering in general (leaving the details for section 4 probably), and the fact that these tend to produce growth in all the dimensions cited earlier. That could then be followed by section 3.3 with something similar to the current second paragraph, which is actually about the Alignment of Incentives. It would then seem sensible to include a paragraph about the need for any mechanisms for improvement to have to property that the costs and incentives for deploying the improvement are aligned. (This appears in the summary in section 6, but needs to be explicitly stated earlier in the document.)
Would it make sense to include in section 4.3 (End Site Renumbering) to observation that this problem has also driven some NAT deployments? (No, that is not a route scaling problem, but it reminds the reader of an indirect cost of not solving these problems in an effective fashion.)
Should we at least acknowledge in section 5 that our habit of addressing any and all problems with BGP extensions puts pressure on the control plane? (It may be that this component is manageable, but I wonder.) Each of these features have been put in for very good reasons, but RFC 2547 VPNs, Flow-Routes for black-holing DDOS, and add-path routes to allow use of multiple parallel routes, are all examples of features wew have or are putting in the system that increase the pressure on the Control Plane. [Note, I am not saying that these are wrong choices. They may well be correct choices, and BGP may well be the right place to address these needs. But we should recognize that this puts pressure on the system.]
Yours, Joel M. Halpern Thomas Narten wrote:
Hi. With the recent thread on route scaling, now might be a good time for folk on this list to have a fresh look at the "route scaling problem" document below. This was put together by the Routing & Addressing Directorate (http://wiki.tools.ietf.org/group/radir/) and is a joint effort by all of its members. The document has been sitting for a while, but we are now looking at it again with the goal of getting it published as an Informational RFC. In order to do that, we really need folk to review it and either point out its shortcomings, or indicate that it's a useful document to publish as is. Thanks!A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : On the Scalability of Internet Routing Author(s) : T. Narten Filename : draft-narten-radir-problem-statement-05.txt Pages : 25 Date : 2010-02-17 There has been much discussion over the last years about the overall scalability of the Internet routing system. Some have argued that the resources required to maintain routing tables in the core of the Internet are growing faster than available technology will be able to keep up. Others disagree with that assessment. This document attempts to describe the factors that are placing pressure on the routing system and the growth trends behind those factors._______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
