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...)

  • From: Paul Jakma
  • Date: Thu Feb 16 21:05:57 2006

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:

10.1.1.0/24
10.10.4.0/22
10.100.8.0/21
10.200.0.0/16

customers. For him to provide connectivity to all the address range, he must

 a) have full routing connectivity to all other providers that have
    addresses in the same range; this implies that he connects to all IXs
    within the region and maintaines a full-mesh of routing information
    (today, BGP sessions) to all of these providers
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).

 b) must be willing to provide connectivity to all sites within the region
    to any place that he advertises the prefix 10.0.0.0/8
Right.

    through routing
    exchanges; if he advertises this prefix to non-customers, it implies
    that he is will provide free transit to his competitors' customers
    which are numbered out of this block
That's not correct. Nothing says it has to be free.

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.

 "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.
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.

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 [email protected] [email protected] Key ID: 64A2FF6A
Fortune:
Gold's Law:
If the shoe fits, it's ugly.