On Apr 30, 2007, at 12:54 PM, Tony Li wrote:
On Apr 30, 2007, at 1:52 AM, Brian E Carpenter wrote:
Thus, the first required goal is to provide significant
improvement
to the scalability of the routing plane.
Should we be looking for a way to measure that goal? For example,
by having a goal that the RIB size goes like log(N) for some
measure N?
Obviously that is simplistic - my point is to ask whether we
want to define metrics.
Well, my take on it is that we will have a hard time being
quantitative about all of the goals. How do we quantify
'deployability', for example? And if we can't quantify all of the
goals, is there really a benefit in quantifying some of them?
I think so, where it's possible. And I'm really not looking for
firm numbers necessarily - just something that allows us to review
a proposed solution other than by gut feeling.
There are also other considerations, such as folks "designing to
the test" and gaming the system by rigging the goals that we should
avoid, IMHO.
Yes. But things like "log N rather than N^2" probably can't be gamed.
Brian,
I'm not opposed to the suggestion, but I'm not sure how to specify
metrics that will capture proper space/time complexity measures
without inviting folks to drown us in detail or enable gaming.
Specific contributions are most welcome.
Let me try a strawman here: as far as we can see from the BGP data, the
number of ISPs has been grown very slowly over the years; today's
routing scalability problem is largely due to the growth of Internet
user sites which are also multihomed. And because the ISPs are the ones
who feel the pain when the routing system size grows beyond
"comfortable" range, there seems a feedback loop for ISP-induced routing
growth.
So What about adding the following quantifier to the existing
scalability goal:
the first required goal is to provide significant improvement
to the scalability of the routing plane; it is highly desirable
to make the routing plane scale independently from the Internet
user population growth.