RE: WG next steps

["Tony Li" <Tony.Li@procket.com>]

|   > All of this could be handled by a set of opaque handles 
|   to locators,
|   > without the direct interaction of the transport layer and the 
|   > locators.
|   
|   If you did this, wouldn't you degenerate into something 
|   resembling the DFZ
|   as it stands in IPv4.  Is what you are proposing is some 
|   kind of global ARP
|   system?  I had suggested something like this a few years 
|   back and it was
|   rejected pretty much on the the grounds that a global cloud 
|   just may not scale.
|   
|   Perhaps I just misunderstand.  There have been so many 
|   ideas and opinions
|   floating around that it's hard to keep track of them all.


No, what I'm proposing is just good software engineering
practice between the transport layer and the network
layer in the host implementation.

You're familiar with BSD sockets, right?  That gives an
application an opaque handle to a TCP connection.

Now do the same thing for locators, just one layer down.
Suppose the application wants to surf www.foo.com.  It
passes the hostname to TCP and requests a connection
to port 80.  It sets up a socket to do this.

TCP then resolves the hostname, which (in a stack
slightly different than BSD) would return a structure
that contained both the identifier and a list of 
current locators.  The locators themselves are opaque to
TCP.  Now, when TCP wants to send a segment,
it pushes the buffer, the pointer to the identifier
and one of the locator handles down into the network
layer.  This in turn formats the packet and shoves it
down to the next layer.

There shouldn't be anything controversial here.  This is
just basic software engineering.  Moreover, this is all
implementation detail, not architectural or even a 
required protocol.

Tony