a radical proposal (Re: protocols that don't meet the need...)

Fri Feb 17 02:05:23 UTC 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	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Gold's Law:
 	If the shoe fits, it's ugly.