Interesting, but this is all about "how to fix
IDR?" and "do we need a (completely) new Internet
routing architecture for that?".
What about optimal routing, "extremely
dynamic routing" from the RG homepage?
Or is this topic also pushed to academia
and we believe that MPLS would soften the
optimal routing problem?
-- dima.> -----Original Message----- > From: Geoff Huston [mailto:gih@telstra.net] > Sent: Thursday, December 14, 2000 4:38 PM > To: abha ahuja > Cc: Fred Baker; irtf-rr@nether.net; irtf-rr@puck.nether.net > Subject: Re: Wither irtf-rr > > > 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