Re: [ncrg] New Draft: Network Complexity Framework

ken carlberg <carlberg@g11.org.uk> Wed, 24 October 2012 13:04 UTC

Return-Path: <carlberg@g11.org.uk>
X-Original-To: ncrg@ietfa.amsl.com
Delivered-To: ncrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF2721F88A7 for <ncrg@ietfa.amsl.com>; Wed, 24 Oct 2012 06:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.965
X-Spam-Level:
X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599]
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 xYZ2vOCNdPfa for <ncrg@ietfa.amsl.com>; Wed, 24 Oct 2012 06:04:39 -0700 (PDT)
Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id CEE3A21F889A for <ncrg@irtf.org>; Wed, 24 Oct 2012 06:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=4ftmFJCdcrD5yyGcGRMjvxfKPZMWUcUrmxH/0gqEITI=; b=dKm5++lW0zTGtqK93YO1aBog4WU1t4XPPbtSaFc4RzCSqX0iQAod8zj3NvZ/7FyCWNnqeAhle0keOZNF3nOdk5A2OtRuOLcLYXHT2A3E8Lofe5nsZW3S7S8AnaAV/Xpk;
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:62814 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from <carlberg@g11.org.uk>) id 1TR0dP-0002NN-7x; Wed, 24 Oct 2012 13:04:35 +0000
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: ken carlberg <carlberg@g11.org.uk>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F5726EB@xmb-rcd-x14.cisco.com>
Date: Wed, 24 Oct 2012 09:04:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <AE32DAB2-0254-4901-9EE6-DCA13DD432EA@g11.org.uk>
References: <20121023173616.7A0A3BDC@m0005296.ppops.net> <82A29460-1205-4403-A49E-AE84020629B1@g11.org.uk> <3AA7118E69D7CD4BA3ECD5716BAF28DF0F5726EB@xmb-rcd-x14.cisco.com>
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>
X-Mailer: Apple Mail (2.1283)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - irtf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: "ncrg@irtf.org" <ncrg@irtf.org>, "surfer@mauigateway.com" <surfer@mauigateway.com>
Subject: Re: [ncrg] New Draft: Network Complexity Framework
X-BeenThere: ncrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Complexity Research Group <ncrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/ncrg>, <mailto:ncrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/ncrg>
List-Post: <mailto:ncrg@irtf.org>
List-Help: <mailto:ncrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/ncrg>, <mailto:ncrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2012 13:04:40 -0000

Hi Michael,

> Ken: The department of computer science in the university of Cambridge would likely see themselves as stub and the university as transit. Conversely, a large tier-1 SP might consider JANET a stub network.
> 
> But again, one step back, what does this classification add to the draft? 

originally, I was just responding to the one side comment instead of its focus on the draft itself.  However, within the context of framework draft, I would use the second sentence of your draft as a starting point ...

     "Network designers generally seek to find the simplest design
     that fulfils a set of requirements."

...and I would take the position that such a design, and its complexity, is influenced in terms of whether its a stub or transit domain.  As an example, I would probably have more elaborate mechanisms for traffic engineering in the transit network (eg, deploying MPLS) that I would not find in most stubs.  I would also probably have more fault tolerant server-based services in my stub (eg, if "I" was a bank) than I would in a transit.  I would also have different policies about firewalled services for the different types of networks -- eg, transits being more open in terms of the type of traffic going through the network while stubs having more restrictions (eg, dropping all ping packets).

But I'll easily concede that these distinctions can be quite blurry at times, with a significant factor being the size and other characteristics of the network (ie, services offered, topological distribution, etc.).  Hence, I would qualify the above paragraph in terms of a probability or propensity when distinguishing stubs from transits.

-ken

ps, and I would disagree your characterizations about Cambridge and JANET, but that is something we can talk about over a pint sometime :-)