Hi, Tony and Lixia Sorry. The following is the organized rebuttal for NOL proposal, and about 397 words. Is this format ok?
========================= 1) NOL resembles neither CEE or CES as a solution. With supporting application level session by name overlay, NOL can support some solution of style of CEE. NOL is closer to the way of CES, i.e., preventing PI prefixes of edge networks from entering into the upstream transit networks.This is done by NTR, like the ITR/ETRs in CES, but NOL has no need to define the clear boundary between core and edge networks. NOL is designed to try to provide end users or networks a service that faciliates the adoption of multihoming, multipath routing and traffic engineering by the indirect routing through NTRs, and, in the mean time, doesn't accelarate, or decrease, the growth of global routing table size. 2) Some problems are stated in the NOL critique. In the original NOL proposal document, DNS query for a host that is behind a NTR will induce the return of the actual IP addresses of the host and the address of the NTR. This arrangement might cause some difficulties for the legacy application due to the non-standard response request for DNS. To resolve this problem, we can make NOL service use a new namespace, and DNS not return NTR IP address for the legacy hosts. The names used for NOL is formatted like email addresses, such as "d...@domain.net". The mapping between "domain.net" and IP address of corresponding NTR will be registered in DNS. NOL layer understand the meaning of the name "d...@domain.net" , and it will send a query to DNS only for "domain.net". And then, DNS will return IP addresses of the corresponding NTRs. For the legacy applications, they will still use the traditional FQDN name and DNS will return the actual IP address of the host. However, if the host is behind a NTR, the legacy applications may be unable to access the host. 3) The stateless address translation or stateful address and port translation maybe cause a scaling problems for the limitiations of the number of table entries NTR must maintain. And the legacy applications can not initiate sessions with hosts inside the NOL-adopting EUN. However, these problems may not be the big barrier for the deployment of NOL or other similar approaches. Many NAT-like boxes and proxy and firewall devices are widely used at the Ingress/Egress points of Enterprise networks, campus networks or other stub EUNs.The hosts running as servers can be deployed outside NTRs or be assigned PA addresses in a NTR-adopting EUN. ----- Original Message ----- From: "Tony Li" <tony...@tony.li> To: "Yangyang Wang" <wyyst...@gmail.com> Cc: "Lixia Zhang" <li...@cs.ucla.edu> Sent: Monday, March 08, 2010 3:38 AM Subject: Re: [rrg] Rebuttal for NOL // Re: NOL (Name Overlay) alternative critique > > Hi, > > Thanks for your contribution, but this format makes it difficult for me to > incorporate into the document. If your intent was to submit this for > inclusion, could you please organize in a way that would be similar to the > document? > > Thanks, > Tony > > > > On 3/7/10 5:42 AM, "Yangyang Wang" <wyyst...@gmail.com> wrote: > >> Thanks Robin for your critique, which is helpful for us to review and improve >> the design of NOL. >> The rebuttal for NOL is stated in the following. >> >> ----- Original Message ----- >> From: "Robin Whittle" <r...@firstpr.com.au> >> To: "RRG" <rrg@irtf.org> >> Cc: "Yangyang Wang" <wyyst...@gmail.com> >> Sent: Thursday, February 18, 2010 6:02 PM >> Subject: NOL (Name Overlay) alternative critique >> >> >>> 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. >>> >> >> Yes. >> NOL resembles neither CEE or CES as a solution. With supporting >> application level session by name overlay, NOL can support some solution >> of style of CEE. NOL is closer to the way of CES, i.e., preventing PI >> prefixes of edge networks from entering into the upstream transit networks. >> This is done by NTR, like the ITR/ETRs in CES. However, NOL has no >> need to define the clear boundary between core and edge networks. And >> NOL is to pay more focus on the benefits for end users or content providers >> by facilitating the adoption of multipath routing, flexible routing path >> selection, >> ect. These incentives to wide depolyment of some solutions, in turn, >> benefit the impovement for Internet routing scalability. >> >>> 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. >>> >> >> Yes. >> This problem is not depicted correctly or detailedly. It can be resolved by >> using a new namespace for NOL. The names used for NOL is formatted like >> email addresses, such as "d...@domain.net". The "domain.net" and IP address >> of corresponding NTR will be registered in DNS. NOL layer understand the >> meaning of the name "d...@domain.net" , and it will send a query to DNS only >> for "domain.net". And then, DNS will return IP addresses of the corresponding >> NTRs. For the legacy applications, they will still use the traditional FQDN >> name >> and DNS will return the actual IP address of the host. However, if the host >> is >> behind a NTR, the legacy applications may be unable to access the host. >> >> >>> 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. >>> >> >> Yes. >> The stateless address translation or stateful address and port translation >> maybe >> cause a scaling problems for the limitiations of the number of table entries >> NTR >> must maintain. And the legacy applications can not initiate sessions with >> hosts >> inside the NOL-adopting EUN. However, these problems may not be the big >> barrier for the deployment of NOL or other similar approaches. Many NAT-like >> boxes and proxy and firewall devices are widely used at the Ingress/Egress >> points >> of Enterprise networks, campus networks or other stub EUNs.The hosts running >> as >> servers can be deployed outside NTRs or be assigned PA addresses in a >> NTR-adopting >> EUN. >> >> >>> 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. >>> >>> >> >> NOL is designed to try to provide end users or networks a service that >> faciliates >> the adoption of multihoming, multipath routing and traffic engineering by the >> indirect >> routing through NTRs, and, in the mean time, doesn't accelarate, or decrease, >> the >> growth of global routing table size. >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> http://www.irtf.org/mailman/listinfo/rrg > > _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
