|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: a radical proposal (Re: protocols that don't meet the need...)
On Thu, 16 Feb 2006, Vince Fuller wrote: to two popular "geo-topo" addressing domains, say the Bay Area and the DC area. Let's say that 10.0.0.0/8 is the "geo-topo" address block in the Bay Area and 172.16.0.0/12 is the "geo-topo" block in the DC area. This provider has four customers in the Bay Area: customers. For him to provide connectivity to all the address range, he must
That's not quite correct. They would have to:
a) Have full routing connectivity to all other providers who
provide transit in/out of the area concerned.
It does not imply:
- having to peer with every provider in the area (some
providers may be wholly within the area, you wouldn't need
to peer with them, only their 'transit provider')
- having to peer at every IX (you only need to fulfill
condition a)
- that peering with the other providers who provide
inter-geo-area service, with whom you must peer as per a,
must occur locally - it does not. (e.g. you could hand-off
ACME providers Bay Area prefixes to ACME at DC if you
want).
Right. If you're handing off X GiB of 10/8 Bay Area traffic to ACME provider each day, then you would (presumably) charge ACME your costs for those X GiB. ACME presumably would do likewise for traffic to 10/8 they carried that happened to be one of your customers instead. So it's normal peering business; indeed it could be a beneficial business model to try carry as much of that 10/8 traffic as possible. Some upsides: - scenic routing would be far less prevalent. - trivial provider-changing for customers / much increased competition (easier to attract new customers away from other providers). Some big downsides: - trivial provider-changing for customers (your competitors can get your customers to change over more easily than today) (I suspect providers would be more wary of this than they would welcome the /increase/ in competition ;) ). - every customer's (using these geo-assigned addresses) traffic is dependent on every transit provider. So ACMEs' customer could face an outage because "Barr's Internet Services" has a failure. This could be mitigated with good practices (ensure that those providers who provide transit into the area only ever originate the area-prefix from within the area, never outside - hard to know how that could be enforced) - Co-ordination of origination the prefix: How do you ensure that those providers who announce the 10/8 prefix are only those providers who are peered with all the others? Squabbles could get really ugly and affect /all/ users in that block, regardless of whether they are customers of the squabbling providers. We have settlements today already. The money factor isn't a problem really - seems to me at least the money aspect could work fine for geo-addressing, as it (should) do for transit services today. It's the other inter-provider co-ordination problems that would make it problematic."Addressing can follow topology or topology can follow addressing. Choose one." and I'd offer a corollary: Transit relationships (i.e money) must follow topological relationships (and thus addressing); the alternative is some combination of inefficient or non-scalable routing, black holes, settlements, regulation, or other undesireable things. There'd need be someone who could "enforce the law", after defining the "law" of course ;). Though, we happen to have such a body in my country funnily enough. If you really want to combine transport identifier and routing locator into a single "address", you give up a lot of flexibility. For routing to scale, addressing must follow topology, so in such a network architecture the term "topology independent address" (aka "provider independent address") is truly an oxymoron.Right. The logical step then is for leaf-sites to build upon this topology-addressed network and advertise the lists of "topology identifiers" by which they are reachable to each other: shim6. Smart hosts communicating over a dumb network. Providers aren't happy with that either though, judging by some of the grumbling wrt shim6. But that's the only solution left unless some new 'break-through' solution is discovered. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Gold's Law: If the shoe fits, it's ugly.
|