Re: [ncrg] New Draft: Network Complexity Framework

"Youell, Stephen" <stephen.youell@gs.com> Mon, 29 October 2012 09:43 UTC

Return-Path: <stephen.youell@gs.com>
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 7C09221F84CE for <ncrg@ietfa.amsl.com>; Mon, 29 Oct 2012 02:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 IOWyKhz+TsxC for <ncrg@ietfa.amsl.com>; Mon, 29 Oct 2012 02:43:21 -0700 (PDT)
Received: from mxecd09.gs.com (mxe7.gs.com [204.4.178.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8C321F84A7 for <ncrg@irtf.org>; Mon, 29 Oct 2012 02:43:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,670,1344225600"; d="scan'208";a="295255598"
Received: from unknown (HELO mxpbd01-public.ny.fw.gs.com) ([148.86.115.129]) by mxecd09.idz.gs.com with ESMTP; 29 Oct 2012 05:43:20 -0400
From: "Youell, Stephen" <stephen.youell@gs.com>
X-sendergroup: RELAYLIST
Received: from gshclcp01ex.firmwide.corp.gs.com ([10.238.48.54]) by mxpbd01.ny.fw.gs.com with ESMTP; 29 Oct 2012 05:43:20 -0400
Received: from GSCMEUP04EX.firmwide.corp.gs.com ([10.238.64.16]) by gshclcp01ex.firmwide.corp.gs.com ([10.238.48.54]) with mapi; Mon, 29 Oct 2012 09:43:20 +0000
To: "'ncrg@irtf.org'" <ncrg@irtf.org>
Date: Mon, 29 Oct 2012 09:43:19 +0000
Thread-Topic: [ncrg] New Draft: Network Complexity Framework
Thread-Index: Ac21C9akx/gXOYSlQFakBABBanzYNwApWwEA
Message-ID: <42A88A94924C7045B7AE694905507C6601CD4F38D6@GSCMEUP04EX.firmwide.corp.gs.com>
References: <20121023173616.7A0A3BDC@m0005296.ppops.net> <82A29460-1205-4403-A49E-AE84020629B1@g11.org.uk> <3AA7118E69D7CD4BA3ECD5716BAF28DF0F5726EB@xmb-rcd-x14.cisco.com> <AE32DAB2-0254-4901-9EE6-DCA13DD432EA@g11.org.uk> <508D2BB4.102@riw.us>
In-Reply-To: <508D2BB4.102@riw.us>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
x-wiganss: 01000000010020gshclcp01ex.firmwide.corp.gs.com ID004D<42A88A94924C7045B7AE694905507C6601CD4F38D6@GSCMEUP04EX.firmwide.corp.gs.com>
x-retentionstamp: Firmwide
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 29 Oct 2012 09:43:32 -0000

It sounds like a recursive model of stub/transit is generally agreed. I agree with Ken's point that complexity is driven by different functions, traffic engineering is more likely at the top of the hierarchy, load-balancing, HA and large DMZ deployments at the bottom.

Michael,
It would be worth making a point about necessary complexity. Sections 2.2 and 2.3 discuss a similar point but I think it's important to come away understanding that not all complexity is bad. Network designers tend to "overshoot" the optimum value of the complexity metric only to find they have some or all of the complexity properties when an external event such as a failure or the attempted implementation of an entirely new application or service exposes those properties.

Perhaps we need a network version of Chaos Monkey (http://techblog.netflix.com/search/label/chaos%20monkey) to flush the complexity out!

Steve.


-----Original Message-----
From: ncrg-bounces@irtf.org [mailto:ncrg-bounces@irtf.org] On Behalf Of Russ White
Sent: Sunday, October 28, 2012 12:57 PM
To: ncrg@irtf.org
Subject: Re: [ncrg] New Draft: Network Complexity Framework


> ...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).

The problem is that all networks are transit, and all networks are stub
--it all depends on who's asking the question. Think of it like
subnetting --if you aggregate 10.1.0.0/24 and 10.1.1.0/24 into
10.1.0.0/23, the "outside world" sees the aggregate as a stub. But
within the aggregation space --where the longer prefixes live--
10.1.0.0/24 could well transit for 10.1.1.0/24.

And so on... The only real "stub" is a host (and even then things that
look like a host might actually transit).

Russ
_______________________________________________
ncrg mailing list
ncrg@irtf.org
https://www.irtf.org/mailman/listinfo/ncrg