On Fri, 2010-01-15 at 09:00 -0500, Joel M. Halpern wrote:
> I could not find the actual critique in this message.  I found a 
> "signature.asc", but no other attachments, and the message body is as
shown.
> 
> Yours,
> Joel

That's because I forgot to attach the file :)

Sorry for that.
Here it is.


// Javier
Name-Based Sockets Critique

Name-based sockets contribution to the routing scalability problem is providing 
end hosts with a network interface which makes the end-host address (locator) 
agnostic. The name abstraction allows the hosts to use any type of locator, 
independent of format or provider. The projected result is that no provider 
independent addresses will be required for multi-homing and mobility solutions.

Deployment:
The main incentives and drivers are geared towards the development of new 
applications and in the slower migration of old applications to the new API. 
Also, not all applications can be ported to a FQDN dependent infrastructure, 
e.g. DNS functions. This hurdle can be overcome, and may not be a definite 
obstacle for the transition of a whole domain, but it needs to be taken into 
account when striving for mobility/multi-homing of an entire site. The 
transition of functions on individual hosts may be trivial, either through 
upgrades/changes to the OS or as linked libraries, however, upgraded 
applications require support from all interacting hosts. This can still happen 
incrementally, but it does require the server in a client/server application to 
maintain both an upgraded as well as a non-upgraded function during the 
transition phase.

Edge-networks:
Name-based sockets provide a new networking-API which is not necessarily 
backwards compatible (there is a track that suggests allowing IPs as names). 
This puts in question to which extent a whole edge-site might accept PA 
addresses. Name-based sockets may make an individual client agnostic to the 
networking medium, be it PA/PI IP-addresses or in a the future an entierly 
different networking medium. However, an entire edge-network, with internal and 
external services will not be able to make a complete transition in the near 
future. In short, new services may be implemented using name-based sockets, old 
services may be ported, but for a complete edge-network transition backwards 
compatibility may be a hinder.


Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to