Subject: RE: (multi6) requirements draft comments

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 18 Dec 2001 23:02:34 -0500

> From: "Tony Hain" <[email-masked]>

    > 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

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 19 Dec 2001 07:14:35 -0600

----- Original Message ----- 
From: "J. Noel Chiappa" <[email-masked]>
> of the topological boundaries (i.e. routing-name assignment) is completely

The "toy" legacy IPv4 Internet does not do routing, it does forwarding.

As for "lots of layers".....

This may help...
http://www.dot-biz.com/IPv4/Tutorial/
http://www.RepliGate.net

The Netfilter Project: Packet Mangling for Linux 2.4
http://netfilter.samba.org

Jim Fleming
http://www.IPv8.info
IPv16....One Better !!

---

From: Eliot Lear <[email-masked]>
Date: Wed, 19 Dec 2001 08:28:41 -0800

In a long line of silly comments, this is silliest.  Telling one of the 
people who
invented the concept of routing (and patented the multiprotocol router) 
that IPv4
Internet doesn't do routing just shows willful ignorance.

Please go away.  Perhaps the chair can help in this matter.

Plonk.

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Dec 2001 08:47:10 -0800

> To: "Jim Fleming" <[email-masked]>

please do not feed the trolls.  they can not digest it, and only puke on
the floor.

randy

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 19 Dec 2001 11:33:11 -0800

> better mousetrap is (since you don't like this one).

The primary problem is assuming there exists a one-size-fits-all
solution to the multi-facetted routing problem. We are currently
restricted to a one-size-fits-all routing protocol, so I believe we need
to allow another variable to change if we expect to meet the needs of
different sites.

> system

Actually the problem of maintaining connections is the easier one
technically, but the solution doesn't sit well with some incumbent
operators. The problem is handling the large sites that expect to be
able to engineer traffic flows, where the definition of that kind of
site needs to be crisp enough for the registries to distinguish it from
a home or a service provider.

As far as radical routing-name allocation system's go, several people on
this list consider my proposal draft-hain-ipv6-pi-addr-01.txt &
draft-hain-ipv6-pi-addr-use-01.txt in that catagory, but I just consider
it to be an overlay that complements the current scheme.

> sit well with the relevant companies.

This is fundamentally what I am suggesting, and it is being received
about as well as you have expected. To a first order, the bit pattern
really doesn't matter, it is the architectural concept that service
providers need to share customer access that is the stumbling block.
Since this is diametrically opposed to their business model the number
of possible technical solutions approaches 0 very quickly.

> automatic, routing-name allocation.

At least no single one.

> the "you have two routing-names (i.e. addresses)" approach,

I agree, but it really is a function of site goals as to which of the N
routing-names it wants to use for any particular application. It is
certainly reasonable for things which need to survive provider failures
to be in an independent address space, but if that is not a site
requirement, using N instances of PA space scales better in the routing
complex because it moves the scaling issue to the edge.

Tony