Re: [ncrg] New Draft: Network Complexity Framework

Russ White <russw@riw.us> Sun, 28 October 2012 12:57 UTC

Return-Path: <russw@riw.us>
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 51C0D21F84B3 for <ncrg@ietfa.amsl.com>; Sun, 28 Oct 2012 05:57: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 9DwI6zn+q7Eq for <ncrg@ietfa.amsl.com>; Sun, 28 Oct 2012 05:57:31 -0700 (PDT)
Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id E39B221F84A8 for <ncrg@irtf.org>; Sun, 28 Oct 2012 05:57:28 -0700 (PDT)
Received: from [200.58.140.242] (helo=[192.168.60.139]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <russw@riw.us>) id 1TSSQg-00077C-Eq for ncrg@irtf.org; Sun, 28 Oct 2012 05:57:28 -0700
Message-ID: <508D2BB4.102@riw.us>
Date: Sun, 28 Oct 2012 08:57:24 -0400
From: Russ White <russw@riw.us>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: ncrg@irtf.org
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>
In-Reply-To: <AE32DAB2-0254-4901-9EE6-DCA13DD432EA@g11.org.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner
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: Sun, 28 Oct 2012 12:57:32 -0000

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