Re: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?

jnc@mercury.lcs.mit.edu (Noel Chiappa) Sun, 24 January 2010 19:47 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 172723A67D7 for <rrg@core3.amsl.com>; Sun, 24 Jan 2010 11:47:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHbas5OvzYGx for <rrg@core3.amsl.com>; Sun, 24 Jan 2010 11:47:33 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 49AD33A672F for <rrg@irtf.org>; Sun, 24 Jan 2010 11:47:33 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 5C8636BE57F; Sun, 24 Jan 2010 14:47:35 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20100124194735.5C8636BE57F@mercury.lcs.mit.edu>
Date: Sun, 24 Jan 2010 14:47:35 -0500
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/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: Sun, 24 Jan 2010 19:47:34 -0000

PS: Don't get me wrong: I think MPTCP is a great idea - in its core context,
which is to provide the ability to split a single TCP flow among multiple
interfaces/paths. So I really do hope it succeeds, because for that
application, it's clearly the right thing.

It's just when people come down with the canonical IETF disorder, and start
trying to turn it into a desert-topping/floor-wax, that I am not so thrilled.
We're all the time trying to drive screws with hammers, because our tool-box
is so poorly stocked...

Ditto HIP and a bunch of other things... great things, in their core
competencies.


And yes, there are also people proposing to try and apply LISP outside its
core competency too, and start doing routing-type things with it. Which I can
understand; they are just trying to do whatever their particular thing is,
they don't want to spend their lives populating a toolbox, when they just want
to get their particular thing to work right. So they just pull out whatever
existing tool looks like it can be kludged into doing their thing, and wail
away with it...

LISP is really intended to achieve one chief goal: to split up location and
identity, and do so in a way that is economically and deployably practical.
Yes, doing that does improve things over in the routing sphere, because now
things that people were trying to do with routing (improperly, due to
hammer-nail syndrome) can be done with a better tool.

However, LISP is still not a new routing architecture - which I claim we will
still need, when all the dust settles. And _none_ of the proposals here (well,
the Compact Routing stuff comes closest) is a new routing architecture....

	Noel