Subject: Re: [rrg] Next pass

From: [email-masked] (Noel Chiappa)
Date: Sun, 25 Apr 2010 18:09:47 -0400 (EDT)

> From: Russ White <[email-masked]>

    > the point is that while loc/id split might be neat ... I don't know
    > that loc/id separation "solves" any sort of "table size" issue

I can give you several examples where it can reduce the table size.

First, let's consider an 'optimal entry router' problem: i.e. site X has a
large interal network, is connected to the Internet in several places, and
wants inbound traffic to take the interconnect which is 'closest' to the
destination, internally. Today, one has to do this by leaking internal routes
outside site X, i.e. not advertizing just a single route to X, outside of X.
If one has a location/identity system which i) allows giving a site border
router as the location, ii) is demand driver (i.e. mappings are not flooded),
and also allows giving different mappings to different mapping requestors,
one can fairly easily cause traffic to take the optimal entry router, by
setting the appropriate border router in the mapping reply. This obviates the
need to leak 'more-specific' routes outside a site.

Second, consider a site that wishes to multihome. Right now, the only ways to
do this are either i) give each host multiple addresses (aka SHIM6, which
most sites do not like), or ii) use PI addresses - which increases the
routing table size. In other words, the only practical method for site
multihoming currently increases the routing table size. With a
location/identity separation system in place, as long as it's one that allows
1->many mappings for the {identity -> location} binding, it's easy to
multihome a site: the mapping just gives the multiple locations which a site
is multi-homed to. This obviates the need to advertize a PI address
network-wide in order to multi-home a small site.

That's just off the top of my head, quickly - there may be other cases too.

Having pointed that out, location/identity separation is not a panacea for a
more advanced routing architecture. It can do _some_ things fairly well (e.g.
support small-site multi-homing), because one has two names available to play
with, each of which has simpler semantics than classic 'addresses', and any
time one has a binding layer, one can get some power out of that (c.f.
Lampson's Law, 'one more layer of indirection'). But it's clearly not routing.

On the other hand, many people who have looked at advanced routing
architectures do feel that location/identity separation is a necessary
precursor, for a number of reasons, one of which is that the characteristics
one wants to see in the names used by routing is rather at variance with the
characteristics one wants to see in the names used in end-end communications.

	Noel

---

From: Russ White <[email-masked]>
Date: Sun, 25 Apr 2010 22:56:19 -0400

> I can give you several examples where it can reduce the table size.

I can give you examples where loc/id will reduce the table size. I can
give you examples where simply aggregating will reduce the table size. I
can give you examples (and mechanisms) that will reduce the table size
through filtering of unneeded routes at the point where they're no
longer needed (remember the old "inbound route summarization" draft?).

Anecdotal evidence doesn't provide an answer, though.

1. We have mechanisms we could use to reduce the table size today,
already in the protocols coded and deployed.

2. Such mechanisms are not used today.

3. Why?

I'm sorry to say I disagree with the general consensus that multihoming
is the problem... Every enterprise I've asked about using PI space, and
every SP I've ever asked about aggregation has told me longer prefixes
are important to control the way traffic _enters_ their networks. The
degree of control here is rather find grained, in fact, based on where
and how particular customers are attached, and even where specific
services live in the customer's network.

Given all the above, some major part of the answer to "why," in #3
above, seems to me to be, "because we want to control inbound traffic
flow."

Now, let's consider this: There's an economic incentive to control
inbound traffic flow, in terms of additional link/equipment costs, etc.
The economic cost of injecting new state to control inbound traffic flow
is small, incremental, and mostly externalized.

Two costs, one of which is immediate and observable, the other of which
is incremental, included in the first cost anyway, and mostly apparently
externalized. I don't have to guess at which cost wins. There are only
two real solutions:

1. Change the economic model somehow--internalize the cost, reduce the
cost of bandwidth, etc.

2. Stop switching packets.

Well, there is a third--just deal with the additional state.

Splitting locs and ids doesn't change the underlying fundamental model
here--the cost of adding new state is still small, incremental, and
mostly externalized, the cost of adding new bandwidth is still large,
immediate, and mostly internal. I suspect you just end up with a locator
table that's generally about the same size as the current routing table
(my guess is it will end up being  at least one loc per PE, possibly
more, depending on your model), and an ID table that's absolutely
_flooded_ with new state (after all, the state is now externalized in
such a way that advertising an IPv4 /32 doesn't really "cost" anything
any longer, does it?).

I'm not a betting man, but if I were, I'd bet a loc/id split will
probably reduce the table for a few years, everyone will declare
victory, and then in seven or ten years the table sizes will be
unbearable again. The first stab at "fixing" it will be to slow down the
propagation of the id table, so it's closer to DNS... And then we're
right back to where we are today, only with two naming systems instead
of one. The network will be more complex, and hence the problem will be
more intractable.

The roots of this problem are policy and economics, not technical. A
technical solution might provide a mechanism people can employ to
resolve the problem (if there is a problem in the first place), but a
technical solution isn't going to convince people to change their
economic behavior--at least I don't think it is.

:-)

Russ

P.S. I'm on vacation for the next two weeks, so I won't be following
this for a bit. None of the above is to say I find some of the solutions
proposed interesting (and some of them give me the heebie-jeebies). I
just that I don't think reality will curve the way we want it to just
because we think it should.