Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U)

From: [email-masked] (Noel Chiappa)
Date: Fri, 10 Nov 2006 21:18:28 -0500 (EST)

> From: John Leslie <[email-masked]>

    >> of course we still have to enter all the data.

    > Someone has to enter the data (except where a default will work), but I
    > don't think it's "we".

By "we" I meant "the Internet community as a whole".

    >> I don't believe in the "else try_and_forward(input_packet)"
    >> clause, except for local traffic)...

    > You don't have to believe it would always work.
    > But we do have to believe it would _sometimes_ work

Well, if you can't depend on it working (at least, in cases where the first
part of the "if" is not true), how much use is it, really? But moving on...

    > it would be _really_nice_ if we could believe it would work for a large
    > majority of current use. (Do you have evidence it wouldn't?)

I started to think through this whole issue, and discovered a problem. To see
it, let's think in a little more detail about how the routing in a "jack-up"
system is going to work.

You have two separate routing planes, a new one for new-type locators, and
another old one for old-style addresses. I know some would like to collapse it
into one, but let's keep it separate for now, for several reasons. First, I
think it's better engineering/etc, long-term, to have a separate system - more
flexibility, robustness, etc. Second, even if you do collapse them for
engineering efficiency (something I'd oppose, for the first reason), it's
easier to think about the problem if you have separate ones in your mental
model.

Let's start with a model of what's happening. You have a range of old-style
addresses Oi-j, which is entered into the what I'll call the "destination
mapping database" (because it turns out we need *another* mapping database,
for *routes*), which turns them into new-type locators Nr-s. Note that Ok-l,
Om-n, etc may *also* map to Nr-s - this becomes very important later. Iterate
over many Oi-j, Ok-l, etc and Nr-s. You also have Oa-b, Oc-d, etc which are
only served by "old-style" routers, and aren't yet in the mapping database.

Furthermore, here's what I think is a needed assumption: looking at the graph
of the network, if you look at the area of the Internet's connectivity graph
which is the "default-free" zone, some contiguous subset of that is modified
routers.

I know some people would like to say it shouldn't have to be contiguous, but
then things get *really* ugly, because then the distributed path computation
algorithm has to run across a mix of areas of new-style and old-style
routing-names, *and the names for entities which that computation uses are
going to have to get translated every time they get passed over a new/old or
old/new boundary*. This is really a problem, for several reasons. First, the
"destination mapping table" is prepared to translate from Oi -> Nr, not Oi-j
-> Nr-s. Second, the DMT is *not* prepared to do the reverse mapping *at all*!
Furthermore, a single entry Nr-s may map into multiple entries Oi-j, Ok-l,
etc. Very, very, ugly, and very, very likely to get screwed up. You do *not*
want to be doing that.

Having to translate from "a path to Oi-j" into "a path to Nr-s", as you go,
say, from some non-transit AS into the new DFZ is going to be ugly enough, but
it's kind of feasible, say with the appropriate table in the border
routers. (Handwave here about if we use a push mechanism, this means we may
not need the destination mapping database, this can be the source of the data,
but let's move on.)

Although, in the period where there's a large old-style DFZ, it's going to be
plenty painful maintaining that large full mapping, in both directions, which
you need at the boundary. (Only for Oi-j, etc, of course - Oa-b, etc have to
be injected into the new plane at the boundary "as is".)

In fact, given the difficulty of doing the reverse mapping Nr-s -> Oi-j, Ok-l,
etc, I'd say that the contiguous subset of the DMZ which is new-style routers
ought not be in the 'center' of the DFZ (i.e. you always have to go through
some old-style DFZ routers to get to edge AS's). Rather, it should be along
one "side" of the DFZ, with a single contiguous boundary between the old-style
and the new-style parts of the DFZ, which is where the mapping of routing
updates happens. I.e. most of its boundary is to leaf AS's. (Sorry if there
should have been a picture here!) That way, you're usually only giving the
leaf AS a default, and you don't need to explode Nr-s into its constituent
Oi-j, etc for them.

On the other end, I don't think it's feasible to assume the entire
default-free zone switches to new-style routers instantly, because that's
infeasible as a deployment plan. So between those two, I think my assumption
above ("some contiguous subset of the DFZ is modified routers") is shown to
be an OK assumption.

(People in the DFZ running old-style routers are going to be gagging on large
routing tables, so there - or ought to be, see below - an incentive to switch
ASAP.)

The way things *ought* to be able to work is that once you have the mapping up
in the destination mapping table, and you have made arrangements for the route
mapping, you *ought* to be able to withdraw Oi-j from the old plane (except
'near' the destination, i.e. in the AS which it's part of, of course), and
only advertise Nr-s in the new-style. Wrongo, perhaps.

Think about what happens when an old-style router in the "default-free" zone
gets a packet with a destination address in Oi-j. It has to have a route to
that destination, or it will toss the packet. So until there are no more
old-style routers in the DFZ, we have to keep injecting routes to *all*
destinations into the old-style part of the DFZ. Either that, or the DFZ has
to contain a default route, which goes to the nearest new-style router... If
we don't either i) kill all old-style routers in the DFZ, or ii) use the
default, we're *still* going to have to deal with the maximum-size old routing
table in all the old-style routers in the DFZ - which kind of defeats the
whole purpose, I'd have thought.

And here's where we get back to the original point that brought us here. It
would also be nice if, once a new-stle router has no old-style router
neighbours, only new-style router neighbours, it could toss the entire old
routing table, i.e. stop participating in the old plane. The reason is the
same as above: if we don't make that assumption, then *nobody* can stop
participating in the old plane until the last old-style DFZ router is shut
down - which again, kind of defeats the whole purpose.

But if a new router is not participating in the old plane, then the "else
try_and_forward(input_packet)" won't work, except for packets to local
destinations. Hence my previous intuitive statement:

    >> I don't believe in the "else try_and_forward(input_packet)"
    >> clause, except for local traffic)...

now seems to have some solid rationale.

Am I understanding this all correctly, or am I missing something obvious?

   Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss