Hi Iljitsch, Heiner's system doesn't cope with the needs of ISPs and end-user networks to be able to apply policy at their routers, to control the flows of packets to those networks for which they know will carry them, according to contractual agreements:
http://psg.com/lists/rrg/2008/msg01815.html Tony seems to admits that geo-aggregation is more of an academic than a practical idea: http://psg.com/lists/rrg/2008/msg01860.html and that it would require cooperation and business motivations which are at odds with centuries of standard business practice. > This clearly has a return, it's just not tightly coupled to the > investment. I don't have time to read your 2003 I-D fully: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt but in your Limitations section, you write, in part: Since this scheme depends on geography for aggregation, it only works well for organizations that connect to the internet in locations that are close together. An organization with a network spanning multiple countries and connecting to the internet in all those countries isn't geographically aggregatable, and neither is an organization connecting to ISPs very far way, for instance by means of a satellite circuit. These types of organizations must choose address space falling within a geographic area that doesn't (fully) fit if they elect to use the type of address space this aggregation scheme uses. ! This choice will have consequences on routing efficiency, and ! when the infrastructure changes, the organization may need to ! adopt a new address range to minimize the routing efficiencies ! created by the change. Although the notion of geographic aggregation has been discussed many times within the IETF over the past eight years or so, this approach is generally believed to be flawed since the topology of * the networks that make up the internet and the interconnection * between those networks doesn't align well with geography. This is * indeed a problem, but it doesn't automatically make geographical * aggregation useless, it only makes it less effective. Since network topology is under constant revision, and as ? networks get faster, the main disadvantage of "scenic routing" ? (the increased speed of light delay) becomes more acute as bandwidth increases, it is certainly not unthinkable for the topology of the internet to align itself more with geography over time. Why would any organisation want to have its choice of address space constrained by your geo-aggregation idea? What good does it do them, especially if the constraints change and require it to change its address assignment when the topology changes? Geo-aggregation is trying to shoehorn the entire addressing and interconnection arrangements of all providers and end-user networks into a set of constraints which do not suit those organisations, for the sole purpose of enabling the Internet to be connected with relatively simple routers. I think this is exactly the wrong approach. Organisations need flexibility in choosing their addressing arrangements, in choosing who they connect to, in choosing whose traffic they will accept for transit to another network etc. Geo-aggregation forces humanity to bend to meet the needs of a dumbed down routing system. It is non-trivial thinking of a better routing and addressing system, but some folks have tried: LISP, APT, Ivip, TRRP, Six-One Router. I am sure it will be easier to achieve any of these - which attempt to meet actual needs of organisations - than to somehow change the thinking of the great majority of organisations to make them happy to accept the constraints of any geographically based addressing regime. You would also have to change the thinking of their shareholders. In order to solve the routing scaling problem we need to devise a new technology which *most* - ideally 90% or 99% or whatever - ISPs and end-user networks will *want* to adopt, within a few years. The reason they want to adopt it cannot depend upon the slow-moving global situation of the DFZ routing table, since that only becomes less troublesome after most people adopt the new system. They need short-term, robust, reasons for adopting it - reasons which make sense to their current business priorities. This is analogous to solving the global warming problem. It is no good making a solution which doesn't give people some benefit immediately. Only a few will adopt a new solution which is less convenient for them simply because it does something to help stop the greenhouse effect. We need something which is highly attractive to the great majority of end-user networks, and their ISPs - something which also enables the Internet to scale well. It is not good enough if only 30% or 70% of the end-user networks adopt it. That would only cut the problem by these amounts. We need to cut the problem by several orders of magnitude in order to enable the millions of end-user networks (including small home and office networks) to have multihomed, portable address space - without causing scaling problems in the DFZ routing table. Map encap schemes have faced criticism from some folks because they would be hard to scale to billions of EIDs. This means those critics must think there is a need and demand for this number of end-user networks with their own multihomable, portable address space. So if your system is to cope with this, it has to minimise the scaling problem at any one router by many orders of magnitude - and this requires almost ubiquitous adoption, not just a mish-mash of geo-aggregation and its associated pattern of idealised interconnects, alongside networks connecting in the current pattern which is highly variegated. I understand the ideal of geo-aggregation is to make life easier for routers, but it has no direct benefit for adoptors over its costs and restrictions - so it could never be adopted widely enough (90% to 99%) to be a proper solution to the routing scaling problem. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
