The problem with this scheme is that it's only aggregatable if there's
some POP that lots of carriers connect to in the proper geographic
areas. What is the carriers' incentive to show up -- peer? -- at such
points, rather than following today's practices?
--Steve Bellovin, http://www.research.att.com/~smb
Steven M. Bellovin wrote:
...
The problem with this scheme is that it's only aggregatable if there's
some POP that lots of carriers connect to in the proper geographic
areas. What is the carriers' incentive to show up -- peer? -- at such
points, rather than following today's practices?
It doesn't require POPs per se, but that might be the simplest
implementation. It does require some form of peering agreement for a service
region which could be implemented with traditional transit arrangements. The
incentive question is still open though. One incentive would be the
trade-off against a routing swamp, but by itself that is probably not
enough. Another incentive might be to stave off the recurring threat that
the ITU/Governments could impose worse approaches. If I had an answer to the
incentive question it would probably be easier to make progress.
Tony
The problem with this scheme is that it's only aggregatable if there's
some POP that lots of carriers connect to in the proper geographic
areas. What is the carriers' incentive to show up -- peer? -- at such
points, rather than following today's practices?
Leaving aside the specifics of any particular geopgraphic
addressing scheme for the moment...
If we adopt a geographic addressing scheme for a part of
the IPv6 space we are really saying that we expect a
part of the IPv6 network topology to be geographically
based. While it is convenient to think og geographical
divisions in terms of boundaries, in real world networks
the geographical divisions are defined by peering points
which the real world refers to as "major cities". So if
we do adopt a geographic addressing scheme it makes no
sense at all for the RIRs to allocate these addresses to
entities that happen to be inside a specific geographic
boundary. However, it makes perfect sense to allocate
these geographic addresses to an entity who is peering
at one or more of the peering points within a geographic
boundary.
This doesn't mean that everybody at the peering point
gets geographic addresses but it does mean that organizations
who have hierarchical networks with geographically
delineated subdivisions can get geographically aggregatable
space.
For example, let's assume that one of the geographical divisions
is the Romance countries. Outside of these countries the geographical
address space for this region would consume exactly one
routing table slot, no more. Everyone would route the traffic
to the nearest network (using non-geographical addresses)
which peers at one of the peering points in Paris, Madrid,
Lisbon, Milan, Toulouse, etc. The global routing table
would be smaller because networks which do not need
detailed global visibility will not be using normal PI
addresses.
Geographic addressing will only work if non-geographic addressing
also exists and if the geographic divisions are neither to
small nor too large. RIR boundaries are too large. Most
national boundaries are too small.
With IPv6, routing table size grows 4 times due to
the 128 bit addresses. With IPv6 routing table size
shrinks because most ASes only need one /32 route.
With IPv6 routing table size explodes because most
businesses want to multihome. With IPv6 and geographical
addressing, routing table size shrinks because most
multihomed businesses only need global visibility of
their routes within a larger geographical aggregate.
--Michael Dillon
The problem with this scheme is that it's only aggregatable if there's
some POP that lots of carriers connect to in the proper geographic
areas. What is the carriers' incentive to show up -- peer? -- at such
points, rather than following today's practices?
Leaving aside the specifics of any particular geopgraphic
addressing scheme for the moment...
Right. There are several ways to do this.
If we adopt a geographic addressing scheme for a part of
the IPv6 space we are really saying that we expect a
part of the IPv6 network topology to be geographically
based.
This is what it seems like on first glance. However, if we take a different approach we arrive at the same result but with a very different mindset.
The idea is that we need to aggregate, because if we let anyone and everyone have a PI block without aggregation in IPv6 bad things will happen to the global routing table. The obvious thing to aggregate on is the ISP used. This is what we do every day. Unfortunately, you don't get provider independence this way.
With provider aggragation out the window, it turns out that it doesn't really matter much on what you aggregate. For instance, we can aggregate on the first byte of the IPv4 address. So all destinations that have 192 as the first number in their address are aggregated together, just like 193, 194 and so on. Suppose we have three routers:
Router A contains all more specifics for 192/8 and the 193 and 194 aggregates
Router B contains all more specifics for 193/8 and the 192 and 194 aggregates
Router C contains all more specifics for 194/8 and the 192 and 193 aggregates
So all traffic towards any destination within 192/8 will have to flow through router A, and so on. This works very well if router A is close to the destinations in question, but it gets problematic when there aren't any routers covering the aggregate for a certain destination close to that destination. So if destination X with address 192.0.0.1 is in Paris, and router A is also in Paris, this works out great. If router A is in London or Frankfurt, this isn't quite optimal but the scenic routing isn't too bad. But if router A happens to be in Auckland, this is not so great.
There are two ways to solve this:
1. Have router A instances everywhere. This basically means multiplying the number of routers by the number of aggregates used. Not so great.
2. Rather than aggregate arbitrarily, do it based on geography so there only need to be a few router A instances.
While it is convenient to think og geographical
divisions in terms of boundaries, in real world networks
the geographical divisions are defined by peering points
which the real world refers to as "major cities". So if
we do adopt a geographic addressing scheme it makes no
sense at all for the RIRs to allocate these addresses to
entities that happen to be inside a specific geographic
boundary.
No. You are assuming a single aggregation level. But there can be many: city, state/province, country, continent. If I have traffic for Amazon, all I need to know is that it should make its way across the Atlantic. At the US East Coast, there are probably aggregates for all the US states, and finally in or close to Seattle all more specifics must be present.
Should there not be an interconnect with other networks in Seattle, then the more specifics must be present in a wider area. So peering within the target area isn't required, although it makes for better aggregation of course.
However, it makes perfect sense to allocate
these geographic addresses to an entity who is peering
at one or more of the peering points within a geographic
boundary.
Peering can change. Geography can't. (Unless you live in an earthquake-prone region.)
The advantage of doing geographic aggregation like this (i.e., the aggregates are only used within ISP networks and not announced to other ISPs) is that everyone can implement the aggregation as desired without global coordination, but the PI benefits start as soon as end-users get the geographically aggregatable address space. So it makes no sense to adopt unaggregatable PI space, geographically aggregatable provider independent (GAPI) address space is always better.