Hi,
Thanks, that's much closer. I removed the paragraph numbers and incorporated this. Is that ok? Thanks, Tony On 3/8/10 12:29 AM, "Yangyang Wang" <wyyst...@gmail.com> wrote: > 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
