Re: [ncrg] Meeting Notes from Today's NCRG Call

"Michael Behringer (mbehring)" <> Tue, 14 May 2013 17:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88A4B21F909A for <>; Tue, 14 May 2013 10:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.3
X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yM1805IFn8Rp for <>; Tue, 14 May 2013 10:03:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E179D21F9049 for <>; Tue, 14 May 2013 10:03:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1983; q=dns/txt; s=iport; t=1368550985; x=1369760585; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/OI5RU1h9a5In/rgCJGMq+9WrtkUVxxPb1Buc8dj9gQ=; b=c6aBH6CKLzab6l2zk+ye6WysArOOhW6XWzxoORkelHHntWQoSslgaGXo fBiXg1DjvbI0J9J8UIQDHbgaz7oTuIsMoLgMrlBSLGV1aQu5zdu4CDIZP dMOYY1LUpcI4OKzPgmuy8Pt80OXN/kqylSTNhBSccJtwwKdLkDDcDa5XQ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEFALNtklGtJV2Z/2dsb2JhbABagwfAYoEAFnSCHwEBAQMBOkQLAgEIIhQQMiUBAQQBGod+Bq5sjyuNW4ESOIJ0YQOocYMPgic
X-IronPort-AV: E=Sophos;i="4.87,671,1363132800"; d="scan'208";a="210361742"
Received: from ([]) by with ESMTP; 14 May 2013 17:02:38 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r4EH2cqM023511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Tue, 14 May 2013 17:02:38 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Tue, 14 May 2013 12:02:38 -0500
From: "Michael Behringer (mbehring)" <>
To: "Alvaro Retana (aretana)" <>, "" <>
Thread-Topic: [ncrg] Meeting Notes from Today's NCRG Call
Thread-Index: Ac5QtoQHlT7cKX86SVC6tqZM0LbSyQAFDUYAAAHMOzA=
Date: Tue, 14 May 2013 17:02:37 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [ncrg] Meeting Notes from Today's NCRG Call
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: Tue, 14 May 2013 17:03:24 -0000

> Our draft (draft-retana-network-complexity-framework) shows tradeoffs
> (which may result in potential metrics) related to network design.
> I agree that the framework should describe different types of
> design complexity being one of them.  My only
> concern with including all forms of complexity, their description, metrics,
> tradeoffs, etc. in one document is simply scope creep: we'll try to cover too
> much and never finish.  The topic is already complex enough (pun
> intended)!
> IMHO, I would prefer the main framework document to briefly describe the
> different forms (operational, design, etc.)..but then to have standalone
> documents that supplement it by going deeper into a specific form and
> describing the tradeoffs and maybe potential metrics.

I think we agree. Obviously the framework will not be able to be exhaustive; I would like to define categories, and a list of examples in each category, with a brief discussion. Deeper analysis of a single metric, or exhaustive trade-off discussions should be in separate documents. 

I guess the question is where we draw the line. Open for discussion. Your cases are right on the border: As they are, they could be going into either, as I see it -  a bit more compact in the framework, or a bit more extensive in a separate doc. 

Do you agree? 

On the "categorisation" we need to think whether this is reasonably possible. Today I was looking at all the metrics mentioned in both documents; they range from very high-level ones like "cost" or "scalability" to much more specific ones like "control plane state". We could probably come up with even more deep metric, such as "peer state for IPsec tunnels" or whatever. Where do we draw the line? Does it make sense to list very high level metric alongside really detailed ones? Not clear to me right now... Ideas? 

> My 2c.
> Alvaro.