[rrg] NOL Critique

"Yangyang Wang" <wyystars@gmail.com> Fri, 15 January 2010 09:05 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:mime-version:content-type :x-priority:x-msmail-priority:x-mailer:x-mimeole; b=fEHKO5Sb3gnZF/OXyrYGKKHnVovD6sKLoU58F9f34V7Tkw2upP9k9VdOHALy1uCw50 WxhuMvyBHjwHta+g/JqhNVAv8qf3v/sQ85TCP7C4rW6J/tFjNOrCEzg6ZVgudq7rACWf 099Z9FWBuBsIw5ot1n2eN+BeTWSYvRFaWrtys=
Message-ID: <72545933A3094A3EA474861539C5D6BF@wyystar>
From: Yangyang Wang <wyystars@gmail.com>
To: rrg@irtf.org
Date: Fri, 15 Jan 2010 17:05:49 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_058E_01CA9604.FC60AC30"
Subject: [rrg] NOL Critique
Precedence: list

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] NOL Critique Yangyang Wang
Re: [rrg] NOL Critique Tony Li