Subject: RE: where the indirection layer belongs

From: "Yuri Ismailov (KI/EAB)" <[email-masked]>
Date: Mon, 1 Sep 2003 11:07:01 +0200

>No matter where the stabilization layer(s) live, using DNS as a
>means to map from identity to locations simply won't work.  It might be
>good enough for initial connection (assuming that if a service exists on
>multiple hosts, any of them will do), but it's not good enough for
>re-establishing an already-open connection, because you might get a
>different host the next time.

This is exactly the point!

>> But the real question here is: does this new "thing" have to be a 
>> layer? 

>It depends on which "thing" you are talking about.  For the L3-L4 thing,
>it's either a new layer or a change to an existing layer.  If you
>have both the L4-L7 thing and the L3-L4 thing, the former is either a
>new layer or (my personal opinion) a new API that knowledgable apps
>call explicitly.

If L4-L7 thing is an API on top of the "socket" in its current form, then I believe that all limitations are still there.
This is implemented and shown to be the fact.

/Yuri

---

From: "Yuri Ismailov (KI/EAB)" <[email-masked]>
Date: Tue, 2 Sep 2003 16:16:09 +0200

I completely agree with that and support the whole thing.
The discussion shows that there are quite many opinions and seems that everybody has in mind some problem, which can be solved by new layer and new name space.
The forum is needed in order to put those ideas together and find out whether all (or at least some) of them have the same root.

/Yuri

-----Original Message-----
From: Robert Honore [mailto:[email-masked]]
Sent: Friday, August 29, 2003 8:40 PM
To: Yuri Ismailov (KI/EAB)
Cc: 'Tony Hain'; 'Keith Moore'; [email-masked]; [email-masked]
Subject: Re: where the indirection layer belongs

Dear Folks,

Regarding this discussion about an indirection layer, I am thinking we 
really should propose the formation of some forum for discussion of 
these issues.  It does not seem to fit cleanly into the IPv6 working 
group, and out here in no-man's-land, I don't think it is getting the 
kind of attention it needs.

I had already made my position clear.  We need something.  Call it an 
indirection layer or a stabilisation layer or whatever you want, but we 
need a forum where we can specify the problem we are trying to solve and 
to consider the possible solutions for it.  Does anybody agree?

Yours sincerely,
Robert Honore.

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 2 Sep 2003 11:37:55 -0400

> From: Robert Honore <[email-masked]>

    > I agree that the "bug" in this picture here is that nodes can have
    > multiple addresses, some of which work and some of which don't work in
    > different circumstances. It really should be that an address which is
    > advertised for a node should be valid for communication with that node
    > under all circumstances.

If by "address" you mean "the names the routing system uses to keep track of
where things are", this contention of yours is not really feasible. What
you're basically saying is "the routing system has to be able to get to *any*
address, no matter what failures happen", and that's not so simple.

The simplest approach to doing so would basically mean injecting a route for
every separate physical network into the global routing table - because
depending on exactly which component or components failed (thereby making the
network unreachable as part of its original addressing aggregate), the
alternative path to it might lead almost anywhere in the network - hence the
requirement to circulate knowledge of that destination globally.

(Actually, it's even worse than "every separate physical network", because if
you have a physical network which can be broken into two separate working
parts, each part would need a separate, globally circulating routing table
entry.)

The obvious second thought is "Oh, but we don't need to put these things in
the routing table - when an addressing aggregate partitions, we can construct
a tunnel to the 'lost' part." The problem with this idea is "how do you find
where the lost part is, and how to get to it"? The simplest answer is - you
guessed it - to inject that destination into the routing.

Again you have two choices - i) do it once failure happens, which first means
you have to detect such failures, and which also means that until the global
routing stabilizes, that destination is unreachable (as well as a host of
other problems I touch on below), or ii) you do it in advance, which is the
preceeding solution.

So an alternative to that would instead be for the partitioned section to try
and make contact with the large aggregate it was partitioned from - after
signing up with some local "care of" agent, one which does still have a
"working" address and will act on its behalf, and tunnelling its traffic
through that entity.

But now you get into all sorts of wonderfully complex failure modes (as I
alluded to above). E.g. how do you decide which of the two parts is the "main"
part of the partitioned addressing entity, i.e. the one that gets to keep
advertising the entire aggregate? And what do you do if the "main" part of the
aggregate was completely disconnected from the network, so it can't act on
behalf of the orphaned piece? And how do you tell the difference between an
aggregate piece which has been disconnected by a failure, and an aggregate
which is a "hole" punched when someone moved and took their addresses with
them (which should be advertised normally, globally - although no doubt some
would say that having to use a tunnel through a "care of" agent would be
condign treatment for such people :-)?

And I won't even get into the issue of how to make this all robust and
secure; I can think of the most wonderful attacks in which I uses these
mechanisms to divert traffic.

So all of sudden the "advertise all the pieces all the time" looks a lot
simpler - until you realize that it won't scale, and is impossible.

So it's nice to say "an address .. should be valid for communication .. under
all circumstances", but it you actually try and think about how you'd make
that work, it's not so simple.

	Noel