Re: [rrg] draft-narten-radir-problem-statement-05.txt

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
> 