Subject: RE: Solving the right problems ...

From: [email-masked]
Date: Wed, 27 Aug 2003 10:37:34 +0300

Tony,

A very quick question about your idea.  Does this layer have a 
protocol / interface to other elements on the network? Or are
you proposing something more like an abstract API?

thanks,
John

> -----Original Message-----
> From: ext Tony Hain [mailto:[email-masked]]
> Sent: 26 August, 2003 21:12
> To: 'Robert Honore'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Solving the right problems ...
> 
> 
> Robert Honore wrote:
> > Perhaps this proposal really requires another working group or 
> > something.  
> 
> To be clear, I was not recommending where the work get done, that is why it
> was sent to the IETF list. I only cc'd the IPv6 list because it ties into
> the recent discussion. In fact it is not clear to me where this work belongs
> because the IETF area structure is very focused around the current layers.
> It is also not clear that a new area is required to create a new layer, but
> maybe that would help focus work in both defining how such a layer would
> interact both up and down, as well as name space and interaction protocols
> along the lines of HIP/DHT/... 
> 
> The only thing that was clear to me was that the efforts to change the
> behavior of lower layers only makes them more complex while creating
> unintended side effects. At the same time, an optional layer between app &
> transport could provide the consistency that some apps require, without
> changing the widely deployed and well refined lower layers.
> 
> Tony
> 
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
>

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Aug 2003 09:28:27 -0700

> you proposing something more like an abstract API?

Simple question, complex answer ... It really depends on where you are
looking at it from, and how the name space discussion gets resolved. As I
was writing that, it occurred to me that from the app perspective what you
want is to provide most of the characteristics of the transport API, making
it somewhat transparent but the layer is really a manager substituting
application name space identifiers for topology references, etc. At the same
time there may need to be some protocol between the layer peers and/or
infrastructure services to establish identities, along the lines of
HIP/DHT/enhanced DNS/etc. As I see it, the hard work is getting this part
done well.

The thought was that the protocol parts of TCP/UDP/SCTP/... do what they do
as directed from above, and do that efficiently. In the abstract, there is
no reason that the entity above them can't deal with changing connection
state, or topology attachment points. In the current environment though, we
have apps parked in that spot, and we agree that dealing with changes is too
much complexity to ask of apps in general. 

Historically, since we have apps parked in that spot, there has been an
insistence that all of the topology complexity get resolved in the lower
layers. Pushing complexity into the lower layers makes them less efficient,
and will unnecessarily break many of the operational assumptions that exist.
Providing an optional stabilization layer above transport allows endpoints
to come and go at different points in the topology, while the application
remains oblivious to the changes.

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Aug 2003 13:21:35 -0400

> Historically, since we have apps parked in that spot, there has been
> an insistence that all of the topology complexity get resolved in the
> lower layers.

uh, no.  the design is for a clean separation of function between the
layers that know about network topology and the hosts, which aren't
supposed to need to know about such things.  that separation of function
is still highly desirable.  

what has changed is that we're now expecting a layer 3 that was designed
for relatively stable networks of wired hosts to suddenly accomodate
mobile and nomadic hosts and networks, without significant change.

you can't solve the right problems without first recognizing what they
are.

---

From: Mika Liljeberg <[email-masked]>
Date: Wed, 27 Aug 2003 21:40:26 +0300

> mobile and nomadic hosts and networks, without significant change.

TCP/IP was designed for such networks. What has changed is that we no
longer have provider indepdendent addressing. Which means routing
protocols can no longer do the job.

	MikaL

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 27 Aug 2003 20:51:14 +0200

-----BEGIN PGP SIGNED MESSAGE-----

> protocols can no longer do the job.

Routing protocols can keep doing a perfect job as they are.
An ISP has a TLA in IPv6 and it provides routability from and
to the address space in this TLA. That is the routing part:
sending a packet from A to B. Just like your postal address.

The Identifier part goes on top of that making the packet
have a signature, saying "this packet is from me".

Then there is a third part in the process which allows
a single identity to have multiple Routing IP's: postal addresses.
Just like one can send you a postal packet to your office and
to your work address, both with your name on it which
will make sure that it arrives at you.

Thus we don't need PI, which is a stupid pain on the
routing tables. We need Identifiers.

Greets,
 Jeroen