Re: radical solutions

[smd@ebone.net (Sean Doran)]

Capitalization is for clarity rather than shouting.  I am trying
to be polite, still.

| I don't see how easy renumbering really addresses the multihoming
| problem.

Well if you consider the multiple-IP-address approach to multihoming,
one of the problems is triggering a site-wide uptake of new numbers
or a site-wide cessation of the utilization of no-longer-valid numbers.

This is, in effect, renumbering.

If we stick to single-IP-address approaches, then moving from PA
space to PA space, is, as you say, an exercise in renumbering.
But so is moving from PA space to PI space.

Regrettably there is no working means for multihoming using CIDR
that does not at this time involve the use of PI space, whether
that PI space is assigned as-such or whether it becomes de facto
PI space by being announced as a "hole" in someone else's PA space.
You say much the same thing in your own note.

| isn't the problem precisely that *de*-aggregation is what is
| required today to get good multihomed service?

Well, my very first message, and itojun's useful followup, indicates
that there are different opinions on what is "good multihomed service",
and alot of them vary on the basis of how large a multihoming entity
one is.  (Large as a function of number of internal routers).

It is impossible to completely AVOID deaggregation without renumbering,
but it is possible to CONTAIN deaggregation, as is the case in v4 today,
where consenting parties exchange longer prefix privately to optimize
routing.

This is the basis of itojun's draft following the initial v4 work
by tbates; and it is a workable means of achieving "good multihomed service"
for SOME multihoming entities.

| If those IPv4 sites today were easily renumbered, how would you use
| that capability to reduce the growth and instability of the routing
| system while continuing to offer adequate multihoming service?

Well, we would see alot fewer holes: people could acquire a slow-start
allocation from a registry and grow into, and perhaps beyond, that.

We would also see cases where multihoming is for BACKUP rather than
for LOAD-SHARING: e.g., two connections who have opposite up-down state,
which is a popular service usually associated with volume-charged 
(at say the 95th percentile of 5-min averages) contracts.
If renumbering can be done fast enough, and with minimal impact to
existing connections, then this kind of "protection switching"
can be done with zero impact to global routing tables.

If the impact is small & short-term, it can be mitigated through
the use of tbates-like tunnel-based exception routing to catch
the things that arrive in the wrong part of the topology while
renumbering is underway.

On the LOAD-SHARING front, there are sites and big-eyeball-providers
which would happily put some percentage of their hosts in one PA
prefix and the remainder into one or more other PA prefixes, and
use the numbering to balance inbound load, with renumbering
used occasionally to optimize the load-split (with a purely 
local definition of optimal) and to cope with network failures
which break or impair performance for hosts with a given PA prefix.

Then there are various classes of networks who cannot easily
renumber or which have such rich connectivity that the load-sharing
approach above is intractable.  These just have to "deaggregate",
although I believe it is better to renumber into a brand new PI
prefix in slow-start allocation mode than it is to blow holes
by announcing PA subnets.

	Sean.