Re: [rrg] Terminology

jnc@mercury.lcs.mit.edu (Noel Chiappa) Thu, 04 February 2010 15:43 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 185C53A6C11 for <rrg@core3.amsl.com>; Thu, 4 Feb 2010 07:43:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.423
X-Spam-Level:
X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 b6PQbVLQGlhP for <rrg@core3.amsl.com>; Thu, 4 Feb 2010 07:43:48 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 00FD43A6A10 for <rrg@irtf.org>; Thu, 4 Feb 2010 07:43:47 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 846406BE5BA; Thu, 4 Feb 2010 10:44:33 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20100204154433.846406BE5BA@mercury.lcs.mit.edu>
Date: Thu, 04 Feb 2010 10:44:33 -0500
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [rrg] Terminology
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: Thu, 04 Feb 2010 15:43:49 -0000

    > From: Tony Li <tony.li@tony.li>

    > To me, CES seemed to be 'map-and-encap' and CEE was 'everything else'.

    > From: Scott Brim <scott.brim@gmail.com>

    > it seems that some approaches just don't fit in it.

If something represents a set of choices along a number of orthagonal axes
(e.g. 'map-and-encaps' plus 'invisibly map in proxies' plus 'caching
mappings' plus etc etc), then it may be useful to give that _set_ of choices
a name.

However, with terminology which labels one particular set of design choices
'{set X}', but then goes on to label everything else 'not-{set X}', the
latter term is not at all useful. It is kind of like saying that my name is
'not-Tony-Li'. The problem is that in such a system, everyone else (except
Tony :-) is also named 'not-Tony-Li' - and that is not very useful for
distinguishing among all the (very different :-) individuals who are not
'Tony Li'.

Equally importantly, if you have a design choice _axis_ (e.g. caching versus
non-caching), different points on that axis can usefully be named.

But 'not-{set X}' names are not useful.


    > From: Scott Brim <scott.brim@gmail.com>

    >> "The CES vs. CEE distinction does not arise from whether hosts are
    >> altered or not. It arises from the fundamentally different mechanisms
    >> which are used by these two different types of architecture to achieve
    >> scalable routing."

    > the two different approaches it distinguishes between are to separate
    > edge routing/addressing from non-edge and eliminating the distinction.

If your summation is right, I think I'm starting to grasp what these terms
are trying to get at, and it might be useful architectural terminology.

    > But that's just one criterion, and not every approach benefits from its
    > use.

Sure, just like the 'cache mappings' versus 'full distribution of mappings'
distinction doesn't apply if you don't have a system with things like xTRs
which handle the mapping process for large groups of entities. But that is
still an axis of architectural choice, just one that doesn't apply to all
potential designs.

But even if CEE/CES does not apply in all cases, that does not mean it is not
an axis (as opposed to a description of a particular set of design choices).
>From your summation above, it seems like it might be...

	Noel