Critique of NOL (name overlay service for Internet routing scalability) We proposed a solution called “Name overlay service for Internet routing
scalability”. In the following, we use the term "NOL" to refer to this proposal. Before the critique presented in the following, we claim that NOL can be used in core-edge elimination or core-edge separation schemes. It is similar to Name-based Socket in being based on the common basic ncept "Name". But NOL is different with others. It adds an overlay on today's TCP/IP. In some sense, the overlay layer is similar to the session layer of OSI model. Name overlay (NOL) service for scalable Internet routing http://www.ietf.org/mail-archive/web/rrg/current/msg05532.html the following is a critique of about 411 words. Expect for collaboration on more critiques for this proposal. ------------------------- 1. Applications on hosts need to be rebuilt based on name overlay library to be NOL-enabled. The legacy softwares that are not maintained any more will not contribute benefits for routing scalability in the core-edge elimination situation. In the core-edge separation scheme, a new gateway NTR (Name Transfer Relay) is deployed to prevent edge specific PI prefixes into transit core. It doesn’t impede the legacy ends behind the NTR to access the outside Internet, but the legacy ends cannot or is difficult to access the ends behind a NTR without the help of NOL. 2. In the scenario of core-edge elimination, the end site will assigned to multiple PA address space, which lead to renumbering troubles on switching to other upstream providers. Upgrading ends to support NOL doesn’t give any benefits to edge networks. It has little incentives to use NOL in the core-edge elimination, and the same to other .host-based ID/locator split proposals. I believe that the edge networks prefer PI address space to PA address space whether they are IPv4 or IPv6 networks. 3. In the scenario of core-edge separation, the additional gateway NTR is to prevent the specific prefixes from the edge networks, just like a NAT or the ITR/ETR of LISP. A NTR gateway is can be seen as an extension of NAT (Network Address Translation). Although NATs are deployed widely, upgrading them to support NOL extension or deploying additional new gateway NTRs at the edge networks are on a voluntary basis and have few economic incentives. 4. The stateful or stateless translating for each packet traversing a NTR will require the cost of the CPU and memory of NTRs, and increase forwarding delay. Thus, it is not appropriated to deploy NTRs at the high-level transit networks where aggregated traffic maybe cause the congestion at the NTRs. 5. In the scenario of core-edge separation, the requirement of multi-homing and inter-domain traffic engineering will make end sites accessible via multiple different NTRs. For the reliability, all of the association between multiple NTRs and the end site name will be kept in DNS, which may increase the load of DNS. 6. In the support for mobility, it is necessary for the DNS to update the corresponding name-NTR mapping records in time when an end system move from behind one NTR to other NTRs. The NOL-enabled end relies on NOL layer to keep the continuity of applications data transport, while the underlying TCP/UDP transport session would be broken when the IP address changed. -Yangyang
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
