Re: [rrg] London

Heiner Hummel <heinerhummel@aol.com> Sat, 11 January 2014 20:24 UTC

Return-Path: <heinerhummel@aol.com>
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 <rrg@ietfa.amsl.com>; 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 <rrg@ietfa.amsl.com>; 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 <rrg@irtf.org>; 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 <heinerhummel@aol.com>
In-Reply-To: <E371C7FE-F5F1-459A-93E6-6C0A5C008630@tony.li>
Date: Sat, 11 Jan 2014 21:24:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <69AE8596-8E77-4CC9-B7DA-5F0105D8E6E9@aol.com>
References: <E371C7FE-F5F1-459A-93E6-6C0A5C008630@tony.li>
To: Tony Li <tony.li@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 <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, 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


 



Am 09.01.2014 um 10:12 schrieb Tony Li <tony.li@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 willing to present in London?  It's coming very soon…
> 
> Thanks,
> Tony
> 
> _______________________________________________
> rrg mailing list
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg