RE: Regionally aggregatable address space for multihoming

["Tony Hain" <alh-ietf@tndh.net>]

> I believe there WILL be problems, the only question is how big
> they'll be.
I absolutely believe there will be work required to match what gets passed
in the routing tables with the desired traffic flows over the current
topology, or to modify the topology to align with this. If doing work
constitutes a problem then I guess your statement covers it.

> Since it is impossible to route strictly on geography alone (even if
> this were a possibility, then there would only be one route so this
> would defeat the purpose of being multihomed), my question is: why
> use such a strict relationship between prefix and geography?
Just like it is impossible to run dial modems faster than 1200bps, TCP
faster than 2 Mbps, or voice over a packet infrastructure. It is not
possible until we figure out how to do it. Note I am not proposing that
routers know about geography, but that a prefix they know how to deal with
be constructed out of something a telco installer can use to uniquely
identify a demarc.

For any given flow today there is only one route, the one defined by EGP/IGP
metrics. The fact that others exist is irrelevant until this one goes away
and a recomputation is done. With this prefix scheme (just like any existing
IPv4 one) there can be an unlimited number of parallel paths to the
destination and whichever one the source chooses is 'the only one' until the
source (or some intermediate router) chooses a different one. The difference
with this scheme is that the prefixes are structured on a global scale so
they aggregate well outside the scope of local provider interactions.

The only question I see as a sticking point is; will transit providers be
willing to charge for ingress offered loads in addition to the egress they
charge for today? If so they will be happy because they are getting paid to
carry traffic, if not they will really be against this since it would cause
them to carry traffic they are not getting paid for.

Tony