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

jnc@mercury.lcs.mit.edu (Noel Chiappa) Fri, 22 January 2010 15:15 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 675373A6902 for <rrg@core3.amsl.com>; Fri, 22 Jan 2010 07:15:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 SWldnyKIKddS for <rrg@core3.amsl.com>; Fri, 22 Jan 2010 07:15:41 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 651F93A68D4 for <rrg@irtf.org>; Fri, 22 Jan 2010 07:15:41 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3B2C76BE579; Fri, 22 Jan 2010 10:15:36 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20100122151536.3B2C76BE579@mercury.lcs.mit.edu>
Date: Fri, 22 Jan 2010 10:15:36 -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: Fri, 22 Jan 2010 15:15:42 -0000

    > From: Patrick Frejborg <pfrejborg@gmail.com>

    > Believe we need both CEE and CES so that the end users can decide which
    > way to go, either by upgrading the hosts or add a network device in
    > front of their hosts - both approaches should be promoted

Umm, CES approaches can also often be deployed in the host (as LISP does for
mobile devices), whereas it seems (to me at least) to be not really feasible
to deploy CEE in the network.


    > you could design the architecture in a such way that it is backwards
    > compatible and only part of [the hosts] need[] to be upgraded.

That was kind of _my_ hope for LISP (although I'm not sure it's not the rest
of the LISP group shares, so please, this is only my personal opinion). I've
always viewed the LISP devices (ITRs and ETRs) as the boundary between the
'old' part of the network (one namespace, etc) and the 'new' part (separate
location/identity, etc, etc).

My further hope was that in that segregated 'new' part of the network, we
could move forward and actually deploy _new_ stuff (e.g. a new locator
syntax, or a new routing architecture). Hosts which didn't need/want direct
access to any of new capabilities would not need to upgrade.

Of course, for that strategy to succeed, it requires _minimization_ of the
number of devices on the boundary (because deploying something new inside the
'new' part means changing them, and the less of them there are, the easier to
change things). Moving the boundary to the hosts means more devices on the
boundary... so in a way I would prefer to _delay_ updating hosts!

Of course, if there are lots of hosts, there is always nested LISP (to which
my personal reaction is 'blech', but I guess when you're changing engines
in flight, some stages of the process are ugly... :-)


    > From: Robin Whittle <rw@firstpr.com.au>

    > The "simple network, sophisticated hosts" paradigm works well in many
    > respects

In pure architectural terms, it is superior. Alas, we aren't working with a
clean sheet of paper...

    > An increasing number of hosts have computational constraints due to
    > being hand-held devices with very limited battery power. ... if
    > cryptographic work is required in the CEE protocols, then I think it is
    > more of a problem.

I'm not sure this is a real problem - but it is the perfect hook for another
of my architectural observations:

In a system which is designed for a very long lifetime, design for the outer
envelope of technology today - because tomorrow's will be a lot more capable.
Yes, it has to be possible, and vaguely economic with today's technology, but
over the entire life-cycle of the technology, you'll be happier overall if
you 'push' the design, even though it may cause a little heart-burn in the
very earliest stages.

	Noel