From tony.li@tony.li Thu Jan 9 01:12:24 2014 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576C11AE07B for ; Thu, 9 Jan 2014 01:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8lxzXy6-JZB for ; Thu, 9 Jan 2014 01:12:22 -0800 (PST) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:40]) by ietfa.amsl.com (Postfix) with ESMTP id A30FE1AE042 for ; Thu, 9 Jan 2014 01:12:22 -0800 (PST) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta04.emeryville.ca.mail.comcast.net with comcast id BlCD1n0011Y3wxoA4lCDdd; Thu, 09 Jan 2014 09:12:13 +0000 Received: from [192.168.2.5] ([69.181.139.254]) by omta15.emeryville.ca.mail.comcast.net with comcast id BlCB1n00E5VX96D8blCCbD; Thu, 09 Jan 2014 09:12:12 +0000 From: Tony Li Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 9 Jan 2014 01:12:11 -0800 To: rrg@irtf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389258733; bh=Zo3ydQLBslRr974AM447Yi3CqCvcehD0vMvmpFxmryM=; h=Received:Received:From:Content-Type:Subject:Message-Id:Date:To: Mime-Version; b=WlitNf/zp5Vmp+lht5+EdjXTqz8vz0XpMBNEo/bMxJPrFg8exBJhIRQgaj9VVsdo/ x2H17+CnTQwcD3puoz2mtiOGqjh3XylTGcN+ZrTPGiKQcxy1w+il7m94FG3ayHJWGB 85GMLcM/mIwrq1Rdk88AiaOHONreixh1JvZiFtIkPHq3GqMUIo+CaVMaYHgAlLsJZW NRmI/pLVOLYfK0wDQ+ZcUpm70yXXOQNPonkLOwstpltUicSS7WPvzkc7V9OJj6gVAf oJz3ymOv4kYdOup7pscw6XV1iPNK3B8G/LQ9n7dyzygmRUbFBuwgx+bolig27xkJ7T c0yNPOD3MiV2w== Subject: [rrg] London X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 09:12:24 -0000 Hi all, We are still looking for excellent papers for our workshop in London. = We really need your help in collecting these. If you know of = interesting research, could you please contact the authors and ask if = they would be willing to present in London? It's coming very soon=85 Thanks, Tony From heinerhummel@aol.com Sat Jan 11 12:24:53 2014 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0E51ADFD1 for ; Sat, 11 Jan 2014 12:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q96mowPZ48i for ; Sat, 11 Jan 2014 12:24:51 -0800 (PST) Received: from omr-m01.mx.aol.com (omr-m01.mx.aol.com [64.12.143.75]) by ietfa.amsl.com (Postfix) with ESMTP id CBADE1ADFCD for ; Sat, 11 Jan 2014 12:24:50 -0800 (PST) Received: from mtaout-mab02.mx.aol.com (mtaout-mab02.mx.aol.com [172.26.249.82]) by omr-m01.mx.aol.com (Outbound Mail Relay) with ESMTP id 49F17701BFC45; Sat, 11 Jan 2014 15:24:40 -0500 (EST) Received: from [192.168.2.106] (178-26-195-50-dynip.superkabel.de [178.26.195.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mab02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id A47D638000096; Sat, 11 Jan 2014 15:24:39 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Heiner Hummel In-Reply-To: Date: Sat, 11 Jan 2014 21:24:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <69AE8596-8E77-4CC9-B7DA-5F0105D8E6E9@aol.com> References: To: Tony Li X-Mailer: Apple Mail (2.1510) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1389471880; bh=MsRG3fnWnXCQrPZmexLOkRYtmxHb54f9/F2RGjhsRhk=; h=From:To:Subject:Message-Id:Date:Mime-Version:Content-Type; b=aPrRBgDD3YQ+rCxBeY+dPbVDC/AbdHjPh48hBdCYRVINEZYT8ehYGufOTsj4otVj5 +DEpc7LHbTBR8yQeO0l/Sr4v5JnMr0+ncAJCJME4pS4nn0mYaSfUhQFq5/d+OCyMLJ QrHJQcXywQkdf4BlYZ+drfWnYjl1udc29hvK0r4s= x-aol-sid: 3039ac1af95252d1a8877d9f X-AOL-IP: 178.26.195.50 Cc: rrg@irtf.org Subject: Re: [rrg] London X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 20:24:53 -0000 Tony, Given that the IESG doesn't care about IPv4 anymore, what kind of papers = are you looking for? IPv6 papers ? IPv7 papers, based on WHAT ? For anyone it would be easier to outline a routing architecture while 16 = octets are available instead of 4. But IPv6 is grounded from the start. = Not even the fact that IPv4 runs out of addresses will help to unleash = IPv6. Combined with NAT, IPv4 won't effectively have a deletion problem. Not = for the next thousand years. Technologically NAT is a sin fall, it hampers internet services = enormously. But this is true with IPv6 as well. So what! Backward compatibility and incremental deployability should be the two = MUSTs for any architecture, no matter who proposes it. IPv6 isn't = backward compatible due to the dual stack issue - right? or is there any = way around? What is expected from any new architecture? To be backward compatible = with IPv4 ( I would think so), to be backward compatible with IPv6 (I = wouldn't think so)? So what is expected? And of course what do you expect to be solved, respectively to be = enabled at least ? ---- Another Proposal: This group should come up with ideas about what a = networking layer should do/support/enable WITHOUT being restricted by = any existing technical solution. Two examples: 1): Prefix building per se is not a service. It is only a = subdue instrument to cope with problems of a minor design. 2): State-less multicast would enable an enormous progress ( Imagine = TV-broadcast to billions of spectators). But this is disabled due to the = crazy belief that there is only one way a FIB can be designed (namely = as the existing FIB looks like) and because a Multicast-FIB cannot reasonable be cast like the existing = Unicast-FIB there cannot/must not be state-less multicast. Period. Heiner =20 Am 09.01.2014 um 10:12 schrieb Tony Li : >=20 > Hi all, >=20 > We are still looking for excellent papers for our workshop in London. = We really need your help in collecting these. If you know of = interesting research, could you please contact the authors and ask if = they would be willing to present in London? It's coming very soon=85 >=20 > Thanks, > Tony >=20 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From lars@netapp.com Sat Jan 11 23:39:58 2014 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557F61ADF51 for ; Sat, 11 Jan 2014 23:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVcO_VTI8EuA for ; Sat, 11 Jan 2014 23:39:56 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 71E1B1ADBD2 for ; Sat, 11 Jan 2014 23:39:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,646,1384329600"; d="asc'?scan'208";a="95581556" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 11 Jan 2014 23:39:45 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Sat, 11 Jan 2014 23:39:47 -0800 From: "Eggert, Lars" To: Heiner Hummel Thread-Topic: [rrg] London Thread-Index: AQHPDRsNFL/rnM9bbk2HL3xGGHUfQZqAgjIAgAC8nQA= Date: Sun, 12 Jan 2014 07:39:45 +0000 Message-ID: <5BB75319-9204-41F1-B869-8D6F77E39190@netapp.com> References: <69AE8596-8E77-4CC9-B7DA-5F0105D8E6E9@aol.com> In-Reply-To: <69AE8596-8E77-4CC9-B7DA-5F0105D8E6E9@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: multipart/signed; boundary="Apple-Mail=_F1D29358-B4FD-4827-A499-EEFED565E068"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: IRTF Routing RG Subject: Re: [rrg] London X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 07:39:58 -0000 --Apple-Mail=_F1D29358-B4FD-4827-A499-EEFED565E068 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On 2014-1-11, at 21:24, Heiner Hummel wrote: > Given that the IESG doesn't care about IPv4 anymore so even if that were true, what the IESG cares for should have little = impact on what an IRTF research group is looking into. I thought Tony's email was spot-on. If the RRG wants to remain = chartered, it needs to become active again and identify some topics that = it wants to investigate. Looking at what's been published by academics = in the recent past seems a useful exercise in order to find some of = those topics. And the group needs a core set of participants that are willing to put = in the energy to make some successful meetings happen, by re-energizing = the broader routing community and by inviting folks that have = interesting things to present to show up to do so. Lars --Apple-Mail=_F1D29358-B4FD-4827-A499-EEFED565E068 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUtJGvtZcnpRveo1xAQJUZgQAh17b+wUpHMd7VNliJ+WPIjzecnztr5gr pyJmAzps8CLl1SFqGH2FfsDD1LIxelCFHR7NyAnH3kMqY+jgbKvmw7ywDvy3FRAH WDpos7Ana0LA1PO8ocpGwEFIu6Dvb9U+1mzkqvDbpviOhqmjFsWh3PrY/yttm0P9 f/eSCkzn1Ng= =qE0+ -----END PGP SIGNATURE----- --Apple-Mail=_F1D29358-B4FD-4827-A499-EEFED565E068-- From heinerhummel@aol.com Sun Jan 12 09:41:07 2014 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC7D1ADFC3 for ; Sun, 12 Jan 2014 09:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78EeY0yYr_Fm for ; Sun, 12 Jan 2014 09:41:06 -0800 (PST) Received: from omr-m04.mx.aol.com (omr-m04.mx.aol.com [64.12.143.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2142D1ADFA0 for ; Sun, 12 Jan 2014 09:41:06 -0800 (PST) Received: from mtaomg-mcc01.mx.aol.com (mtaomg-mcc01.mx.aol.com [172.26.253.85]) by omr-m04.mx.aol.com (Outbound Mail Relay) with ESMTP id 46A8D70001D57; Sun, 12 Jan 2014 12:40:55 -0500 (EST) Received: from core-dqa003a.r1000.mail.aol.com (core-dqa003.r1000.mail.aol.com [172.29.211.201]) by mtaomg-mcc01.mx.aol.com (OMAG/Core Interface) with ESMTP id CC980380000C9; Sun, 12 Jan 2014 12:40:54 -0500 (EST) To: lars@netapp.com X-MB-Message-Source: WebUI Received: from 178.26.195.50 by webmail-m276.sysops.aol.com (64.12.145.243) with HTTP (WebMailUI); Sun, 12 Jan 2014 12:40:54 -0500 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D0DDD493FF397D_17E4_1270F0_webmail-m276.sysops.aol.com" X-Mailer: Webmail 38252-STANDARD Message-Id: <8D0DDD493F352A2-17E4-54879@webmail-m276.sysops.aol.com> X-Originating-IP: [178.26.195.50] Date: Sun, 12 Jan 2014 12:40:54 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1389548455; bh=RV4S/dzZENGzv7YFDbfCsLvCMYi1eJbxvfCnjuX5uP8=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=QW4Nrc9qz6Q/wauAVMephB1MRYFfgUyJr0d+WEUnvFyXvWhiJ1PWKHSnSsdNyVfF2 b0g7B6HxsvCdYIpX5pyuYN6a/OYd8uGJBrq/3KuX388I1DDSgehsLY3OdkfmYAPiQE PBXqHcjPMfAReJx78Z6RBalWBxOVUwHYB9FSIKCo= x-aol-sid: 3039ac1afd5552d2d3a65d47 Cc: rrg@irtf.org Subject: Re: [rrg] London X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 17:41:08 -0000 This is a multi-part message in MIME format. ----------MB_8D0DDD493FF397D_17E4_1270F0_webmail-m276.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Sounds good to me. Myself, I have already tabled my suggestions and did refer to a respective = academic publishment (see my email from 30th Nov.). Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Eggert, Lars An: Heiner Hummel Cc: Tony Li ; IRTF Routing RG Verschickt: So, 12 Jan 2014 8:39 am Betreff: Re: [rrg] London Hi, On 2014-1-11, at 21:24, Heiner Hummel wrote: > Given that the IESG doesn't care about IPv4 anymore so even if that were true, what the IESG cares for should have little impac= t on=20 what an IRTF research group is looking into. I thought Tony's email was spot-on. If the RRG wants to remain chartered, i= t=20 needs to become active again and identify some topics that it wants to=20 investigate. Looking at what's been published by academics in the recent pa= st=20 seems a useful exercise in order to find some of those topics. And the group needs a core set of participants that are willing to put in t= he=20 energy to make some successful meetings happen, by re-energizing the broade= r=20 routing community and by inviting folks that have interesting things to pre= sent=20 to show up to do so. Lars =20 ----------MB_8D0DDD493FF397D_17E4_1270F0_webmail-m276.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Sounds goo= d to me.

Myself, I hav= e already tabled my suggestions and did refer to a respective academic publishment  (= see my email from 30th Nov.).

Heiner
 

Hi,

On 2014-1-11, at 21:24, Heiner Hummel <heinerhummel@aol.com> wrote:
> Given that the IESG doesn't care about IPv4 anymore

so even if that were true, what the IESG cares for should have little impac=
t on=20
what an IRTF research group is looking into.

I thought Tony's email was spot-on. If the RRG wants to remain chartered, i=
t=20
needs to become active again and identify some topics that it wants to=20
investigate. Looking at what's been published by academics in the recent pa=
st=20
seems a useful exercise in order to find some of those topics.

And the group needs a core set of participants that are willing to put in t=
he=20
energy to make some successful meetings happen, by re-energizing the broade=
r=20
routing community and by inviting folks that have interesting things to pre=
sent=20
to show up to do so.

Lars
----------MB_8D0DDD493FF397D_17E4_1270F0_webmail-m276.sysops.aol.com-- From lixia@cs.ucla.edu Sun Jan 12 10:12:51 2014 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0641ADFB5 for ; Sun, 12 Jan 2014 10:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJmwJwtVfei2 for ; Sun, 12 Jan 2014 10:12:49 -0800 (PST) Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0C17D1ADF7D for ; Sun, 12 Jan 2014 10:12:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 62DD4A60001; Sun, 12 Jan 2014 10:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBP7hGVmSVQK; Sun, 12 Jan 2014 10:12:37 -0800 (PST) Received: from [10.0.1.8] (cpe-76-166-241-160.socal.res.rr.com [76.166.241.160]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 08F5139E8013; Sun, 12 Jan 2014 10:12:37 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Lixia Zhang In-Reply-To: <69AE8596-8E77-4CC9-B7DA-5F0105D8E6E9@aol.com> Date: Sun, 12 Jan 2014 10:12:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5E3D4B6F-C98C-46D3-AD73-B763C4E0CEB9@cs.ucla.edu> References: <69AE8596-8E77-4CC9-B7DA-5F0105D8E6E9@aol.com> To: Heiner Hummel X-Mailer: Apple Mail (2.1510) Cc: rrg@irtf.org Subject: Re: [rrg] London X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 18:12:51 -0000 I may not necessarily agree with the technical specifics of Heiner's = msg, but I do think the msg made a good point: to provide useful input = into RRG London agenda, we need to first have a clear goal(s) for that = meeting. Just volunteering a talk for whatever latest results multiple = individuals have achieved may or may not help RRG to move forward. So what do we as a group want to achieve? Reactivating RRG would be the results of identifying that goal (the = group would march towards that clearly articulated goal). Or maybe the goal of London meeting could be to identify/clarify the = goal? (in that case, Heiner's msg did make one position statement as an input, = for the group to consider) Lixia PS: I must admit that I have NOT had time to go thru the 40 or so RRG = msgs since Vancouver IETF, ignore my comments if the goal had been = clarified earlier (other than "reactivating RRG"). On Jan 11, 2014, at 12:24 PM, Heiner Hummel = wrote: > Tony, > Given that the IESG doesn't care about IPv4 anymore, what kind of = papers are you looking for? IPv6 papers ? IPv7 papers, based on WHAT ? >=20 > For anyone it would be easier to outline a routing architecture while = 16 octets are available instead of 4. But IPv6 is grounded from the = start. Not even the fact that IPv4 runs out of addresses will help to = unleash IPv6. > Combined with NAT, IPv4 won't effectively have a deletion problem. = Not for the next thousand years. > Technologically NAT is a sin fall, it hampers internet services = enormously. But this is true with IPv6 as well. So what! >=20 > Backward compatibility and incremental deployability should be the two = MUSTs for any architecture, no matter who proposes it. IPv6 isn't = backward compatible due to the dual stack issue - right? or is there any = way around? > What is expected from any new architecture? To be backward compatible = with IPv4 ( I would think so), to be backward compatible with IPv6 (I = wouldn't think so)? So what is expected? >=20 > And of course what do you expect to be solved, respectively to be = enabled at least ? > ---- > Another Proposal: This group should come up with ideas about what a = networking layer should do/support/enable WITHOUT being restricted by = any existing technical solution. > Two examples: 1): Prefix building per se is not a service. It is only = a subdue instrument to cope with problems of a minor design. > 2): State-less multicast would enable an enormous progress ( Imagine = TV-broadcast to billions of spectators). But this is disabled due to the = crazy belief that there is only one way a FIB can be designed (namely = as the existing FIB looks like) > and because a Multicast-FIB cannot reasonable be cast like the = existing Unicast-FIB there cannot/must not be state-less multicast. = Period. >=20 > Heiner >=20 > Am 09.01.2014 um 10:12 schrieb Tony Li : >=20 >>=20 >> Hi all, >>=20 >> We are still looking for excellent papers for our workshop in London. = We really need your help in collecting these. If you know of = interesting research, could you please contact the authors and ask if = they would be willing to present in London? It's coming very soon=85 >>=20 >> Thanks, >> Tony >>=20 >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> http://www.irtf.org/mailman/listinfo/rrg >=20 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From tony.li@tony.li Sun Jan 12 21:04:21 2014 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147A01A1F7D for ; Sun, 12 Jan 2014 21:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzmnxHc-r2tl for ; Sun, 12 Jan 2014 21:04:18 -0800 (PST) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by ietfa.amsl.com (Postfix) with ESMTP id D39361A1EF9 for ; Sun, 12 Jan 2014 21:04:18 -0800 (PST) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta14.emeryville.ca.mail.comcast.net with comcast id DGpe1n0040lTkoCAEH48PQ; Mon, 13 Jan 2014 05:04:08 +0000 Received: from [192.168.5.13] ([64.134.238.233]) by omta04.emeryville.ca.mail.comcast.net with comcast id DH1c1n00J52q0uQ8QH1iNv; Mon, 13 Jan 2014 05:02:03 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tony Li In-Reply-To: <5E3D4B6F-C98C-46D3-AD73-B763C4E0CEB9@cs.ucla.edu> Date: Sun, 12 Jan 2014 21:01:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <69AE8596-8E77-4CC9-B7DA-5F0105D8E6E9@aol.com> <5E3D4B6F-C98C-46D3-AD73-B763C4E0CEB9@cs.ucla.edu> To: Lixia Zhang X-Mailer: Apple Mail (2.1510) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389589448; bh=ky0VyNxOlXoJ5+q/bP9ErsRpCkFN6l5VcDDgSD/6wGI=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=m1HRsxIKKBW3nTwqnE0LmcaY/i4mfQFOcOd1Cs/vsL+rBDTaWivNwBN5fgpPn8Z/e VRF+mLgLFrvqr5U28BIh5hK+T3EyABZJ16g1bCDwsSbPXmoyQZbsdikoFZxihVrLuf C4G6I1H37vO12QnfYH99SCSvHdeazquebzawlb1o73c6H7I7GsYslAyIha0fdvEz4+ mgzg3CKrp3eB0U7unJ9d799sVUP4KStOOZh3gL83iAYgo91pgbKRVbdT+81BVY9TPp KngGNri5AmEvlr6cUEmSFCIW7OSnMponbwhKGol9yJtXiZ1HVBnNEiYIS8P2zxR/3Q yoRqx738VOjtA== Cc: rrg@irtf.org Subject: Re: [rrg] London X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 05:04:21 -0000 Lixia, The whole point of London is a broad survey of routing topics with = exactly the goal of trying to clarify the topic(s) that the RRG is = interested in. In some circles, this is known as the 'shotgun approach'. ;-) Tony On Jan 12, 2014, at 10:12 AM, Lixia Zhang wrote: > I may not necessarily agree with the technical specifics of Heiner's = msg, but I do think the msg made a good point: to provide useful input = into RRG London agenda, we need to first have a clear goal(s) for that = meeting. > Just volunteering a talk for whatever latest results multiple = individuals have achieved may or may not help RRG to move forward. >=20 > So what do we as a group want to achieve? > Reactivating RRG would be the results of identifying that goal (the = group would march towards that clearly articulated goal). >=20 > Or maybe the goal of London meeting could be to identify/clarify the = goal? >=20 > (in that case, Heiner's msg did make one position statement as an = input, for the group to consider) >=20 > Lixia > PS: I must admit that I have NOT had time to go thru the 40 or so RRG = msgs since Vancouver IETF, ignore my comments if the goal had been = clarified earlier (other than "reactivating RRG"). >=20 > On Jan 11, 2014, at 12:24 PM, Heiner Hummel = wrote: >=20 >> Tony, >> Given that the IESG doesn't care about IPv4 anymore, what kind of = papers are you looking for? IPv6 papers ? IPv7 papers, based on WHAT ? >>=20 >> For anyone it would be easier to outline a routing architecture while = 16 octets are available instead of 4. But IPv6 is grounded from the = start. Not even the fact that IPv4 runs out of addresses will help to = unleash IPv6. >> Combined with NAT, IPv4 won't effectively have a deletion problem. = Not for the next thousand years. >> Technologically NAT is a sin fall, it hampers internet services = enormously. But this is true with IPv6 as well. So what! >>=20 >> Backward compatibility and incremental deployability should be the = two MUSTs for any architecture, no matter who proposes it. IPv6 isn't = backward compatible due to the dual stack issue - right? or is there any = way around? >> What is expected from any new architecture? To be backward compatible = with IPv4 ( I would think so), to be backward compatible with IPv6 (I = wouldn't think so)? So what is expected? >>=20 >> And of course what do you expect to be solved, respectively to be = enabled at least ? >> ---- >> Another Proposal: This group should come up with ideas about what a = networking layer should do/support/enable WITHOUT being restricted by = any existing technical solution. >> Two examples: 1): Prefix building per se is not a service. It is only = a subdue instrument to cope with problems of a minor design. >> 2): State-less multicast would enable an enormous progress ( Imagine = TV-broadcast to billions of spectators). But this is disabled due to the = crazy belief that there is only one way a FIB can be designed (namely = as the existing FIB looks like) >> and because a Multicast-FIB cannot reasonable be cast like the = existing Unicast-FIB there cannot/must not be state-less multicast. = Period. >>=20 >> Heiner >>=20 >> Am 09.01.2014 um 10:12 schrieb Tony Li : >>=20 >>>=20 >>> Hi all, >>>=20 >>> We are still looking for excellent papers for our workshop in = London. We really need your help in collecting these. If you know of = interesting research, could you please contact the authors and ask if = they would be willing to present in London? It's coming very soon=85 >>>=20 >>> Thanks, >>> Tony >>>=20 >>> _______________________________________________ >>> rrg mailing list >>> rrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/rrg >>=20 >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> http://www.irtf.org/mailman/listinfo/rrg >=20 From pfrejborg@gmail.com Mon Jan 13 11:13:14 2014 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4CA1ADFD7 for ; Mon, 13 Jan 2014 11:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O19exHHF6I1D for ; Mon, 13 Jan 2014 11:13:12 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id D5D471ADF48 for ; Mon, 13 Jan 2014 11:13:11 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id i13so1987537qae.27 for ; Mon, 13 Jan 2014 11:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=A6e9fncfKxCGtC0m1Q2NlqKWRbvvM8/oOA74tsxLLp0=; b=0A/0pICf2p0ac32Th7EqLq9QQiKMaIQO3Ystl/Y1lslXVzrhAfjgfHWESG1xFOixu9 G7tKMq07vij59NI4rinJsWOifyddcj3NH8MnxPlfXZI6HqANuoq0suwttv1sKu8D/d4Y J8VPMqRSwwMICzQXYg7pYysOyhwnYvdGgtB6zINNxZP8e/cpdK7Z6hIIEgwXowd77IKv 6UwEkrGEUODSnfdsw3696WxFdDjmTb6/skFqeebNXmXK6VFE7Psg6bGGAIWGgD8puELQ y2JZ3sbDljhPt+dLz9TE9I+CpPy6yffcDSSPmu6qWKtiXAsFtgaVS6YgjGEF6wRQQWTi XiwA== MIME-Version: 1.0 X-Received: by 10.224.124.195 with SMTP id v3mr42920964qar.55.1389640380443; Mon, 13 Jan 2014 11:13:00 -0800 (PST) Received: by 10.229.214.10 with HTTP; Mon, 13 Jan 2014 11:13:00 -0800 (PST) In-Reply-To: References: <69AE8596-8E77-4CC9-B7DA-5F0105D8E6E9@aol.com> <5E3D4B6F-C98C-46D3-AD73-B763C4E0CEB9@cs.ucla.edu> Date: Mon, 13 Jan 2014 21:13:00 +0200 Message-ID: From: Patrick Frejborg To: Tony Li Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: RRG Subject: Re: [rrg] London X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 19:13:14 -0000 Tony, here is a shotshell for your shotgun to consider, and also for the group to consider as a research topic. Currently there is no papers or presentations available, it is an early idea based on a combination of several research works - if it is doable it could produce some new research papers from this group. The basic idea is: 1) Take ILNPv6 as a baseline. 2) Add a new routing header extension to ILNPv6, it will contain some locator fields. It must be compatible with RFC2460, some tweaks are needed but it has to obey the spirit and format of RFC2460. 3) From RFC6306, take the concept of realms and for the "segments left" field in the new routing header field, take the conpets of exit routing, DFZ routing and approach routing - apply those on ILNPv6 with the new routing header extension. However, "segments left" field has to be applied in such way that it do obey RFC5095 in DFZ routing path of a packet's journey (this is the tweak). 4) The DFZ must remain backwards compatible. 5) With steps 1-3 in place we can introduce a new type of identifier, a service identifier with a "late binding", see http://www.cs.princeton.edu/research/techreps/TR-885-10 6) Multipath transport protocols, such as MPTCP and SCTP will add a new option of multi-homing and mobility to ILNPv6 ("new option" is the wrong semantics here, but anyway) - ILNPv6 with the host identifier is great for business-to-business sessions (e.g. LAN-to-LAN VPN tunnels) but I think that a multipath transport protocol with a service identifier solution is better suited for the cloud and mobility era of the Internet. So here is the shotshell in a nutshell ;-) It is up to the group if we can think this might be doable and willing to spend some time researching on this specific topic. Patrick On Mon, Jan 13, 2014 at 7:01 AM, Tony Li wrote: > > Lixia, > > The whole point of London is a broad survey of routing topics with exactl= y the goal of trying to clarify the topic(s) that the RRG is interested in. > > In some circles, this is known as the 'shotgun approach'. ;-) > > Tony > > > On Jan 12, 2014, at 10:12 AM, Lixia Zhang wrote: > >> I may not necessarily agree with the technical specifics of Heiner's msg= , but I do think the msg made a good point: to provide useful input into RR= G London agenda, we need to first have a clear goal(s) for that meeting. >> Just volunteering a talk for whatever latest results multiple individual= s have achieved may or may not help RRG to move forward. >> >> So what do we as a group want to achieve? >> Reactivating RRG would be the results of identifying that goal (the grou= p would march towards that clearly articulated goal). >> >> Or maybe the goal of London meeting could be to identify/clarify the goa= l? >> >> (in that case, Heiner's msg did make one position statement as an input,= for the group to consider) >> >> Lixia >> PS: I must admit that I have NOT had time to go thru the 40 or so RRG ms= gs since Vancouver IETF, ignore my comments if the goal had been clarified = earlier (other than "reactivating RRG"). >> >> On Jan 11, 2014, at 12:24 PM, Heiner Hummel wrote= : >> >>> Tony, >>> Given that the IESG doesn't care about IPv4 anymore, what kind of paper= s are you looking for? IPv6 papers ? IPv7 papers, based on WHAT ? >>> >>> For anyone it would be easier to outline a routing architecture while 1= 6 octets are available instead of 4. But IPv6 is grounded from the start. N= ot even the fact that IPv4 runs out of addresses will help to unleash IPv6= . >>> Combined with NAT, IPv4 won't effectively have a deletion problem. Not= for the next thousand years. >>> Technologically NAT is a sin fall, it hampers internet services enorm= ously. But this is true with IPv6 as well. So what! >>> >>> Backward compatibility and incremental deployability should be the two = MUSTs for any architecture, no matter who proposes it. IPv6 isn't backward = compatible due to the dual stack issue - right? or is there any way around? >>> What is expected from any new architecture? To be backward compatible w= ith IPv4 ( I would think so), to be backward compatible with IPv6 (I wouldn= 't think so)? So what is expected? >>> >>> And of course what do you expect to be solved, respectively to be enabl= ed at least ? >>> ---- >>> Another Proposal: This group should come up with ideas about what a ne= tworking layer should do/support/enable WITHOUT being restricted by any exi= sting technical solution. >>> Two examples: 1): Prefix building per se is not a service. It is only a= subdue instrument to cope with problems of a minor design. >>> 2): State-less multicast would enable an enormous progress ( Imagine TV= -broadcast to billions of spectators). But this is disabled due to the craz= y belief that there is only one way a FIB can be designed (namely as the e= xisting FIB looks like) >>> and because a Multicast-FIB cannot reasonable be cast like the existing= Unicast-FIB there cannot/must not be state-less multicast. Period. >>> >>> Heiner >>> >>> Am 09.01.2014 um 10:12 schrieb Tony Li : >>> >>>> >>>> Hi all, >>>> >>>> We are still looking for excellent papers for our workshop in London. = We really need your help in collecting these. If you know of interesting = research, could you please contact the authors and ask if they would be wil= ling to present in London? It's coming very soon=85 >>>> >>>> Thanks, >>>> Tony >>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From heinerhummel@aol.com Fri Jan 17 00:06:12 2014 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBC31ADFB5 for ; Fri, 17 Jan 2014 00:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_WT8kmdnIuy for ; Fri, 17 Jan 2014 00:06:06 -0800 (PST) Received: from omr-d03.mx.aol.com (omr-d03.mx.aol.com [205.188.109.200]) by ietfa.amsl.com (Postfix) with ESMTP id 951FD1ADFAA for ; Fri, 17 Jan 2014 00:06:06 -0800 (PST) Received: from mtaomg-mbe01.mx.aol.com (mtaomg-mbe01.mx.aol.com [172.26.254.175]) by omr-d03.mx.aol.com (Outbound Mail Relay) with ESMTP id 1AB6C701BD6CF; Fri, 17 Jan 2014 03:05:54 -0500 (EST) Received: from core-dqa005a.r1000.mail.aol.com (core-dqa005.r1000.mail.aol.com [172.29.211.209]) by mtaomg-mbe01.mx.aol.com (OMAG/Core Interface) with ESMTP id A30B73800008C; Fri, 17 Jan 2014 03:05:53 -0500 (EST) References: <69AE8596-8E77-4CC9-B7DA-5F0105D8E6E9@aol.com> <5E3D4B6F-C98C-46D3-AD73-B763C4E0CEB9@cs.ucla.edu> To: lixia@cs.ucla.edu In-Reply-To: <5E3D4B6F-C98C-46D3-AD73-B763C4E0CEB9@cs.ucla.edu> X-MB-Message-Source: WebUI Received: from 178.26.195.50 by webmail-d263.sysops.aol.com (205.188.16.103) with HTTP (WebMailUI); Fri, 17 Jan 2014 03:05:53 -0500 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D0E17213BD5DA5_1ABC_18317_webmail-d263.sysops.aol.com" X-Mailer: AOL Webmail 38252-STANDARD Message-Id: <8D0E17213B176C5-1ABC-602E@webmail-d263.sysops.aol.com> X-Originating-IP: [178.26.195.50] Date: Fri, 17 Jan 2014 03:05:53 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1389945954; bh=MDXKxS1PT1k0ralsrOlMrgxGHxzI7Tq3VoSt/rMqB7k=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=UiPpTaU+odXYAm80j/5IPETO6B3ZZFjg24KDC5RGQs3U1YGxktZr+pyufZNNhBjlc TCPo7ZfSIoRX6VMxPVMPAAN3gnkMZ7q+gZNlsIn5sduuZY0hgI5sWzr1pTSunhrx9y Ywuh4dGhnGB1V/+YUZlRLqG9rjuB0XyuUesnFtXk= x-aol-sid: 3039ac1afeaf52d8e4610d2a Cc: rrg@irtf.org Subject: Re: [rrg] London X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 08:06:13 -0000 This is a multi-part message in MIME format. ----------MB_8D0E17213BD5DA5_1ABC_18317_webmail-d263.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Lixia, It was at the London 2002 IETF meeting when the request was raised to devel= op a new routing architecture. Concurrently it was added " there is no reas= on to rush, we will have a 10 years time frame for doing it". Well, meanwhi= le 12 years have passed and all we 've got is LISP which boast to enable 52= x10^27 EIDs per person but doesn't enhance the IPv4 address space not by on= e single address. A concept which employs (bottle neck) servers which are = vulnerable wrt. DoSA and perhaps even due to normal overload of queries and= which impose a threat to their not-owning clients which dependent on them.= =20 IPv6 was certainly not meant by that request in London because it existed a= lready at that time. And RFC 4984 =C2=A73 even warns that it would multifol= d the number of prefixes. And integrating AS-numbers seems not good wrt pre= fix building either. Also: 16 octets are provided and yet a E164 mobile use= r phone number is still needed outside of these 16 octets:-(. In the past I have asked many times to discuss the existing paradigms, and= to question them ! Research is questioning the obvious! The too obvious! L= ike: Why are there two different routing concepts wrt intra versus inter-do= main routing? I really would like to know why is Dijkstra bad for inter-dom= ain ? Why isn't Distance Vector used in intra-domain routing? Why is there no Multicast-FIB ? Is it because it can't hardly be like the e= xisting Unicast-FIB on the one hand side while on the other side a FIB must= not be any different than the existing one? Lixia, why would you not necessarily agree with my technical specific of ha= ving a Multicast-FIB ? And also: What is the value of depending on prefix building in unicast forw= arding? After all, it doesn't work wrt Multicast nor to Anycast (nor see ab= ove with AS#s) Another very fundamental point is what we expect a network layer to be/to l= ook like/to handle/ to solve: It is not only me, it is the entire ITU-T which thinks that the network lay= er deals with the WHERE. With E164 routing and addressing are or at least h= ave been identical: the next-hop trunk was selected electro-mechanically du= e to the next dialed digit. A routing protocol wasn't even needed.=20 It is worth to have a look to the past. I am convinced, If there were not M= POA (but Cisco's Peer model instead) MPLS wouldn't have been developed. Wit= hout MPLS, being a strong push of IntServ, there wouldn't have been the cou= nter movement DiffServ whose mantra is "do what Traffic Engineering wanted = to contribute to SVCs/LSPs without knowing the network nor its current traf= fic load external to the waiting queue of incoming packets at any router An= d - imho - this mantra prevents any reasonable handling of genuine network = layer objectives: like handling traffic congestions (avoiding them if possi= ble in the first place dissolving them where needed). A network layer techn= ology which has no idea, how to direct flows such that some would bypass th= e congested area to the left while some others to the right is not future p= rone. It is stupid and unknowledgeable!!! Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Lixia Zhang An: Heiner Hummel Cc: Tony Li ; rrg Verschickt: So, 12 Jan 2014 7:12 pm Betreff: Re: [rrg] London I may not necessarily agree with the technical specifics of Heiner's msg, b= ut I=20 do think the msg made a good point: to provide useful input into RRG London= =20 agenda, we need to first have a clear goal(s) for that meeting. Just volunteering a talk for whatever latest results multiple individuals h= ave=20 achieved may or may not help RRG to move forward. So what do we as a group want to achieve? Reactivating RRG would be the results of identifying that goal (the group w= ould=20 march towards that clearly articulated goal). Or maybe the goal of London meeting could be to identify/clarify the goal? (in that case, Heiner's msg did make one position statement as an input, fo= r the=20 group to consider) Lixia PS: I must admit that I have NOT had time to go thru the 40 or so RRG msgs = since=20 Vancouver IETF, ignore my comments if the goal had been clarified earlier (= other=20 than "reactivating RRG"). On Jan 11, 2014, at 12:24 PM, Heiner Hummel wrote: > Tony, > Given that the IESG doesn't care about IPv4 anymore, what kind of papers = are=20 you looking for? IPv6 papers ? IPv7 papers, based on WHAT ? >=20 > For anyone it would be easier to outline a routing architecture while 16= =20 octets are available instead of 4. But IPv6 is grounded from the start. Not= even=20 the fact that IPv4 runs out of addresses will help to unleash IPv6. > Combined with NAT, IPv4 won't effectively have a deletion problem. Not f= or=20 the next thousand years. > Technologically NAT is a sin fall, it hampers internet services enormou= sly.=20 But this is true with IPv6 as well. So what! >=20 > Backward compatibility and incremental deployability should be the two MU= STs=20 for any architecture, no matter who proposes it. IPv6 isn't backward compat= ible=20 due to the dual stack issue - right? or is there any way around? > What is expected from any new architecture? To be backward compatible wit= h=20 IPv4 ( I would think so), to be backward compatible with IPv6 (I wouldn't t= hink=20 so)? So what is expected? >=20 > And of course what do you expect to be solved, respectively to be enabled= at=20 least ? > ---- > Another Proposal: This group should come up with ideas about what a=20 networking layer should do/support/enable WITHOUT being restricted by any= =20 existing technical solution. > Two examples: 1): Prefix building per se is not a service. It is only a s= ubdue=20 instrument to cope with problems of a minor design. > 2): State-less multicast would enable an enormous progress ( Imagine=20 TV-broadcast to billions of spectators). But this is disabled due to the cr= azy=20 belief that there is only one way a FIB can be designed (namely as the exi= sting=20 FIB looks like) > and because a Multicast-FIB cannot reasonable be cast like the existing= =20 Unicast-FIB there cannot/must not be state-less multicast. Period. >=20 > Heiner >=20 > Am 09.01.2014 um 10:12 schrieb Tony Li : >=20 >>=20 >> Hi all, >>=20 >> We are still looking for excellent papers for our workshop in London. W= e=20 really need your help in collecting these. If you know of interesting rese= arch,=20 could you please contact the authors and ask if they would be willing to pr= esent=20 in London? It's coming very soon=E2=80=A6 >>=20 >> Thanks, >> Tony >>=20 >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> http://www.irtf.org/mailman/listinfo/rrg >=20 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg =20 ----------MB_8D0E17213BD5DA5_1ABC_18317_webmail-d263.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Lixia,

It was at the London 2002 IETF m= eeting when the request was raised to develop a new routing architecture. C= oncurrently it was added " there is no reason to rush, we will have a 10 ye= ars time frame for doing it". Well, meanwhile 12 years have passed and all = we 've got is LISP which boast to enable 52x10^27 EIDs per person but doesn= 't enhance the IPv4 address space not by one single address. A concept whic= h  employs (bottle neck) servers which are vulnerable wrt. DoSA and pe= rhaps even due to normal overload of queries and which impose a threat= to their not-owning clients which dependent on them.  <= /div>

IPv6 was certainly not meant by = that request in London because it existed already at that time. And RFC 498= 4 =C2=A73 even warns that it would multifold the number of prefixes. And in= tegrating AS-numbers seems not good wrt prefix building either. Also: 16 oc= tets are provided and yet a E164 mobile user phone number is still needed o= utside of these 16 octets:-(.

In the past I have  as= ked many times to discuss the existing paradigms, and to question them= ! Research is questioning the obvious! The too obvious! Like: Why are ther= e two different routing concepts wrt intra versus inter-domain routing? I r= eally would like to know why is Dijkstra bad for inter-domain ? Why isn't D= istance Vector used in intra-domain routing?
Why is there no Multicast-FIB ? = Is it because it can't hardly be like the existing Unicast-FIB on the one h= and side while on the other side a FIB must not be any different than the e= xisting one?
Lixia, why would you not necessa= rily agree with my technical specific of having a Multicast-FIB ?
And also: What is the value of dependi= ng on prefix building in unicast forwarding? After all, it doesn't work wrt= Multicast nor to Anycast (nor see above with AS#s)


Another very fundamental point is what= we expect a network layer to be/to look like/to handle/ to solve:

It is not only me, it is the entire IT= U-T which thinks that the network layer deals with the WHERE. With E164 rou= ting and addressing are or at least have been identical: the next-hop trunk= was selected electro-mechanically due to the next dialed digit. A routing = protocol wasn't even needed. 


It is worth to have a look to the past= . I am convinced, If there were not MPOA (but Cisco's Peer model instead) M= PLS wouldn't have been developed. Without MPLS, being a strong push of IntS= erv, there wouldn't have been the counter movement DiffServ whose mantra is= "do what Traffic Engineering wanted to contribute to SVCs/LSPs without kno= wing the network nor its current traffic load external to the waiting queue= of incoming packets at any router And - imho - this mantra prevents any re= asonable handling of genuine network layer objectives: like handling traffi= c congestions (avoiding them if possible in the first place dissolving= them where needed). A network layer technology which has no idea, how to d= irect flows such that some would bypass the congested area to the left whil= e some others to the right is not future prone. It is stupid and unknowledg= eable!!!

Heiner




I may not necessarily agree with the tec=
hnical specifics of Heiner's msg, but I=20
do think the msg made a good point: to provide useful input into RRG London=
=20
agenda, we need to first have a clear goal(s) for that meeting.
Just volunteering a talk for whatever latest results multiple individuals h=
ave=20
achieved may or may not help RRG to move forward.

So what do we as a group want to achieve?
Reactivating RRG would be the results of identifying that goal (the group w=
ould=20
march towards that clearly articulated goal).

Or maybe the goal of London meeting could be to identify/clarify the goal?

(in that case, Heiner's msg did make one position statement as an input, fo=
r the=20
group to consider)

Lixia
PS: I must admit that I have NOT had time to go thru the 40 or so RRG msgs =
since=20
Vancouver IETF, ignore my comments if the goal had been clarified earlier (=
other=20
than "reactivating RRG").

On Jan 11, 2014, at 12:24 PM, Heiner Hummel <heinerhummel@aol.com> wrote:

> Tony,
> Given that the IESG doesn't care about IPv4 anymore, what kind of pape=
rs are=20
you looking for? IPv6 papers ? IPv7 papers, based on WHAT ?
>=20
> For anyone it would be easier to outline a routing architecture while =
16=20
octets are available instead of 4. But IPv6 is grounded from the start. Not=
 even=20
the fact that  IPv4 runs out of addresses will help to unleash IPv6.
> Combined with NAT,  IPv4 won't effectively have a deletion problem. No=
t for=20
the next thousand years.
> Technologically NAT is a sin  fall, it hampers internet services  enor=
mously.=20
But this is true with IPv6 as well. So what!
>=20
> Backward compatibility and incremental deployability should be the two=
 MUSTs=20
for any architecture, no matter who proposes it. IPv6 isn't backward compat=
ible=20
due to the dual stack issue - right? or is there any way around?
> What is expected from any new architecture? To be backward compatible =
with=20
IPv4 ( I would think so), to be backward compatible with IPv6 (I wouldn't t=
hink=20
so)? So what is expected?
>=20
> And of course what do you expect to be solved, respectively to be enab=
led at=20
least ?
> ----
> Another Proposal:  This group should come up with ideas about what a=
=20
networking layer should do/support/enable WITHOUT being restricted by any=
=20
existing technical solution.
> Two examples: 1): Prefix building per se is not a service. It is only =
a subdue=20
instrument to cope with problems of a minor design.
> 2): State-less multicast would enable an enormous progress ( Imagine=
=20
TV-broadcast to billions of spectators). But this is disabled due to the cr=
azy=20
belief that there is only one way  a FIB can be designed (namely as the exi=
sting=20
FIB looks like)
> and because a Multicast-FIB cannot reasonable be cast like the existin=
g=20
Unicast-FIB there cannot/must not be state-less multicast. Period.
>=20
> Heiner
>=20
> Am 09.01.2014 um 10:12 schrieb Tony Li <tony.li@tony.li>:
>=20
>>=20
>> Hi all,
>>=20
>> We are still looking for excellent papers for our workshop in Lond=
on.  We=20
really need your help in collecting these.  If you know of interesting rese=
arch,=20
could you please contact the authors and ask if they would be willing to pr=
esent=20
in London?  It's coming very soon=E2=80=A6
>>=20
>> Thanks,
>> Tony
>>=20
>> _______________________________________________
>> rrg mailing list
>> rrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/rrg
>=20
> _______________________________________________
> rrg mailing list
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg
----------MB_8D0E17213BD5DA5_1ABC_18317_webmail-d263.sysops.aol.com-- From lixia@cs.ucla.edu Fri Jan 17 22:04:17 2014 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB171ADEB4 for ; Fri, 17 Jan 2014 22:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78ZRBy1d5xh2 for ; Fri, 17 Jan 2014 22:04:16 -0800 (PST) Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id E2E921ADE72 for ; Fri, 17 Jan 2014 22:04:15 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 534A0A60004; Fri, 17 Jan 2014 22:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmrIUs9hC1j0; Fri, 17 Jan 2014 22:04:01 -0800 (PST) Received: from [10.0.1.8] (cpe-76-166-241-160.socal.res.rr.com [76.166.241.160]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 5B2B039E8011; Fri, 17 Jan 2014 22:04:01 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_534479BE-FE66-4C11-AC77-199A89CFC8EF" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Lixia Zhang In-Reply-To: <8D0E17213B176C5-1ABC-602E@webmail-d263.sysops.aol.com> Date: Fri, 17 Jan 2014 22:04:02 -0800 Message-Id: <3E1A9EBE-B57B-4FEE-ABD9-EFAC14FCB134@cs.ucla.edu> References: <69AE8596-8E77-4CC9-B7DA-5F0105D8E6E9@aol.com> <5E3D4B6F-C98C-46D3-AD73-B763C4E0CEB9@cs.ucla.edu> <8D0E17213B176C5-1ABC-602E@webmail-d263.sysops.aol.com> To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.1510) Cc: rrg@irtf.org Subject: Re: [rrg] London X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 06:04:17 -0000 --Apple-Mail=_534479BE-FE66-4C11-AC77-199A89CFC8EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 17, 2014, at 12:05 AM, HeinerHummel@aol.com wrote: > Lixia, >=20 > It was at the London 2002 IETF meeting when the request was raised to = develop a new routing architecture. Concurrently it was added " there is = no reason to rush, we will have a 10 years time frame for doing it". = Well, meanwhile 12 years have passed and all we 've got is LISP which = boast to enable 52x10^27 EIDs per person but doesn't enhance the IPv4 = address space not by one single address. A concept which employs = (bottle neck) servers which are vulnerable wrt. DoSA and perhaps even = due to normal overload of queries and which impose a threat to their = not-owning clients which dependent on them. =20 >=20 > IPv6 was certainly not meant by that request in London because it = existed already at that time. And RFC 4984 =A73 even warns that it would = multifold the number of prefixes. And integrating AS-numbers seems not = good wrt prefix building either. Also: 16 octets are provided and yet a = E164 mobile user phone number is still needed outside of these 16 = octets:-(. >=20 > In the past I have asked many times to discuss the existing = paradigms, and to question them ! Research is questioning the obvious! = The too obvious! Like: Why are there two different routing concepts wrt = intra versus inter-domain routing? I really would like to know why is = Dijkstra bad for inter-domain ? Why isn't Distance Vector used in = intra-domain routing? > Why is there no Multicast-FIB ? Is it because it can't hardly be like = the existing Unicast-FIB on the one hand side while on the other side a = FIB must not be any different than the existing one? > Lixia, why would you not necessarily agree with my technical specific = of having a Multicast-FIB ? > And also: What is the value of depending on prefix building in unicast = forwarding? After all, it doesn't work wrt Multicast nor to Anycast (nor = see above with AS#s) >=20 > Another very fundamental point is what we expect a network layer to = be/to look like/to handle/ to solve: >=20 > It is not only me, it is the entire ITU-T which thinks that the = network layer deals with the WHERE. With E164 routing and addressing are = or at least have been identical: the next-hop trunk was selected = electro-mechanically due to the next dialed digit. A routing protocol = wasn't even needed.=20 >=20 > It is worth to have a look to the past. I am convinced, If there were = not MPOA (but Cisco's Peer model instead) MPLS wouldn't have been = developed. Without MPLS, being a strong push of IntServ, there wouldn't = have been the counter movement DiffServ whose mantra is "do what Traffic = Engineering wanted to contribute to SVCs/LSPs without knowing the = network nor its current traffic load external to the waiting queue of = incoming packets at any router And - imho - this mantra prevents any = reasonable handling of genuine network layer objectives: like handling = traffic congestions (avoiding them if possible in the first place = dissolving them where needed). A network layer technology which has no = idea, how to direct flows such that some would bypass the congested area = to the left while some others to the right is not future prone. It is = stupid and unknowledgeable!!! >=20 > Heiner Hi Heiner, although your msg seems addressed to me, I believe you meant to bring up = the questions to the RRG, right? =20 Lixia= --Apple-Mail=_534479BE-FE66-4C11-AC77-199A89CFC8EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 HeinerHummel@aol.com = wrote:

Lixia,

It was at the London = 2002 IETF meeting when the request was raised to develop a new routing = architecture. Concurrently it was added " there is no reason to rush, we = will have a 10 years time frame for doing it". Well, meanwhile 12 years = have passed and all we 've got is LISP which boast to enable 52x10^27 = EIDs per person but doesn't enhance the IPv4 address space not by one = single address. A concept which  employs (bottle neck) servers = which are vulnerable wrt. DoSA and perhaps even due to normal = overload of queries and which impose a threat to their not-owning = clients which dependent on them.  

IPv6 was certainly not meant by that request in London = because it existed already at that time. And RFC 4984 =A73 even warns = that it would multifold the number of prefixes. And integrating = AS-numbers seems not good wrt prefix building either. Also: 16 octets = are provided and yet a E164 mobile user phone number is still needed = outside of these 16 octets:-(.

In the past = I have  asked many times to discuss the existing = paradigms, and to question them ! Research is questioning the obvious! = The too obvious! Like: Why are there two different routing concepts wrt = intra versus inter-domain routing? I really would like to know why is = Dijkstra bad for inter-domain ? Why isn't Distance Vector used in = intra-domain routing?
Why is there no Multicast-FIB ? Is it because it can't hardly = be like the existing Unicast-FIB on the one hand side while on the other = side a FIB must not be any different than the existing = one?
Lixia, why would you = not necessarily agree with my technical specific of having a = Multicast-FIB ?
And = also: What is the value of depending on prefix building in unicast = forwarding? After all, it doesn't work wrt Multicast nor to Anycast (nor = see above with AS#s)
Another = very fundamental point is what we expect a network layer to be/to look = like/to handle/ to solve:

It is not only me, it is the entire ITU-T = which thinks that the network layer deals with the WHERE. With E164 = routing and addressing are or at least have been identical: the next-hop = trunk was selected electro-mechanically due to the next dialed digit. A = routing protocol wasn't even needed. 
It is = worth to have a look to the past. I am convinced, If there were not MPOA = (but Cisco's Peer model instead) MPLS wouldn't have been developed. = Without MPLS, being a strong push of IntServ, there wouldn't have been = the counter movement DiffServ whose mantra is "do what Traffic = Engineering wanted to contribute to SVCs/LSPs without knowing the = network nor its current traffic load external to the waiting queue of = incoming packets at any router And - imho - this mantra prevents any = reasonable handling of genuine network layer objectives: like handling = traffic congestions (avoiding them if possible in the first place = dissolving them where needed). A network layer technology which has no = idea, how to direct flows such that some would bypass the congested area = to the left while some others to the right is not future prone. It is = stupid and unknowledgeable!!!

Heiner

Hi = Heiner,

although your msg seems addressed to me, I = believe you meant to bring up the questions to the RRG, right? =  

Lixia
= --Apple-Mail=_534479BE-FE66-4C11-AC77-199A89CFC8EF-- From heinerhummel@aol.com Sat Jan 18 09:39:52 2014 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8381ADF7B for ; Sat, 18 Jan 2014 09:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.062 X-Spam-Level: X-Spam-Status: No, score=0.062 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5Tum0DszuwP for ; Sat, 18 Jan 2014 09:39:50 -0800 (PST) Received: from omr-m02.mx.aol.com (omr-m02.mx.aol.com [64.12.143.76]) by ietfa.amsl.com (Postfix) with ESMTP id 06D371ADF60 for ; Sat, 18 Jan 2014 09:39:50 -0800 (PST) Received: from mtaomg-mbe01.mx.aol.com (mtaomg-mbe01.mx.aol.com [172.26.254.175]) by omr-m02.mx.aol.com (Outbound Mail Relay) with ESMTP id 29FF97000009E; Sat, 18 Jan 2014 12:39:37 -0500 (EST) Received: from core-dqa005a.r1000.mail.aol.com (core-dqa005.r1000.mail.aol.com [172.29.211.209]) by mtaomg-mbe01.mx.aol.com (OMAG/Core Interface) with ESMTP id 6E88B38000082; Sat, 18 Jan 2014 12:39:36 -0500 (EST) To: lixia@cs.ucla.edu X-MB-Message-Source: WebUI Received: from 178.26.195.50 by webmail-d263.sysops.aol.com (205.188.16.103) with HTTP (WebMailUI); Sat, 18 Jan 2014 12:39:36 -0500 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D0E28B63CBA14E_BB0_1F037_webmail-d263.sysops.aol.com" X-Mailer: AOL Webmail 38289-STANDARD Message-Id: <8D0E28B63BD590E-BB0-861E@webmail-d263.sysops.aol.com> X-Originating-IP: [178.26.195.50] Date: Sat, 18 Jan 2014 12:39:36 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1390066777; bh=pnDHJu8hBxX0u3zzBPUuGeAdQrzEySPFa0FQUwMvmok=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=NM3IYe6uDWZD/SFOwdujFTlORcVKYUwkzb4cXwNZD3dTlyIw3tv2Irv/fzNY5pXiw dSXXy41IX/Q7kKqNmnJbBBMxhIXKpz4zUje3Gvb1Sus4CEyTBItgNZou+MffNBPc/7 hk4jfH1Cyvly9RbeqnaRfvExdvT85Vv6eOKl89OA= x-aol-sid: 3039ac1afeaf52dabc583984 Cc: rrg@irtf.org Subject: Re: [rrg] London X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 17:39:52 -0000 This is a multi-part message in MIME format. ----------MB_8D0E28B63CBA14E_BB0_1F037_webmail-d263.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Certainly, Lixia :-) And there are many more severe points to make for sure. Against LISP, again= st IPv6, against many holy paradigms, and also against the general way to p= roceed.=20 "Rough consensus and running code" has also its disadvantages, especially i= f each taken step to improve creates a higher hurdle for the over next step= of improvement.=20 Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Lixia Zhang An: HeinerHummel Cc: tony.li ; rrg Verschickt: Sa, 18 Jan 2014 7:04 am Betreff: Re: [rrg] London On Jan 17, 2014, at 12:05 AM, HeinerHummel@aol.com wrote: Lixia, It was at the London 2002 IETF meeting when the request was raised to devel= op a new routing architecture. Concurrently it was added " there is no reas= on to rush, we will have a 10 years time frame for doing it". Well, meanwhi= le 12 years have passed and all we 've got is LISP which boasts to enable 5= 2x10^27 EIDs per person but doesn't enhance the IPv4 address space not by o= ne single address. Also, it is a concept which employs (bottle neck) server= s which are vulnerable wrt. DoSA and perhaps even due to normal overload of= queries and which creates a dependency of their clients which might cause = a latent political threat by the owners of these servers for their (helples= s) clients. =20 IPv6 was certainly not meant by that request in London because it existed a= lready at that time. And RFC 4984 =C2=A73 even warns that it would multifol= d the number of prefixes. And integrating AS-numbers seems not good wrt pre= fix building either. Also: 16 octets are provided and yet a E164 mobile use= r phone number is still needed outside of these 16 octets:-(. In the past I have asked many times to discuss the existing paradigms, and= to question them ! Research is questioning the obvious! The too obvious! L= ike: Why are there two different routing concepts wrt intra versus inter-do= main routing? I really would like to know why is Dijkstra bad for inter-dom= ain ? Why isn't Distance Vector used in intra-domain routing? Why is there no Multicast-FIB ? Is it because it can't hardly be like the e= xisting Unicast-FIB on the one hand side while on the other side a FIB must= not be any different than the existing one? Lixia, why would you not necessarily agree with my technical specific of ha= ving a Multicast-FIB ? And also: What is the value of depending on prefix building in unicast forw= arding? After all, it doesn't work wrt Multicast nor to Anycast (nor see ab= ove with AS#s) Another very fundamental point is what we expect a network layer to be/to l= ook like/to handle/ to solve: It is not only me, it is the entire ITU-T which thinks that the network lay= er deals with the WHERE. With E164 routing and addressing are or at least h= ave been identical: the next-hop trunk was selected electro-mechanically du= e to the next dialed digit. A routing protocol wasn't even needed.=20 It is worth to have a look to the past. I am convinced, If there were not M= POA (but Cisco's Peer model instead) MPLS wouldn't have been developed. Wit= hout MPLS, being a strong push of IntServ, there wouldn't have been the cou= nter movement DiffServ whose mantra is "do what Traffic Engineering wanted = to contribute to SVCs/LSPs without knowing the network nor its current traf= fic load external to the waiting queue of incoming packets at any router An= d - imho - this mantra prevents any reasonable handling of genuine network = layer objectives: like handling traffic congestions (avoiding them if possi= ble in the first place dissolving them where needed). A network layer techn= ology which has no idea, how to direct flows such that some would bypass th= e congested area to the left while some others to the right is not future p= rone. It is stupid and unknowledgeable!!! Heiner Hi Heiner, although your msg seems addressed to me, I believe you meant to bring up th= e questions to the RRG, right? =20 Lixia ----------MB_8D0E28B63CBA14E_BB0_1F037_webmail-d263.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Certainly, Lixia :-)

And there are many more severe points to make for sure. = Against LISP, against IPv6, against many holy paradigms, and also against t= he general way to proceed. 
"Rough con= sensus and running code" has also its disadvantages, especially if each tak= en step to improve creates a higher hurdle for the over next step of improvement. 


On Jan 17, 2014, at 12:05 AM, = HeinerHummel@aol.com wrote:

Lixia,
It = was at the London 2002 IETF meeting when the request was raised to develop = a new routing architecture. Concurrently it was added " there is no reason = to rush, we will have a 10 years time frame for doing it". Well, meanwhile = 12 years have passed and all we 've got is LISP which boasts to enable 52x1= 0^27 EIDs per person but doesn't enhance the IPv4 address space not by one = single address. Also, it is a concept which employs (bottle neck) servers w= hich are vulnerable wrt. DoSA and perhaps even due to normal overload = of queries and which creates a dependency of their clients which might caus= e a latent political threat by the owners of these servers for their (helpl= ess) clients.  
IPv= 6 was certainly not meant by that request in London because it existed alre= ady at that time. And RFC 4984 =C2=A73 even warns that it would multifold t= he number of prefixes. And integrating AS-numbers seems not good wrt prefix= building either. Also: 16 octets are provided and yet a E164 mobile user p= hone number is still needed outside of these 16 octets:-(.
In = the past I have  asked many times to discuss the existing pa= radigms, and to question them ! Research is questioning the obvious! The to= o obvious! Like: Why are there two different routing concepts wrt intra ver= sus inter-domain routing? I really would like to know why is Dijkstra bad f= or inter-domain ? Why isn't Distance Vector used in intra-domain routing?
Why= is there no Multicast-FIB ? Is it because it can't hardly be like the exis= ting Unicast-FIB on the one hand side while on the other side a FIB must no= t be any different than the existing one?
Lix= ia, why would you not necessarily agree with my technical specific of havin= g a Multicast-FIB ?
And also: What is the value of depending on prefix building in = unicast forwarding? After all, it doesn't work wrt Multicast nor to Anycast= (nor see above with AS#s)

Another very fundamental point is what we expect a network laye= r to be/to look like/to handle/ to solve:

It is not only me, it is the entire ITU-T which thinks that the= network layer deals with the WHERE. With E164 routing and addressing are o= r at least have been identical: the next-hop trunk was selected electro-mec= hanically due to the next dialed digit. A routing protocol wasn't even need= ed. 

It is worth to have a look to the past. I am convinced, If ther= e were not MPOA (but Cisco's Peer model instead) MPLS wouldn't have been de= veloped. Without MPLS, being a strong push of IntServ, there wouldn't have = been the counter movement DiffServ whose mantra is "do what Traffic Enginee= ring wanted to contribute to SVCs/LSPs without knowing the network nor its = current traffic load external to the waiting queue of incoming packets at a= ny router And - imho - this mantra prevents any reasonable handling of genu= ine network layer objectives: like handling traffic congestions (avoiding t= hem if possible in the first place dissolving them where needed). A ne= twork layer technology which has no idea, how to direct flows such that som= e would bypass the congested area to the left while some others to the righ= t is not future prone. It is stupid and unknowledgeable!!!

Heiner

Hi Heiner,

although your msg seems addressed to me, I believe you meant to bring = up the questions to the RRG, right?  

Lixia
----------MB_8D0E28B63CBA14E_BB0_1F037_webmail-d263.sysops.aol.com-- From lixia@cs.ucla.edu Sat Jan 18 14:27:24 2014 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93371AD7C2 for ; Sat, 18 Jan 2014 14:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.138 X-Spam-Level: X-Spam-Status: No, score=-4.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClHVmO7hIbEx for ; Sat, 18 Jan 2014 14:27:21 -0800 (PST) Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 943221AD1F5 for ; Sat, 18 Jan 2014 14:27:21 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 9291439E8015; Sat, 18 Jan 2014 14:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gse+n9IaZcq; Sat, 18 Jan 2014 14:27:06 -0800 (PST) Received: from [10.0.1.8] (cpe-76-166-241-160.socal.res.rr.com [76.166.241.160]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 187CF39E8011; Sat, 18 Jan 2014 14:27:06 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_91CD719D-6DDA-46F0-948F-058F2BF74CD8" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Lixia Zhang In-Reply-To: <8D0E28B63BD590E-BB0-861E@webmail-d263.sysops.aol.com> Date: Sat, 18 Jan 2014 14:27:05 -0800 Message-Id: References: <8D0E28B63BD590E-BB0-861E@webmail-d263.sysops.aol.com> To: heinerhummel@aol.com X-Mailer: Apple Mail (2.1510) Cc: rrg@irtf.org Subject: Re: [rrg] London X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 22:27:24 -0000 --Apple-Mail=_91CD719D-6DDA-46F0-948F-058F2BF74CD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 18, 2014, at 9:39 AM, heinerhummel@aol.com wrote: > Certainly, Lixia :-) >=20 > And there are many more severe points to make for sure. Against LISP, = against IPv6, against many holy paradigms, and also against the general = way to proceed.=20 > "Rough consensus and running code" has also its disadvantages, = especially if each taken step to improve creates a higher hurdle for the = over next step of improvement.=20 >=20 >=20 > Heiner Heiner, if your goal is to start a RRG discussion, here is my personal = suggestion: moving from abstract statements to structured specifics = would help get you moving, for example, listing your "more severe = points", or describe through a concrete example what is the problem as = you see with "rough consensus and running code". Lixia > -----Urspr=FCngliche Mitteilung-----=20 > Von: Lixia Zhang > An: HeinerHummel > Cc: tony.li ; rrg > Verschickt: Sa, 18 Jan 2014 7:04 am > Betreff: Re: [rrg] London >=20 > On Jan 17, 2014, at 12:05 AM, HeinerHummel@aol.com wrote: >=20 >> Lixia, >>=20 >> It was at the London 2002 IETF meeting when the request was raised to = develop a new routing architecture. Concurrently it was added " there is = no reason to rush, we will have a 10 years time frame for doing it". = Well, meanwhile 12 years have passed and all we 've got is LISP which = boasts to enable 52x10^27 EIDs per person but doesn't enhance the IPv4 = address space not by one single address. Also, it is a concept which = employs (bottle neck) servers which are vulnerable wrt. DoSA and perhaps = even due to normal overload of queries and which creates a dependency of = their clients which might cause a latent political threat by the owners = of these servers for their (helpless) clients. =20 >>=20 >> IPv6 was certainly not meant by that request in London because it = existed already at that time. And RFC 4984 =A73 even warns that it would = multifold the number of prefixes. And integrating AS-numbers seems not = good wrt prefix building either. Also: 16 octets are provided and yet a = E164 mobile user phone number is still needed outside of these 16 = octets:-(. >>=20 >> In the past I have asked many times to discuss the existing = paradigms, and to question them ! Research is questioning the obvious! = The too obvious! Like: Why are there two different routing concepts wrt = intra versus inter-domain routing? I really would like to know why is = Dijkstra bad for inter-domain ? Why isn't Distance Vector used in = intra-domain routing? >> Why is there no Multicast-FIB ? Is it because it can't hardly be like = the existing Unicast-FIB on the one hand side while on the other side a = FIB must not be any different than the existing one? >> Lixia, why would you not necessarily agree with my technical specific = of having a Multicast-FIB ? >> And also: What is the value of depending on prefix building in = unicast forwarding? After all, it doesn't work wrt Multicast nor to = Anycast (nor see above with AS#s) >>=20 >> Another very fundamental point is what we expect a network layer to = be/to look like/to handle/ to solve: >>=20 >> It is not only me, it is the entire ITU-T which thinks that the = network layer deals with the WHERE. With E164 routing and addressing are = or at least have been identical: the next-hop trunk was selected = electro-mechanically due to the next dialed digit. A routing protocol = wasn't even needed.=20 >>=20 >> It is worth to have a look to the past. I am convinced, If there were = not MPOA (but Cisco's Peer model instead) MPLS wouldn't have been = developed. Without MPLS, being a strong push of IntServ, there wouldn't = have been the counter movement DiffServ whose mantra is "do what Traffic = Engineering wanted to contribute to SVCs/LSPs without knowing the = network nor its current traffic load external to the waiting queue of = incoming packets at any router And - imho - this mantra prevents any = reasonable handling of genuine network layer objectives: like handling = traffic congestions (avoiding them if possible in the first place = dissolving them where needed). A network layer technology which has no = idea, how to direct flows such that some would bypass the congested area = to the left while some others to the right is not future prone. It is = stupid and unknowledgeable!!! >>=20 >> Heiner >=20 > Hi Heiner, >=20 > although your msg seems addressed to me, I believe you meant to bring = up the questions to the RRG, right? =20 >=20 > Lixia --Apple-Mail=_91CD719D-6DDA-46F0-948F-058F2BF74CD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 heinerhummel@aol.com = wrote:
Certainly, Lixia :-)

And there are many more severe points to make for sure. = Against LISP, against IPv6, against many holy paradigms, and also = against the general way to proceed. 
"Rough = consensus and running code" has also its disadvantages, especially if = each taken step to improve creates a higher hurdle for = the over next step of improvement. 



Lixia

lixia@cs.ucla.edu>
An: HeinerHummel <HeinerHummel@aol.com>
Cc: tony.li <tony.li@tony.li>; rrg <rrg@irtf.org>
Verschickt: Sa, 18 Jan 2014 7:04 am
Betreff: Re: [rrg] London

On Jan 17, 2014, at 12:05 AM, HeinerHummel@aol.com = wrote:

Lixia,

It was at the London 2002 IETF meeting when the = request was raised to develop a new routing architecture. Concurrently = it was added " there is no reason to rush, we will have a 10 years time = frame for doing it". Well, meanwhile 12 years have passed and all we 've = got is LISP which boasts to enable 52x10^27 EIDs per person but doesn't = enhance the IPv4 address space not by one single address. Also, it is a = concept which employs (bottle neck) servers which are vulnerable wrt. = DoSA and perhaps even due to normal overload of queries and which = creates a dependency of their clients which might cause a latent = political threat by the owners of these servers for their (helpless) = clients.  

IPv6 was certainly not meant by that request in = London because it existed already at that time. And RFC 4984 =A73 even = warns that it would multifold the number of prefixes. And integrating = AS-numbers seems not good wrt prefix building either. Also: 16 octets = are provided and yet a E164 mobile user phone number is still needed = outside of these 16 octets:-(.

In the past I have  asked many times = to discuss the existing paradigms, and to question them ! Research is = questioning the obvious! The too obvious! Like: Why are there two = different routing concepts wrt intra versus inter-domain routing? I = really would like to know why is Dijkstra bad for inter-domain ? Why = isn't Distance Vector used in intra-domain routing?
Why is there no Multicast-FIB ? Is it because it = can't hardly be like the existing Unicast-FIB on the one hand side while = on the other side a FIB must not be any different than the existing = one?
Lixia, why would you not necessarily agree with my = technical specific of having a Multicast-FIB ?
And also: What is the value of = depending on prefix building in unicast forwarding? After all, it = doesn't work wrt Multicast nor to Anycast (nor see above with = AS#s)
Another very fundamental point is what = we expect a network layer to be/to look like/to handle/ to = solve:

It is not only me, it is the entire = ITU-T which thinks that the network layer deals with the WHERE. With = E164 routing and addressing are or at least have been identical: the = next-hop trunk was selected electro-mechanically due to the next dialed = digit. A routing protocol wasn't even needed. 
It is worth to have a look to the = past. I am convinced, If there were not MPOA (but Cisco's Peer model = instead) MPLS wouldn't have been developed. Without MPLS, being a strong = push of IntServ, there wouldn't have been the counter movement DiffServ = whose mantra is "do what Traffic Engineering wanted to contribute to = SVCs/LSPs without knowing the network nor its current traffic load = external to the waiting queue of incoming packets at any router And - = imho - this mantra prevents any reasonable handling of genuine network = layer objectives: like handling traffic congestions (avoiding them if = possible in the first place dissolving them where needed). A = network layer technology which has no idea, how to direct flows such = that some would bypass the congested area to the left while some others = to the right is not future prone. It is stupid and = unknowledgeable!!!

Heiner

Hi Heiner,

although your msg seems addressed to me, I believe you meant to = bring up the questions to the RRG, right?  

Lixia

= --Apple-Mail=_91CD719D-6DDA-46F0-948F-058F2BF74CD8-- From heinerhummel@aol.com Sun Jan 19 08:17:23 2014 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2F31ADF4F for ; Sun, 19 Jan 2014 08:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.062 X-Spam-Level: X-Spam-Status: No, score=0.062 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfPVLWqii3MB for ; Sun, 19 Jan 2014 08:17:19 -0800 (PST) Received: from omr-m02.mx.aol.com (omr-m02.mx.aol.com [64.12.143.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6E78C1ADF4D for ; Sun, 19 Jan 2014 08:17:19 -0800 (PST) Received: from mtaomg-mcc01.mx.aol.com (mtaomg-mcc01.mx.aol.com [172.26.253.85]) by omr-m02.mx.aol.com (Outbound Mail Relay) with ESMTP id 069A0701CED58; Sun, 19 Jan 2014 11:17:06 -0500 (EST) Received: from core-dqa005a.r1000.mail.aol.com (core-dqa005.r1000.mail.aol.com [172.29.211.209]) by mtaomg-mcc01.mx.aol.com (OMAG/Core Interface) with ESMTP id BC7C938000085; Sun, 19 Jan 2014 11:17:05 -0500 (EST) References: <8D0E28B63BD590E-BB0-861E@webmail-d263.sysops.aol.com> To: lixia@cs.ucla.edu In-Reply-To: X-MB-Message-Source: WebUI Received: from 178.26.195.50 by webmail-d263.sysops.aol.com (205.188.16.103) with HTTP (WebMailUI); Sun, 19 Jan 2014 11:17:05 -0500 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D0E349074D32FD_AEC_45DE_webmail-d263.sysops.aol.com" X-Mailer: AOL Webmail 38289-STANDARD Message-Id: <8D0E349074AD19D-AEC-1546@webmail-d263.sysops.aol.com> X-Originating-IP: [178.26.195.50] Date: Sun, 19 Jan 2014 11:17:05 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1390148225; bh=66c/Oc9Q52AovEDzct8+9dUKXCxiyUlYSSxQsItsjjM=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=tlJEBGngcqoNkn33Wjhw32Nt21INtjAxF64htAVskqbdqayR2Q4Mr/VHgbFewXL/z Dox5e440Xa3nHsPiAqy0UZ91tRQGlW8R0y7YoD0NUCR+QVgKxFZGD9iOwaJiAznU/k ZOJ7DBfxKbyIZ8QBT9sc5KV5AFn58W6dHyWLhQD0= x-aol-sid: 3039ac1afd5552dbfa817f26 Cc: rrg@irtf.org Subject: Re: [rrg] London X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 16:17:23 -0000 This is a multi-part message in MIME format. ----------MB_8D0E349074D32FD_AEC_45DE_webmail-d263.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Structured specifics: Well, they are all presented in publication (1) and(2= ) by ICI Global, for which by the way I do not earn any single dime and whi= chI am not allowed to publish verbatimly by myself. But of course, I can re= writeall of it :-) =20 Rough consensus and running code: Certainly there is no objection to reaching consensus nor to presentingrunn= ing code, but its message is also, that long-term consequences shouldn=E2= =80=99t bother.=20 =20 Example: A LISP-ITR would attract packets by advertising prefix of length 0,given th= at the respectively needed reachability info wasn=E2=80=99t disseminated to= all. At first I had the same idea for diverting traffic to the nearest ingress T= ARArouter. Meantime I happily dumped this feature by requesting that the so= urcehost must prepend the TARA-header because an expansion of the IPv4-addr= essspace expansion (by factor 2^16) is byfar more important.=20 And yet, that would have been a race similar to the race betweencompeting e= mergency organisations which conceive their help as a business andwhich try= to snap the accident victims away from each other. Not only TARA,any other= concept would suffer given that it relied on the same default prefixpropag= ation. The right way would be to have a clean Anycast service. However this is mis= sing in IPv4 entirely, and is designed in IPv6 terribly. Thereason: With I= Pv6 the internet=E2=80=99s network-layer is not where-aware either. =20 Also: At first I took for sure that the LISP-RLOCs were also used toextend = the IPv4-address space, hence argued that LISP-DDT will never work. ThenI l= earnt that the address depletion is not of LISP=E2=80=99s concern. Differen= tbuilding plot.=20 Resum=C3=A9: an architecture is something else, isn=E2=80=99t it ? =20 Heiner =20 Publication (1) =E2=80=9ESolutions for Sustaining Scalability in Internet Growth=E2=80=9C b= yBoucadair/Binet http://www.igi-global.com/book/solutions-sustaining-scalability-internet-gr= owth/75470 , Chapter 6 thereof=20 =20 Publication (2) =20 =20 =E2=80=9ETopology Aggregating Routing Architecture (TARA): A Conceptfor Sca= lable and Efficient routing=E2=80=9C by Heiner Hummel http://www.igi-global.com/chapter/topology-aggregating-routing-architecture= -tara/77501 =20 =20 =20 disadvantages -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Lixia Zhang An: heinerhummel Cc: tony.li ; rrg Verschickt: Sa, 18 Jan 2014 11:27 pm Betreff: Re: [rrg] London On Jan 18, 2014, at 9:39 AM, heinerhummel@aol.com wrote: Certainly, Lixia :-) And there are many more severe points to make for sure. Against LISP, again= st IPv6, against many holy paradigms, and also against the general way to p= roceed.=20 "Rough consensus and running code" has also its disadvantages, especially i= f each taken step to improve creates a higher hurdle for the over next step= of improvement.=20 Heiner Heiner, if your goal is to start a RRG discussion, here is my personal suggestion: = moving from abstract statements to structured specifics would help get you = moving, for example, listing your "more severe points", or describe through= a concrete example what is the problem as you see with "rough consensus an= d running code". Lixia -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Lixia Zhang An: HeinerHummel Cc: tony.li ; rrg Verschickt: Sa, 18 Jan 2014 7:04 am Betreff: Re: [rrg] London On Jan 17, 2014, at 12:05 AM, HeinerHummel@aol.com wrote: Lixia, It was at the London 2002 IETF meeting when the request was raised to devel= op a new routing architecture. Concurrently it was added " there is no reas= on to rush, we will have a 10 years time frame for doing it". Well, meanwhi= le 12 years have passed and all we 've got is LISP which boasts to enable 5= 2x10^27 EIDs per person but doesn't enhance the IPv4 address space not by o= ne single address. Also, it is a concept which employs (bottle neck) server= s which are vulnerable wrt. DoSA and perhaps even due to normal overload of= queries and which creates a dependency of their clients which might cause = a latent political threat by the owners of these servers for their (helples= s) clients. =20 IPv6 was certainly not meant by that request in London because it existed a= lready at that time. And RFC 4984 =C2=A73 even warns that it would multifol= d the number of prefixes. And integrating AS-numbers seems not good wrt pre= fix building either. Also: 16 octets are provided and yet a E164 mobile use= r phone number is still needed outside of these 16 octets:-(. In the past I have asked many times to discuss the existing paradigms, and= to question them ! Research is questioning the obvious! The too obvious! L= ike: Why are there two different routing concepts wrt intra versus inter-do= main routing? I really would like to know why is Dijkstra bad for inter-dom= ain ? Why isn't Distance Vector used in intra-domain routing? Why is there no Multicast-FIB ? Is it because it can't hardly be like the e= xisting Unicast-FIB on the one hand side while on the other side a FIB must= not be any different than the existing one? Lixia, why would you not necessarily agree with my technical specific of ha= ving a Multicast-FIB ? And also: What is the value of depending on prefix building in unicast forw= arding? After all, it doesn't work wrt Multicast nor to Anycast (nor see ab= ove with AS#s) Another very fundamental point is what we expect a network layer to be/to l= ook like/to handle/ to solve: It is not only me, it is the entire ITU-T which thinks that the network lay= er deals with the WHERE. With E164 routing and addressing are or at least h= ave been identical: the next-hop trunk was selected electro-mechanically du= e to the next dialed digit. A routing protocol wasn't even needed.=20 It is worth to have a look to the past. I am convinced, If there were not M= POA (but Cisco's Peer model instead) MPLS wouldn't have been developed. Wit= hout MPLS, being a strong push of IntServ, there wouldn't have been the cou= nter movement DiffServ whose mantra is "do what Traffic Engineering wanted = to contribute to SVCs/LSPs without knowing the network nor its current traf= fic load external to the waiting queue of incoming packets at any router An= d - imho - this mantra prevents any reasonable handling of genuine network = layer objectives: like handling traffic congestions (avoiding them if possi= ble in the first place dissolving them where needed). A network layer techn= ology which has no idea, how to direct flows such that some would bypass th= e congested area to the left while some others to the right is not future p= rone. It is stupid and unknowledgeable!!! Heiner Hi Heiner, although your msg seems addressed to me, I believe you meant to bring up th= e questions to the RRG, right? =20 Lixia ----------MB_8D0E349074D32FD_AEC_45DE_webmail-d263.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Structured specifics: Well, they are all presented in= publication (1) and (2) by ICI Global, for which by the way I do not earn any single dime and w= hich I am not allowed to publish verbatimly by myself. But of course, I can rewr= ite all of it :-)
 
Rough consensus and running code:
Certainly there is no objection to reaching consensus= nor to presenting running code, but its message is also, that long-term consequences shouldn=E2=80=99t bother. <= /font>
 
Example:
A LISP-ITR would attract packets by advertising prefix of length 0, given that the respectively needed reachability info wasn=E2=80=99t dissemi= nated to all.
At first I had the same idea for diverting traffic to= the nearest ingress TARA router. Meantime I happily dumped this feature by requesting that the sourc= e host must prepend the TARA-header because an expansion of the IPv4-address space expansion (by factor 2^16)  is by far more important.
And yet, that would have been a race similar to the race between competing emergency organisations which conceive their help as a business a= nd which try to snap the accident victims away from each other. Not only TARA, any other concept would suffer given that it relied on the same default pre= fix propagation.
The right way would be to have a clean Anycast servic= e. However this is missing  in IPv4 entirely, and is designed in IPv6 terribly. The reason: With IPv6 the internet=E2=80=99s network-layer is not where-aware either.
 
Also: At first I took for sure that the LISP-RLOCs were also used to extend the IPv4-address space, hence argued that LISP-DDT will never work. = Then I learnt that the address depletion is not of LISP=E2=80=99s concern. Diffe= rent building plot.
Resum=C3=A9: an architecture is something else, isn=E2=80=99t it ?
 
Heiner
 
Publication (1)
=E2= =80=9ESolutions for Sustaining Scalability in Internet Growth=E2=80=9C by Boucadair/Binet
http://www.igi-global.com/book/solutions-sustaining-sca= lability-internet-growth/75470  , Chapter 6 thereof
 
Pub= lication (2)
 
 
=E2= =80=9ETopology Aggregating Routing Architecture (TARA): A Concept for Scalable and Efficient routing=E2=80=9C by Heiner Hummel
http://www.igi-global.com/chapter/topology-aggregating= -routing-architecture-tara/77501
 
 
 
dis= advantages




On Jan 18, 2014, at 9:39 AM, h= einerhummel@aol.com wrote:

Certainly, Lixia :-)

And there are many more severe points to make for sure. Against LISP= , against IPv6, against many holy paradigms, and also against the general w= ay to proceed. 
"Rough con= sensus and running code" has also its disadvantages, especially if each tak= en step to improve creates a higher hurdle for the over next step of improvement. 


Heiner

Heiner,

if your goal is to start a RRG discussion, here is my personal suggest= ion: moving from abstract statements to structured specifics would hel= p get you moving, for example, listing your "more severe points", or descri= be through a concrete example what is the problem as you see with "rough co= nsensus and running code".

Lixia

-----Urspr= =C3=BCngliche Mitteilung-----
Von: Lixia Zhang <lixia@cs.ucla.edu= >
An: HeinerHummel <HeinerHummel@a= ol.com>
Cc: tony.li <tony.li@tony.li>;= rrg <rrg@irtf.org>
Verschickt: Sa, 18 Jan 2014 7:04 am
Betreff: Re: [rrg] London

On Jan 17, 2014, at 12:05 AM, = HeinerHummel@aol.com wrote:

Lixia,
It = was at the London 2002 IETF meeting when the request was raised to develop = a new routing architecture. Concurrently it was added " there is no reason = to rush, we will have a 10 years time frame for doing it". Well, meanwhile = 12 years have passed and all we 've got is LISP which boasts to enable 52x1= 0^27 EIDs per person but doesn't enhance the IPv4 address space not by one = single address. Also, it is a concept which employs (bottle neck) servers w= hich are vulnerable wrt. DoSA and perhaps even due to normal overload = of queries and which creates a dependency of their clients which might caus= e a latent political threat by the owners of these servers for their (helpl= ess) clients.  
IPv= 6 was certainly not meant by that request in London because it existed alre= ady at that time. And RFC 4984 =C2=A73 even warns that it would multifold t= he number of prefixes. And integrating AS-numbers seems not good wrt prefix= building either. Also: 16 octets are provided and yet a E164 mobile user p= hone number is still needed outside of these 16 octets:-(.
In = the past I have  asked many times to discuss the existing pa= radigms, and to question them ! Research is questioning the obvious! The to= o obvious! Like: Why are there two different routing concepts wrt intra ver= sus inter-domain routing? I really would like to know why is Dijkstra bad f= or inter-domain ? Why isn't Distance Vector used in intra-domain routing?
Why= is there no Multicast-FIB ? Is it because it can't hardly be like the exis= ting Unicast-FIB on the one hand side while on the other side a FIB must no= t be any different than the existing one?
Lix= ia, why would you not necessarily agree with my technical specific of havin= g a Multicast-FIB ?
And also: What is the value of depending on prefix building in = unicast forwarding? After all, it doesn't work wrt Multicast nor to Anycast= (nor see above with AS#s)

Another very fundamental point is what we expect a network laye= r to be/to look like/to handle/ to solve:

It is not only me, it is the entire ITU-T which thinks that the= network layer deals with the WHERE. With E164 routing and addressing are o= r at least have been identical: the next-hop trunk was selected electro-mec= hanically due to the next dialed digit. A routing protocol wasn't even need= ed. 

It is worth to have a look to the past. I am convinced, If ther= e were not MPOA (but Cisco's Peer model instead) MPLS wouldn't have been de= veloped. Without MPLS, being a strong push of IntServ, there wouldn't have = been the counter movement DiffServ whose mantra is "do what Traffic Enginee= ring wanted to contribute to SVCs/LSPs without knowing the network nor its = current traffic load external to the waiting queue of incoming packets at a= ny router And - imho - this mantra prevents any reasonable handling of genu= ine network layer objectives: like handling traffic congestions (avoiding t= hem if possible in the first place dissolving them where needed). A ne= twork layer technology which has no idea, how to direct flows such that som= e would bypass the congested area to the left while some others to the righ= t is not future prone. It is stupid and unknowledgeable!!!

Heiner

Hi Heiner,

although your msg seems addressed to me, I believe you meant to bring = up the questions to the RRG, right?  

Lixia

----------MB_8D0E349074D32FD_AEC_45DE_webmail-d263.sysops.aol.com--