Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5560F3A67A1 for ; Mon, 14 Dec 2009 14:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[AWL=-1.495, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkw2CZBWH+bW for ; Mon, 14 Dec 2009 14:42:15 -0800 (PST) Received: from omr-d33.mx.aol.com (omr-d33.mx.aol.com [205.188.249.131]) by core3.amsl.com (Postfix) with ESMTP id 1AE463A6849 for ; Mon, 14 Dec 2009 14:42:14 -0800 (PST) Received: from imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by omr-d33.mx.aol.com (8.14.1/8.14.1) with ESMTP id nBEMeUJG030157; Mon, 14 Dec 2009 17:40:30 -0500 Received: from HeinerHummel@aol.com by imo-ma03.mx.aol.com (mail_out_v42.5.) id f.c3f.61423fbf (34898); Mon, 14 Dec 2009 17:40:25 -0500 (EST) Received: from smtprly-mb02.mx.aol.com (smtprly-mb02.mx.aol.com [64.12.207.149]) by cia-da01.mx.aol.com (v126.13) with ESMTP id MAILCIADA017-5c664b26bed5a4; Mon, 14 Dec 2009 17:40:25 -0500 Received: from magic-m15.mail.aol.com (magic-m15.mail.aol.com [172.21.145.217]) by smtprly-mb02.mx.aol.com (v126.13) with ESMTP id MAILSMTPRLYMB024-5c664b26bed5a4; Mon, 14 Dec 2009 17:40:21 -0500 From: heinerhummel@aol.com Message-ID: <4143.4f2ace14.385818d4@aol.com> Date: Mon, 14 Dec 2009 17:40:20 EST To: charriesun@gmail.com, rrg@irtf.org, lixia@cs.ucla.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_4143.4f2ace14.385818d4_boundary" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-ORIG-IP: 95.91.134.31 X-AOL-IP: 172.21.145.217 X-AOL-SENDER: HeinerHummel@aol.com Subject: Re: [rrg] Fwd: Propose a new proposal X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 22:42:16 -0000 --part1_4143.4f2ace14.385818d4_boundary Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Sun Letong, your proposal shows that the strong belief in mapping doesn't crumble at= =20 all. Speaking in analogy once more, I have tried - in vain - to convince= =20 people that a routable namespace a la Manhattan, New York is better than= using=20 a non-routable namespace where you depend on mapping. In New York you can= =20 progress towards your destination without asking people at each junction= of=20 avenue and street. =20 Besides that the scalability problem could indeed become a non-issue (for= =20 ever), it strikes me that the inherent capabilities of geographical=20 coordinates-based routing wrt IP mobility aren't appreciated neither by= Nokia=20 nor Ericsson folks. =20 Good luck for your proposal =20 Heiner =20 =20 =20 =20 In einer eMail vom 13.12.2009 02:51:09 Westeurop=E4ische Normalzeit schrei= bt =20 charriesun@gmail.com: =20 Hello Lixia and all: I'm a student in Tsinghua University, BeiJing and make bold to submit a= =20 proposal for the current scalability problems of the Internet. This is ab= out=20 a layered mapping system (perhaps we can call it "LMS") to store and look= up=20 mapping information of edge addresses and core addresses in the separatio= n=20 base. It is similar to LISP+ALT while differs from it in a number of ways= .=20 I made a elementary summary and introduced the design in another document= .=20 =20 Summary is here: =20 (file:///C:%5CDOCUME%7E1%5Ccscg%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip= _filelist.xml)=20 _http://docs.google.com/Doc?docid=3D0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&= hl=3Den_=20 (http://docs.google.com/Doc?docid=3D0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&= hl=3Den)=20 Details: =20 (file:///C:%5CDOCUME%7E1%5Ccscg%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip= _filelist.xml)=20 _http://docs.google.com/fileview?id=3D0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM= 0LTg5ZjktNmFkYzBhNWJhMWEy&hl=3Den_=20 (http://docs.google.com/fileview?id=3D0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM= 0LTg5ZjktNmFkYzBhNWJhM WEy&hl=3Den)=20 My key idea is similar to the LISP+ALT in adopting a hierarchical mapping= =20 system to guarantee scalability. Initially i thought my proposal is just= a=20 specification of ALT, but later i realize there're some differences. I als= o=20 made a comment on today's proposals and my devised two-stage cache on the= ITR=20 can work for many proposals to enhance the performance. My experiements= =20 haven't added to it but prelimenary results are satisfied. Could you do= me a=20 favor to add this proposal to the rrg-wiki Active Proposal list? You may= =20 have a look at it and discard it if it's not novel at all. I apologize if= it=20 wastes rrg's time. =20 Best wishes, Sun Letong _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg --part1_4143.4f2ace14.385818d4_boundary Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <= FONT id=3Drole_document color=3D#000000 size=3D2 face=3DArial>
Sun Letong,
your proposal shows that the strong belief in mapping doesn't crumble= at=20 all. Speaking in analogy once more, I have tried - in vain - to convince= people=20 that a routable namespace a la Manhattan, New York is better than using a= =20 non-routable namespace where you depend on mapping. In New York you can pr= ogress=20 towards your destination without asking people at each junction of avenue= and=20 street.
 
Besides that the scalability problem could indeed become a non-issue= (for=20 ever), it strikes me that    the inherent capabilities= of=20 geographical coordinates-based routing wrt IP mobility aren't appreciated= =20 neither by Nokia nor Ericsson folks.
 
Good luck for your proposal
 
Heiner
 
 
 
 
In einer eMail vom 13.12.2009 02:51:09 Westeurop=E4ische Normalzeit= schreibt=20 charriesun@gmail.com:

Hello Lixia and all:

    I'm a student in Tsinghua University, BeiJing and= make=20 bold to submit a proposal for the current scalability problems of the=20 Internet. This is about a layered mapping system (perhaps we can call it= =20 "LMS") to store and lookup mapping information of edge addresses and cor= e=20 addresses in the separation base. It is similar to LISP+ALT while differ= s from=20 it in a number of ways. I made a elementary summary and introduced the= design=20 in another document.

Summary is here: ht= tp://docs.google.com/Doc?docid=3D0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&= ;hl=3Den
Details:=20 http://docs.google.com/= fileview?id=3D0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM0LTg5ZjktNmFkYzBhNWJhMWE= y&hl=3Den

My key idea is similar t= o the LISP+ALT in adopting a hierarchical&nb= sp;mapping system to guarantee scalability. Initi= ally i thought my proposal is just a&nb= sp;specification of ALT, but later i realize=  there're some differences. I also made = ;a comment on=20 today's proposals and my devised two-stage = ;cache on the ITR can work for many&nbs= p;proposals to enhance the performance.=20 My experiements haven't added to it but prelimenary results are satisfie= d.=20 Could you do me a favor to add this proposal to the rrg-wiki Active Prop= osal=20 list? You may have a look at it and discard it if it's not novel at all.= I=20 apologize if it wastes rrg's time. 


Best wishes,
Sun Letong



_______________________________________________
= rrg=20 mailing=20 list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
 
 --part1_4143.4f2ace14.385818d4_boundary--