I've gotten feedback from Christian Vogt. He spotted a few nasty bugs in my text. Thank you Christian. (I was wrongfully claiming non-backwards compatibility).
Here's the revised version. Thank you // Javier Ubillos On Tue, 2010-01-19 at 12:46 +0100, Javier Ubillos wrote: > I have updated the critique. > > Changes: > * Rephrasing - clarifications > * Clarified that transtion to 100% PA-addresses is unlikeley. Some use > of PI-addresses may be motivated. The contribution is the increased > motivation to move to PA-addresses as provider independence relies less > and less on actual PI-addressing. > * Name-based sockets _are_ backwards compatible. > > If any one wants to contribute, I'll happily accept additions/changes > and merge them. > > // Javier > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg
Name-Based Sockets Critique Name-based sockets contribution to the routing scalability problem is to decrease the reliance on PI addresses, allowing a greater use of PA addresses, and thus a less fragmented routing table. It provides end hosts with an API which makes the applications address-agnostic. The name abstraction allows the hosts to use any type of locator, independent of format or provider. This increases the motivation and usability of PA addresses. Some applications, in particular bootstrapping applications, may still require hard coded IP addresses, and as such will still motivate the use of PI addresses. Deployment: The main incentives and drivers are geared towards the transition of applications to the name-based sockets. Adoption by applications will be driven by benefits in terms of reduced application development cost. Legacy applications are expected to migrate to the new API in a slower pace, as the name-based sockets are backwards compatible, this can happen in an per-host fashion. Also, not all applications can be ported to a FQDN dependent infrastructure, e.g. DNS functions. This hurdle is manageable, 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. This can still happen incrementally and disjoint, as compatibility is not affected by the use of name-based sockets. Edge-networks: The name-based sockets rely on the transition of individual applications, the name-based sockets are backwards compatible, hence it does not require bilateral upgrades. This does allow each host to migrate its applications independently. 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 entirely 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. Hence, even if a substantial fraction of the hosts in an edge-network use name-based sockets, PI addresses may still be required by the edge-network. In short, new services may be implemented using name-based sockets, old services may be ported. Name-based sockets provide an increased motivation to move to PA-addresses as actual provider independence relies less and less on PI-addressing.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
