Re: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6
-
To: "" <>
-
From: "Oliver Bartels" <>
-
Date: Wed, 07 Dec 2005 16:35:01 +0100
-
Priority: Normal
-
Reply-to: "Oliver Bartels" <>
On Wed, 7 Dec 2005 14:40:47 +0000, Michael.Dillon@localhost wrote:
>This is not about cost. Does an STM-1 between Wiesbaden
>and London cost less than one between Wiesbaden and
>Frankfurt?
Between the right end points: Yes.
Thanks to DWDM.
The cost of leased lines is mostly dominated by
- competition / available number of carriers
- spare capacity
- (central) locations of the end points
It is no longer dominated by line length. This holds even
true for regulated pricings like DTAG SFV/CVF in Germany,
the new price list contains huge discounts for connections
between backbone cities, smaller discounts between other
cities and backbone cities versus full price for arbitrary
connections, even thru there is still a distance component.
However the influence of the distance component on pricing
becomes very small on long distance leased lines.
>Or does it pass through Frankfurt because it
>is a neighbouring city?
No.
Frankfurt contains a lot of telco infrastructure with huge
competition. You might even get a leased line between
Frankfurt and New York with a pricing comparable to a
local line. There is simply enough spare capacity,
with DWDM you may put e.g. 400 GBit/s on a _single_
fiber pair. The whole DECIX has a peak throughput
around 50 GBit/s. As long as there is a dark fiber,
bandwidth is no longer an real issue.
>If we did use a geotopological allocation scheme for
>another 1/8th of the IPv6 address space, this is an
>example of an area where there is a logical clustering
>of cities into a larger geographical aggregate. Wiesbaden,
>Mainz, Darmstadt and Frankfurt are all over 100,000 population.
>It is logical to reserve a single aggregate for them that
>covers all 4 city aggregates. That way, providers can choose
>to accept all city-level aggregate routes or to only see the
>single regional aggregate. Chances are that North American
>providers will only use the one regional aggregate while
>man Europeans will distinguish all 4 cities.
The key point is: The property "traffic belongs to ISP X" is
_much_ more important than the property "traffic belongs
to region Y". E.g. one might have a peering with ISP X,
which means settlement free traffic exchange, compared
to transit. Thus there is always the need for the full table
if one would like to implement complex routing policies
to consider quality and economical facts.
As there is just one sorting criteria possible for an linear
ordered address space, one must be the dominant, and this
is by decision of the huge majority of the participants in
the game: "ISP X".
A regional ordering as dominant criteria would blow up the
table dramatically, because of the need of the "from ISP"
information for every region.
What you can do: Make a proprosal to sort the minor
adressing inside an ISP's allocation to regions. So one could
use this additional information.
But to be honest: I don't believe you will get acceptance on
such a proposal, the infrastructure and distribution of customers
to regions is too different between ISP's.
>That's not how IP routing works. Anyone can announce any route
>that they want,
Of course you might filter out all routes and get no connectivity
at all. Or you would need a default route which moves the job
to the next Tier level, but doesn't solve the problem.
>but network providers filter incoming route
>announcements based on some sort of logical view of the network
>topology.
As there is no guranteed transit or peering between different
ISP's in a region, however as a peering or transit agreeement
between ISP's typically covers the whole _company_, the
primary sorting criteria for functional routing decisions and
thus the MSB's in the Prefix address is the ISP company id.
and not the region id.
Again: Sorry, that I have no better news, it is the way it is.
Best Regards
Oliver Bartels
Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany
oliver@localhost + http://www.bartels.de + Tel. +49-8122-9729-0
|