Subject: Re: [arch-d] Major practical decision

From: [email-masked] (Noel Chiappa)
Date: Sat, 9 Dec 2006 10:56:47 -0500 (EST)

> From: "Mark Handley" <[email-masked]>

    >> So, what's it to be: jack-up (i.e. insertion of a new internetworking
    >> layer), or new end-end names (i.e. insertion of a new end-end naming
    >> layer)?

    > I'm not sure these are the only possibilities.
    > We've been playing with the idea of using edge-to-edge tunnelling to
    > construct an infrastructure for defending against DDoS attacks.
    > ..
    > this sort of edge-to-edge tunnelling doesn't require any end-host
    > changes .. and it should be incrementally deployable.
    > In any event, it's an example of an architecture that isn't quite
    > either of the two you listed above.

I think Pekka's recent reply (9 Dec 2006 15:57:37 +0200) says roughly what I
would have said (but a great deal more elegantly - I wouldn't have thought to
decompose it into separate axes, naming and implementation).

I don't have time to carefully read your paper (too much email here I need to
answer :-), but from the 10-minute look I took, at a high level it seems to
be more or less exactly a "jack-up" scheme (which is my term for a scheme in
which a new set of names are added at a layer below the existing
internetworking layer, and those new names are mostly what is used for
forwarding traffic). You have two logically separate namespaces, and map from
one to the other, and in the middle of the network you wrap packets with
names from one namespace inside packets with names from another namespace.
(You call it "tunneling", but to me tunneling implies a point-point thing,
with the creation of some state at each end of the tunnel, and this scheme
doesn't really have that. It's just a straight wrapping.)

This exchange did provoke the following analysis, which all might find
useful. Here's the key point:

*** Architecturally, separation of location and identity necessarily implies
*** creation of a second namespace - one is used for location, and one for
*** identity.

(The namespace might, confusingly, have the same syntax as the first [as in
MIP6, SHIM6, and your scheme], and, yet more confusingly, even be allocated
via the same delegation hierarchy. However, it remains that case that one
cannot use a name from one space in exactly the same way that one uses a name
from the other space, so they are indeed separate.)

So, if one accepts that we need to separate location and identity, one is
basically also accepting that we need a second namespace. (If someone thinks
they can have one without the other, try thinking about it some more! :-)

So the only question, architecturally speaking, is "do the new names take
over the location role, or the identity role"? In designs like HIP, the new
names take over the identity. In all jack-up schemes, the new names (mostly)
take over the location role.

(I say "mostly" because in most jack-up schemes there is usually a vestigial
"location" role left with the original names. In other words, because the goal
is usually to avoid modifying hosts, at some point the packet is unwrapped,
and once that happens, the original internetworking "address", which is now
mostly "identity", resumes its role of identifying an interface, and where
that interface is. Any forwarding decisions that are taken based on it are
only in a scope fairly local to the destination, though.)

So I would claim that, at an architectural level, the question is indeed
"jack-up (i.e. insertion of a new internetworking layer), or new end-end
names (i.e. insertion of a new end-end naming layer)". There are many
possible implementation variants within each, of course, but fundamentally
one of these two things is happening.

	Noel

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