Re: [rrg] Rebooting the RRG Wed, 05 February 2014 00:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BD3261A016A for <>; Tue, 4 Feb 2014 16:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.266
X-Spam-Status: No, score=0.266 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.535, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gx1TRfql08iN for <>; Tue, 4 Feb 2014 16:38:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2FE821A0169 for <>; Tue, 4 Feb 2014 16:38:39 -0800 (PST)
Received: from ( []) by (Outbound Mail Relay) with ESMTP id 9FDD5700444E8 for <>; Tue, 4 Feb 2014 19:38:38 -0500 (EST)
Received: from ( []) by (OMAG/Core Interface) with ESMTP id 72FFB38000086 for <>; Tue, 4 Feb 2014 19:38:38 -0500 (EST)
References: <> <> <> <> <> <>
In-Reply-To: <>
X-MB-Message-Source: WebUI
MIME-Version: 1.0
X-MB-Message-Type: User
Content-Type: multipart/alternative; boundary=""
X-Mailer: AOL Webmail 38331-STANDARD
Received: from by ( with HTTP (WebMailUI); Tue, 04 Feb 2014 19:38:38 -0500
Message-Id: <>
X-Originating-IP: []
Date: Tue, 4 Feb 2014 19:38:38 -0500 (EST)
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20121107; t=1391560718; bh=84Xwhac+VFWTsHWRPyB7EkrGCZuiEU9OBkeKfLZ+b0Y=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=clF3+CXniIpQPJphLnNDIGSGJ6ZR5270HMKkRwb8ZNy8nAu+QlB4WP4Udc/udh3Fz pkD8cQ/v5lY3qfztjt+yQnmIMyq96n4CwLMi/QFwGDZ14SjC64BeDxQwXsq7dY5Y3n 3I6dVPKxEbg5e+jjo7z5hmV1fgOQHK7yAAnKh93E=
x-aol-sid: 3039ac1a32b052f1880e7c42
Subject: Re: [rrg] Rebooting the RRG
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: Wed, 05 Feb 2014 00:38:41 -0000

Lixia excepted, I tried in vain to stimulate a discussion about the IETF's routing paradigms which I have questioned many times:

- the diffserv philosophy (the total absence of the WHERE-awareness)
- the intra-versus inter-domain distinction (Dijkstra versus distance vector)

and also about
- the absence of a MULTICAST FIB.
- the absence of a ANYCAST FIB
- the absence of (scoped) Broadcast
- the negligence of IPv4

This week the German government has been suit by the CCC because it missed/is missing to protect people against spy attacks by the US's  NSA.

With the current routing architecture and its complete absence of any WHERE-awareness there is no way to give back any country its sovereignty. 
With TARA that wouldn't be a problem: Each country would recognize "its" part of the internet (intra- and inter-domain portions alike) and could take action that within its borders packets were encrypted according to its own keys. Packets which are being sent to outside of the country would be recognized as such ones and the user might be questioned to confirm whether forwarding should be done or not - just like he is reminded  to add a subject line if missing.

Whenever an airplane crosses illegally some country, it is conceived as a violation of the respective nation's sovereignty. But spying  out  a l l   communication data is by far worse.
That crashes any nation's sovereignty. Attempts to accomplish mutual no-spy treaties show the helplessness of the German government. The right way would be  - and here is the  IETF asked to come up with results - to provide  solutions which PREVENT spy attacks as we are experiencing today in the first place!  

I know that NSA folks are as well subscribed to this list (but eventually they may have positive feeling towards Edward S. too).

I think such a security service is the most important one of all that can be based on the WHERE-awareness, much more important than to be able to redirect parts of the traffic such that they bypass some congested area to the left or to the right.

But so far no one has even tried to explain the advantages of the current architecture.


-----Ursprüngliche Mitteilung----- 
Von: Eggert, Lars <>
An: IRTF Routing RG <>
Verschickt: Di, 4 Feb 2014 7:35 pm
Betreff: Re: [rrg] Rebooting the RRG


nobody is debating that there's interesting routing research being done. We even 
gave quite a number of ANRPs (Applied Networking Research Prizes) to routing 
papers, and flew the main authors to IETF meetings to present.

What we don't seem to have is a core group of RRG participants with the energy 
of reaching out to and bringing the research that is out there into the group, 
on a continuous basis. Those of you who feel that the group should stay around, 
please realize that you need to dedicate some of your own time towards making 
that happen.


rrg mailing list