Re: [ncrg] New Draft: Network Complexity Framework

"Michael Behringer (mbehring)" <mbehring@cisco.com> Mon, 29 October 2012 14:17 UTC

Return-Path: <mbehring@cisco.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 8E43921F8518 for <ncrg@ietfa.amsl.com>; Mon, 29 Oct 2012 07:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 7igxXj30MnWQ for <ncrg@ietfa.amsl.com>; Mon, 29 Oct 2012 07:17:34 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6019921F84A8 for <ncrg@irtf.org>; Mon, 29 Oct 2012 07:17:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3289; q=dns/txt; s=iport; t=1351520254; x=1352729854; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wmf+FBuAax7FMpSyoxgUdTtexoHfp2QOIYcLJME6rFw=; b=YeYRtUhNxTbS/9+aod3S+CZNjewHf3LNVB48gEkJbXYCWi0YJ3zP8Rx0 RROfvhigqOb3Ge3QdUMzbVb5D7THJ4whWwMqVRhEhn7xX1XBe/MCa5GmY 05RdHEA/L7txJsEDL6VmwR6yPCvWUl1IyW9NpcpHNnRhEBIjsvvlozecm 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAJOPjlCtJV2Y/2dsb2JhbAAuFsJjgQiCHgEBAQMBAQEBDwEnNBAHBAIBCBEEAQELCQsJBycLFAkIAgQBEggah14GC5w8n1SLdQOFeWEDkgiFBo09gWuCb4IZ
X-IronPort-AV: E=Sophos;i="4.80,672,1344211200"; d="scan'208";a="136448177"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 29 Oct 2012 14:17:17 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9TEHHdY021371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Oct 2012 14:17:17 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Mon, 29 Oct 2012 09:17:16 -0500
From: "Michael Behringer (mbehring)" <mbehring@cisco.com>
To: "Youell, Stephen" <stephen.youell@gs.com>, "'ncrg@irtf.org'" <ncrg@irtf.org>
Thread-Topic: [ncrg] New Draft: Network Complexity Framework
Thread-Index: AQHNsX+TV4oVMY/sT2OMTS35Feqv0JfIn+QA///CuUCAAF5xAIAGR1EAgAFcG4D///YR0A==
Date: Mon, 29 Oct 2012 14:17:15 +0000
Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F579D4E@xmb-rcd-x14.cisco.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> <42A88A94924C7045B7AE694905507C6601CD4F38D6@GSCMEUP04EX.firmwide.corp.gs.com>
In-Reply-To: <42A88A94924C7045B7AE694905507C6601CD4F38D6@GSCMEUP04EX.firmwide.corp.gs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.194.20]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19318.004
x-tm-as-result: No--46.598600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
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 14:17:35 -0000

> -----Original Message-----
> From: ncrg-bounces@irtf.org [mailto:ncrg-bounces@irtf.org] On Behalf Of
> Youell, Stephen
> Sent: 29 October 2012 10:43
> To: 'ncrg@irtf.org'
> Subject: Re: [ncrg] New Draft: Network Complexity Framework
> 
> 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.

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

Interesting thought. Could also be brought into the doc, I guess. Need to think more... Another section, on "how to debug complexity"?

Thanks for the feedback! 
Michael

 
> 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
> _______________________________________________
> ncrg mailing list
> ncrg@irtf.org
> https://www.irtf.org/mailman/listinfo/ncrg