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 18:42:04 -0500 (EST)

> From: David Conrad <[email-masked]>

    >> If we go the jack-up route (to avoid having to modify hosts), then we
    >> have a big, painful job ahead of us, which is to build, deploy, and
    >> populate that mapping database - the one that maps from old-style
    >> "addresses" (aka identifiers, now) to new-style locators.

    > If the destination DNS has:
    > No new technology needed, just a small matter of programming.

If I understand what you are proposing (it's been so long since I looked at
the DNS that the bits have all been swapped out to a tape drive in my brain
that has gone offline :-), you're basically proposing to use the DNS as the
mapping database. That way we don't have to design, build or deploy it, it's
already there. That's perfectly feasible, but of course we still have to
enter all the data.

I'm not sure why I assumed we'd build something new. I do know that every
time in the past when I tried suggesting we'd use the DNS for anything
related to this kind of stuff, Keith Moore would go totally non-linear,
saying that for a variety of reasons (I'll let Keith explain, if you want
details) that was a Really, REALLY, Bad Idea. Basically, IIRC, it boiled down
to the DNS being too flaky and overloaded (in the conceptual sense, not
number of packets sense) already.

It's certainly true that the mapping database becomes something that has to
be running before packets can flow (sorry, I don't believe in the "else
try_and_forward(input_packet)" clause, except for local traffic), so it's
really critical.

I'd also want to make sure we aren't getting in any dependency loop issues
(e.g. on cold-boot after the next big regional power failure, A needs B to be
up before it can restart, and B needs A to be up). If so, a separate database
might make it easier to solve any such issues.

Anyway, I wonder if you're not falling into "this problem is easy if I give
the hard part to someone else" syndrome. (The classic example of this is that
lots of people think multi-homing via PI is easy, because it gives the
problem to the routing. NOT!)

I wonder if the DNS people won't go non-linear when you spring this on them,
saying the DNS has enough problems already, without adding this functionality
too, etc, etc, etc. You might wind up having to do a database...

    > The mapping is done at the edges, distributing both the map database
    > and the lookup load.

Oh, I always assumed that. That why I said "make it a distributed database".
Oh, I should have said "replicated," - typing too fast!

One big central database, or even a small number of them, is clearly a bad
idea for about 9 different reasons.

    > there are disadvantages to this approach (the first packet latency hit

Well, that's true of any jack-up scheme that relies on querying a database,
instead of having a complete mapping database already on hand.

    > there are other approaches (some sort of push method, e.g., a BGP
    > attribute)

Hmm, intesting idea. You get the range(s) of identifiers that map to a
particular locator (which might be a high-level aggregate) when you get
information about the path to the aggregate.

The nice thing about using a database, though, is that it gives you an place
to go and update the mapping, though. (Yes, yes, I know, routing tables are
just a large distributed replicated database too... :-)

For instance, one issue with predistributed tables that is that it makes it
harder to do certain kinds of mobility (e.g. slow motion) where it's feasible
to do it by changing the mapping in the database for just that one node. No
way you'd want to inject that info into the routing.

That one may not be that important, but here's one that is: avoiding the
query/response cycle also makes doing fault bypassing with multi-homing
harder. E.g. assume your link to your primary ISP goes down, you just switch
to a different set of locators (or disable the ones in the database that
refer to the failed link), and you don't have to flood the entire network
with a down status on that link (so that people can recompute paths).

How to handle people who are already communicating with you, when a link goes
out, is harder; I have a long list of ideas, but this is too long already.

But doing a push instead of / as well as a pull is definitely something to
consider.

     Noel

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

---

From: John Leslie <[email-masked]>
Date: Fri, 10 Nov 2006 19:40:58 -0500

Much though I dislike delving into details too early...

Noel Chiappa <[email-masked]> wrote:
> ... you're basically proposing to use the DNS as the mapping database.
> That way we don't have to design, build or deploy it, it's already
> there.

   We shouldn't think of it as the "only" database, though it might be
the "authoritative" database.

> That's perfectly feasible, but 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".

> ... Keith Moore would go totally non-linear...

   Perhaps that needs to happen, but not (IMHO) now. That's an
engineering issue -- the data could be maintained in DNS but queried
through an entirely different mechanism.

> ... sorry, 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; and 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'd also want to make sure we aren't getting in any dependency loop
> issues (e.g. on cold-boot after the next big regional power failure,
> A needs B to be up before it can restart, and B needs A to be up).

   A very good question!

> If so, a separate database might make it easier to solve any such
> issues.

   Reasonable... I'm guessing that a number of endpoints would need to
retain input==output mapping "forever". There's certainly no reason
we couldn't have local copies of a small database (like /etc/hosts).

> Anyway, I wonder if you're not falling into "this problem is easy
> if I give the hard part to someone else" syndrome.

   Often that is the _only_ way to "solve" a problem...

> (The classic example of this is that lots of people think
> multi-homing via PI is easy, because it gives the problem to the
> routing. NOT!)

   Agreed -- multi-homing via PI, at best, "tends to" break routing.
Folks worth considering _don't_ think that makes it "easy" -- it's
just the only plausible option they see.

> I wonder if the DNS people won't go non-linear when you spring this
> on them...

   Then let's not "spring it on them" yet. We need to work up an
architecture, not wander in the weeds of implementing that architecture.

> information about the path to the aggregate.

   Reasonable -- but it strikes me as an optimization, thus engineering.

--
John Leslie <[email-masked]>

---

From: David Conrad <[email-masked]>
Date: Fri, 10 Nov 2006 18:15:18 -0800

Noel,

> try_and_forward(input_packet)" clause, except for local traffic),  

Assume you have a source edge (or first hop) device that implements  
what I described.  On the "inside", the network is numbered in  
"identifier" space.  On the outside, the network is numbered in  
"locator" space.  If the lookup for the destination fails, the device  
can either drop the packet on the floor, or it can try to forward the  
packet.  If it decides to forward the packet, there are a couple of  
options:

1) assume the destination identifier is actually a "legacy" IPv6  
address and throw it to the mercies of the existing routing system  
without any encapsulation.

2) do another lookup, this time for something like  
"d.e.s.t.i.d.p.r.e.f.source-isp.net." (a name managed by the ISP)  
which would return the locator endpoint of a device that would be at  
the "other side" of the source ISP (that is, to a peering or transit  
point where the source ISP would hand the packet off to another ISP),  
thus creating an intra-AS tunnel.  The transit ISP the packet is  
handed off to would have the same decision about dropping or  
forwarding to make.

(yes, kludge upon kludge... don't think I'm proud of coming up with  
stuff like this)

> issues
> up before it can restart, and B needs A to be up).

As long as the mapping database servers are numbered out of locator  
space, there would not be any dependency loops.

> on them,
> too, etc, etc, etc.

I'm not wedded to the DNS (despite the fact I've been involved (at a  
management level) in the development of 3 different DNS servers) --  
it's just easy for people to understand.  This might be an  
opportunity to come up with a better distributed lookup technology,  
one that addresses many of the warts that's found in the DNS, but I  
would worry about trying to do or change too much in too short a time.

Rgds,
-drc