Re: [ncrg] New Draft: Network Complexity Framework

"Youell, Stephen" <> Mon, 29 October 2012 09:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C09221F84CE for <>; Mon, 29 Oct 2012 02:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IOWyKhz+TsxC for <>; Mon, 29 Oct 2012 02:43:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8B8C321F84A7 for <>; 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 ([]) by with ESMTP; 29 Oct 2012 05:43:20 -0400
From: "Youell, Stephen" <>
X-sendergroup: RELAYLIST
Received: from ([]) by with ESMTP; 29 Oct 2012 05:43:20 -0400
Received: from ([]) by ([]) with mapi; Mon, 29 Oct 2012 09:43:20 +0000
To: "''" <>
Date: Mon, 29 Oct 2012 09:43:19 +0000
Thread-Topic: [ncrg] New Draft: Network Complexity Framework
Thread-Index: Ac21C9akx/gXOYSlQFakBABBanzYNwApWwEA
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-GB
Content-Language: en-US
acceptlanguage: en-US, en-GB
x-wiganss: ID004D<>
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Complexity Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.

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 ( to flush the complexity out!


-----Original Message-----
From: [] On Behalf Of Russ White
Sent: Sunday, October 28, 2012 12:57 PM
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 and into, the "outside world" sees the aggregate as a stub. But
within the aggregation space --where the longer prefixes live-- could well transit for

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

ncrg mailing list