At 12/14/00 04:27 PM -0500, abha ahuja wrote:
>> >we definitely still feel that there are important issues to tackle. :)
>> >everyone, of course, is free to start the discussions on the list...
>> >if you have things you feel are of concern, please post!
>>
>>
>> FYI, there is enough concern on the IAB and IESG that you can expect them
>> to start some ideas moving as well.
>
>Great! We'd be happy to work with them... What are their concerns?
the long version or the short version?
oh well - here's the long version
[excerpt/adpatation of a paper I authored, to be published in the Internet Protocol Journal in March 2001]
There are strong parallels between the BGP routing space and the condition commonly referred to as the tragedy of the commons. The BGP routing space is simultaneously everyone's problem, as it impacts the stability and viability of the entire Internet, and noone's problem in that no single entity can be considered to manage this common resource.
Multi-Homed small networks
It would appear that one of the major drivers of the recent growth of the BGP table is that of small networks multi-homing with a number of peers and a number of upstream providers. In the appropriate environment where there are a number of networks in relatively close proximity, using peer relationships can reduce total connectivity costs, as compared to using a single upstream service provider. Equally significantly, multi-homing with a number of upstream providers is seen as a means of improving the overall availability of the service. In essence, multi-homing is seen as an acceptable substitute for upstream service resiliency. In such an environment resiliency still exists, but rather than being a function of the bearer or switching subsystem, resiliency is provided through the function of the BGP routing system. The question is not whether this is feasible or desirable in the individual case, but whether the BGP routing system can scale adequately to continue to undertake this role.
A denser interconnectivity mesh
The decreasing unit cost of communications bearers in many part of the Internet is creating a rapidly expanding market in exchange points and other forms of inter-provider peering. The deployment model of a single-homed network with a single upstream provider is rapidly being supplanted by a model of extensive interconnection at the edges of the Internet. The underlying deployment model assumed by CIDR assumed a different structure, more akin to a strict hierarchy of supply providers. The business imperatives driving this denser mesh of interconnection in the Internet are irresistible, and the casualty in this case is the CIDR-induced dampened growth of the BGP routing table. Given that small prefixes continue to have a relatively dynamic aspect, and that route flap damping as we know it today is ineffective in the face of the changes in the routing changes that occur in the Internet today, is there a way to scale a routing system while admitting the frequent changes of fine-grained policy? Do such dense meshes affect convergence? Are there ways to use a even denser mesh while not cause update storms and unstable intermediate states?
Traffic Engineering via Routing
Further driving this growth in the routing table is the use of selective advertisement of smaller prefixes along different paths in an effort to undertake traffic engineering within a multi-homed environment. At this stage the only tool being used for inter-provider traffic engineering is that of the BGP routing table, further exacerbating the growth and stability pressures being placed on the BGP routing domain. If there a way to express traffic engineering preferences in such a way that does not overload the BGP table with pplicy applied to specific prefix announcements?
Post-CIDR
The effects of CIDR on the growth of the BGP table have been outstanding, not only because of their initial impact in turning exponential growth into a linear growth trend, but also because CIDR was effective for far longer than could've been reasonably expected in hindsight. The current growth factors at play in the BGP table are not easily susceptible to another round of CIDR deployment pressure within the operator community. It may well be time to consider how to manage a BGP routing table which has millions of small entries, rather than the expectation of tens of thousands of larger entries.
How's that for a set of concerns and the motivation for these concerns as a starter?
Geoff
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT