Re: [RRG] Geographic aggregation-based routing is at odds with reality

[Robin Whittle <rw@firstpr.com.au>]

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 rrg-request@psg.com 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