RE: (multi6) requirements draft comments

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    > From: "Tony Hain" <alh-ietf@tndh.net>

    > replacing all the applications with ones that ignore those changes is a
    > fantasy .. even if you got those to things done, the topology shift
    > renumbering would create a DNS update spike that would take out all
    > name services

I must confess I've only been listening to this exchange with half of one
ear, so perhaps I've missed something, but I'm wondering what your proposed
better mousetrap is (since you don't like this one).

Sure, supporting multi-homing in the routing works for a few sites, but if
(say) 30% of all homes are multi-homed (to produce a nice big user base), and
want open connections to stay up when the "primary" link fails (the most
technically aggressive case), then trying to do it in the routing just isn't
going to fly, at least without a fairly radical routing-name allocation
system (see below).


Remember the "Key Multihoming Observation #0" from:

    http://ana-3.lcs.mit.edu/~jnc/tech/nsrg/multihoming_points.txt

which is:

  "TANSTAAFL: There Ain't No Such Thing As A Free Lunch"

  Multihoming is something that is done to provide *benefits*. Those are not
  *free*. There is a *cost* for them ...

In other words, don't expect to get the benefits of globally deployed multi-
homing without paying some costs.

So people who say "oh, we have multi-homing now, what's the problem" - that's
total bilge. We don't have real multi-homing - we have a hack that works if
only a few people use it (i.e. low systemic cost).


To explain my aside about "fairly radical routing-name allocation",
Kleinrock/Kamoun says that you can get scalable routing in *any* arbitrary
graph (including ones with every house multihomed), so theoretically at least
we might be able to get multi-homing support with the support costs buried in
the routing overhead.

(Actually, now that I think about it, I'd better go check that their results
to apply to *any* random graph; more on this below.)

However, I don't think we're going to get there with the current routing-name
allocation system; we'd probably have to have some fairly radical system
where there's *lots* of aggregation (i.e. lots of layers) - and the placing
of the topological boundaries (i.e. routing-name assignment) is completely
automated.

To put this a little more concretely, if you read the K-K math, their results
hold for their optimal aggregate size which is, IIRC, "e". That's right, 3
level-N entities per level-(N-1) object. So a network X nodes would need
ln(X) levels of addressing; e.g. a 100M node Internet would need 19 layers of
addressing. Now, it turns out you don't really have to go to that extreme,
since their scheme produces ridiculously tiny routing tables; IIRC, they are
e * ln(X). We don't really need 60 entry routing tables!

Still, a address aggregation hierarchy which did work with large numbers of
multihomed sites would probably do things like group me and my neighours who
have CATV into one fairly low-level entity - and assign *both* the CATV and
DSL links a single fairly-low-level routing-name - which probably wouldn't
sit well with the relevant companies.

Now that I think about it, though (this is the aside from above), it's perhaps
the case that there are very pathological graphs in which the K-K results
*don't* hold - and a graph in which there are basically two kinds of nodes, a
very large group with only two neighbours, and a very small group with many
thouands, might be one. This makes sense: it will be impossible to form those
3-element groups (remember them?) in such a graph.

So, perhaps there is no routing solution, even with an aggressive, and fully
automatic, routing-name allocation.


So if you can't cram it into the routing that way, you're pretty much back to
the "you have two routing-names (i.e. addresses)" approach, with all that
implies.

But remember, TANSTAAFL. Somebody, somewhere, has to pay (and I don't mean $)
to roll out this wonderful benefit.

I will leave you wth another quote from that document:

   JNC Corollary to the JTW Principle: - It is best if one can allocate the
	costs so that the entities which benefit from the multihoming are
	the ones to bear the cost.

I was going to say more about multiple routing-names, but I seem to have
run out of brain cells. Anyway, this is long enough already.

	Noel