Re: [rrg] RRG to hibernation

jnc@mercury.lcs.mit.edu (Noel Chiappa) Mon, 12 November 2012 16:15 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8A421F8561 for <rrg@ietfa.amsl.com>; Mon, 12 Nov 2012 08:15:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.514
X-Spam-Level:
X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFk9Af8rZeAD for <rrg@ietfa.amsl.com>; Mon, 12 Nov 2012 08:15:38 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id D7A3721F8531 for <rrg@irtf.org>; Mon, 12 Nov 2012 08:15:38 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4BC8418C0C3; Mon, 12 Nov 2012 11:15:36 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20121112161536.4BC8418C0C3@mercury.lcs.mit.edu>
Date: Mon, 12 Nov 2012 11:15:36 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [rrg] RRG to hibernation
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.12
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: Mon, 12 Nov 2012 16:15:39 -0000

    > From: "Christian Huitema" <huitema@huitema.net>

    > Indeed, any substantial change in routing and addressing would most
    > probably end up changing all hosts, or at least most of them.

Not necessarily, provided that the identity/location mapping layer is
deployed as a set of middleboxes (as opposed to being instantiated in all the
hosts). One of the benefits from that deployment model is that a new location
namespace can be deployed invisibly to the hosts.

And of course the routing is invisible to the hosts at the moment anyway, so
changing that without the hosts noticing is almost inevitable.


    > I also think that a research group should not necessarily shy away from
    > investigations that affect all hosts. If research comes out with a
    > brilliant shiny star on the horizon, then engineering might follow.

You're correct about that. I guess I didn't clearly distinguish in my
previous message between research and engineering. From the engineering
perspective, a design which requires changes to all hosts is, IMO, a
non-starter.

But at the same time, I definitely am already a follower of the model that,
if all we do is "hack on the edges of current solutions" without some larger
vision of where we are going in the long term (and that's often, or usually,
missing, in many of the incremental changes), those many small incremental
changes will result in nothing more than 'architecture cancer'. So, to me, a
"brilliant shiny star on the horizon" really is a requirement; you have to
know where you're going in the long term, and that destination has to be a
clear, clean, functional architecture. So perhaps we're not so far apart,
actually?

But in the end, as a practical matter, to get anything done, the path there
has to consist of many small steps, each of incremental nature...


	Noel