This is an alternative to the critique of NOL which is in the RRG Report ID:
http://tools.ietf.org/html/draft-irtf-rrg-recommendation-04 and which was written by one of the NOL designers, Yangyang Wang on 2010-01-15: http://www.ietf.org/mail-archive/web/rrg/current/msg05658.html This is 1088 words. I will refine it with feedback from the designers and will include it in the forthcoming omnibus of RRG critiques which are not fully included in the final RRG report (draft-whittle-rrg- critiques). The proposal summary and PDF documentation is: http://www.ietf.org/mail-archive/web/rrg/current/msg05532.html The RRG Report ID does not currently mention the PDF files which are attached to the msg05532. I think it would be good to place them on a reasonably permanent site somewhere so references to these could be added to the RRG Report. I previously wrote that I thought NOL was a CEE architecture. I currently think it does not resemble either a CEE or CES architecture. I do not consider NOL to be a viable solution to the routing scaling problem. Nonetheless, it is part of the design process and uses a novel combination of techniques which have some advantages: no need to alter host stacks, or to introduce a new mapping system. - Robin NOL (Name Overlay) alternative critique --------------------------------------- NOL is attempt to solve, or contribute to the solution of, the routing scaling problems for both IPv4 and IPv6. NOL's NAT-like architecture and enhancements to applications resembles neither that of a Core-Edge Elimination (CEE) or Core-Edge Separation (CES) architecture. It appears to be inadequate as a solution on its own, and while it is intended to be able to be used with either a CES or CEE architecture, it is not clear what benefits NOL would bring to architectures of either types. NOL consists of two new elements and the use of the existing DNS in a manner which returns IP addresses different from the actual address of the host. This arrangement may cause difficulties for some applications unless they are modified to cope with this non-standard arrangement. The first type of element is the Name Transfer Relay (NTR), NTRs are router-like devices, or extra functionality in existing routers, which operate at the CE or PE location. NTRs perform a NAT-like function, and also operate as a query server by which a NOL-compatible application can request an address and port on which to send packets which will be translated and sent to a host in the end-user network (EUN). EUNs use PI global unicast addresses, but the routes covering these addresses are only propagated as far as the NTR. The NTR is said to "block" these prefixes from being known any further. Specifically, these EUN PI prefixes are not advertised individually in the DFZ - nor are they covered by a shorter prefix in the DFZ. Hosts in the NOL-using EUNs need not run NOL-compatible applications - unless these applications are required to initiate communications with other hosts in other NOL-using EUNs. Hosts inside the NOL-using EUN are only accessible to a host outside this EUN initiating communications if the initiating application is NOL-updated. NOL requires no changes to the IP stack, including the TCP and UDP layers. An NOL-upgraded application is one which has been rewritten to include functions of an NOL library - and this enables the application to communicate using the host stack's conventional TCP, UDP and IP functionality to hosts in NOL-using EUNs, behind NTRs. >From the point of view of an NOL-application outside the NOL-adopting EUN, if the NOL-adopting EUN has two or more NTRs, each on the link to a different ISP, then all the hosts in the NOL-adopting EUN can be multihomed for all communication sessions initiated by the external NOL-application. The NOL documentation does no appear to show two NOL-applications on different hosts in different NOL-adopting EUNs communicating, or multihoming - but this is presumably possible by the NTR of the host which initiates the session translating outgoing and returning packets by which this NOL-application requests an address and port on the NTR of the destination network. The most significant reason why NOL or any similar approach can't be considered as the best solution to the routing scaling problem is that unmodified applications running on hosts outside the NOL-adopting EUN cannot initiate sessions with hosts inside the EUN, irrespective of whether the applications which are intended to respond to the request are upgraded to NOL or not. There is a workaround of the NTR assigning an address from a PA prefix to each server inside a NOL-adopting EUN, so it can be reached from outside by conventional hosts via stateless address translation. However, this cannot provide multihoming. If this problem - and whatever problems arise from the DNS returning IP addresses different from those of the hosts themselves - could be ignored, there would still be significant scaling problems with the two methods NTRs can use for their NAT-like translation of packets in sessions initiated by NOL-upgraded applications. One approach is to use a relatively small number of IP addresses on the outside of the NTR, with various TCP and UDP port numbers, to NAT sessions to a larger number of hosts behind the NTR in the NOL-adopting network. Since each port on each outside-facing address can only be used for a single session, with a single internal host and port number using the same TCP, UDP (or perhaps SCTP?) session, there are scaling problems with the limitations of the number of ports and the state the NTR must maintain. These constraints and the general volume of traffic, may mandate the use of multiple NTRs, each handling a subset of the hosts and having a subset of the available outside facing IP addresses. This approach has the advantage of conserving the total usage of address space, probably resulting in a total usage of somewhat more global unicast address space than the space actually used by the EUN behind the NTR. The other approach is stateless address translation in both directions. This is conceptually and computationally easier, but it unsuitable for large-scale use with IPv4, since a multihomed /24 EUN would require each of its two or more NTRs to use a /24 of PA space from each NTR's ISP. Consequently, to multihome an EUN with 256 IPv4 addresses would require a total of 768 IPv4 addresses. While it is possible to imagine new protocols between two NOL-updated applications, an external NOL proxy so ordinary applications can initiate communications with applications on hosts in NOL-adopting networks, and perhaps some application of NOL to Mobility, all these potential benefits - and the multihoming which NOL can in principle provide - only apply for communications initiated in either direction between hosts in different NOL-adopting EUNs when both hosts are using NOL-upgraded applications. Therefore the same non-linear benefits to adoption relationships found in all CEE architectures also apply to NOL. Firstly, adopters only derive substantial benefits (portability, multihoming and inbound TE for all their communications) after all, or nearly all other hosts and their applications are upgraded to use NOL. Secondly, routing scaling benefits only occur to a significant degree when this occurs - near 100% adoption for all hosts on the Net - because until this ubiquitous level of adoption is achieved, EUNs with PI space need to retain it to support their portability, multihoming etc. with conventional applications running on hosts all over the world. These problems, in addition to the fundamental problems of NAT - problems with referrals, breaking of the end-to-end principle and NAT traversal in general - mean that Name Overlay and any design operating according to similar principles cannot be considered as the best solution to the routing scaling problem, since several CEE and CES architectures promise to provide portability, multihoming and inbound TE with fewer constraints. _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg