Re: [ncrg] New Draft: Network Complexity Framework

"Rana Pratap Sircar" <sircar.rana@gmail.com> Tue, 30 October 2012 16:40 UTC

Return-Path: <sircar.rana@gmail.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 EC63C21F870E for <ncrg@ietfa.amsl.com>; Tue, 30 Oct 2012 09:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 ZG2lBCzHehYe for <ncrg@ietfa.amsl.com>; Tue, 30 Oct 2012 09:40:29 -0700 (PDT)
Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id E2A3F21F870D for <ncrg@irtf.org>; Tue, 30 Oct 2012 09:40:28 -0700 (PDT)
Received: by mail-pb0-f54.google.com with SMTP id rp8so340654pbb.13 for <ncrg@irtf.org>; Tue, 30 Oct 2012 09:40:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=uUnRS7g5CLvEgegBPfSNSMGcD7+NpuqsV5uxJCc37SM=; b=eP7ltNZozTBgKM2K1Q3OZFMdlC8Z679EYNI6hnacyNamXz6qKpZa4e+BJZydBX4vG0 y1OrbVojFGZGv2NxmRu4Wd1G9chxrDnuNF+3HI5FDM3EZnC1tGHeN056imzMF6hXseZf yj62BSoUD09T0X5K373o0SPRcC4xhukaTkJ1pbJAhBVRxHiXI2oC1iXfsctRE6kNUEoZ NAtlxGUD80RpqKMRLk0W0hMVfM6kr91zLgOUyUiAdbzYdGKLRhhJ3a+W/zJYSd7h37ar vYvJmTpj6VPV0d4CJHA+ggOYGasLlaiD1jl8s5rrWVYI7B9O/RHmrnjECjzEkEG+qTqE Fs9w==
Received: by 10.66.88.133 with SMTP id bg5mr93733005pab.80.1351615223830; Tue, 30 Oct 2012 09:40:23 -0700 (PDT)
Received: from Diya7 ([122.161.144.12]) by mx.google.com with ESMTPS id j8sm639520paz.30.2012.10.30.09.40.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 09:40:23 -0700 (PDT)
From: "Rana Pratap Sircar" <sircar.rana@gmail.com>
To: "'Youell, Stephen'" <stephen.youell@gs.com>, <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> <508D2BB4.102@riw.us> <42A88A94924C7045B7AE694905507C6601CD4F38D6@GSCMEUP04EX.firmwide.corp.gs.com>
In-Reply-To: <42A88A94924C7045B7AE694905507C6601CD4F38D6@GSCMEUP04EX.firmwide.corp.gs.com>
Date: Tue, 30 Oct 2012 22:10:17 +0530
Message-ID: <0ddb01cdb6bd$4121f0f0$c365d2d0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0DDC_01CDB6EB.5ADDFD80"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEd/x56M4yeodFnLqCUAscD3qsKuAHt9NY/AmVRqp8BkhGSfQFsiKPVAvRIX4GY30N1oA==
Content-Language: en-in
Cc: "Michael Behringer \(mbehring\)" <mbehring@cisco.com>
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: Tue, 30 Oct 2012 16:40:32 -0000

There are a few thoughts that I would like to highlight:

1.       Interfaces: Let us look at two scenarios here:

a.       A network with a single vendor providing pure-play LTE-FDD
data-only services

b.      An IMS or VoLTE services including LTE-FDD (both are new networks)

c.       In my opinion, the second one is more complex - question is how
much more? The fact that it has more number of interfaces and more complex
signalling further complicates the matter. We can see similar comparisons
between a Campus LAN/WiFi network with a HSPA/LTE network with WiFi Offload.


2.       Number of proprietary interfaces / vendors: Compare a Greenfield
single vendor network versus a multi-vendor brown-field network with
multiple proprietary interfaces. 

3.       Configurable services provided by the network: Many networks are
created using nodes that are very flexible. During Systems Integration
phase, one would do a lot of integration & coding to create very
configurable services (VAS/SDP, Java servlet based apps for different
network services etc.). 

a.       More configurable the network is (in particular, the Control
plane), more complex it becomes in the Operations & sustenance phase. 

b.      In many operators, thus, the planning phase starts fairly innocently
with Network Planning & design. However, by the time everything is completed
(assuming that the network provides a lot of services), network would have
grown fairly complex. 

4.       Mobility: Mobility adds planning & optimization complexity (and now
even interop complexity on device & technology angles)

 

I would like to understand your views on the same.

 

Best Regards,

Rana

 

-----Original Message-----
From: ncrg-bounces@irtf.org [mailto:ncrg-bounces@irtf.org] On Behalf Of
Youell, Stephen
Sent: 29 October 2012 15:13
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.

 

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

 

Steve.

 

 

-----Original Message-----

From:  <mailto:ncrg-bounces@irtf.org> ncrg-bounces@irtf.org [
<mailto:ncrg-bounces@irtf.org> mailto:ncrg-bounces@irtf.org] On Behalf Of
Russ White

Sent: Sunday, October 28, 2012 12:57 PM

To:  <mailto:ncrg@irtf.org> 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

 <mailto:ncrg@irtf.org> ncrg@irtf.org

 <https://www.irtf.org/mailman/listinfo/ncrg>
https://www.irtf.org/mailman/listinfo/ncrg

_______________________________________________

ncrg mailing list

 <mailto:ncrg@irtf.org> ncrg@irtf.org

 <https://www.irtf.org/mailman/listinfo/ncrg>
https://www.irtf.org/mailman/listinfo/ncrg