Re: [rrg] London

Lixia Zhang <lixia@cs.ucla.edu> Sat, 18 January 2014 22:27 UTC

Return-Path: <lixia@cs.ucla.edu>
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 <rrg@ietfa.amsl.com>; 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 <rrg@ietfa.amsl.com>; 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 <rrg@irtf.org>; 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 <lixia@cs.ucla.edu>
In-Reply-To: <8D0E28B63BD590E-BB0-861E@webmail-d263.sysops.aol.com>
Date: Sat, 18 Jan 2014 14:27:05 -0800
Message-Id: <D51839A5-161F-48D6-A5BE-702DC592EAAE@cs.ucla.edu>
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 <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg/>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jan 2014 22:27:24 -0000

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, 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. 
> 
> 
> 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üngliche Mitteilung----- 
> Von: Lixia Zhang <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 §3 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