Re: [ncrg] New Draft: Network Complexity Framework

["Rana Pratap Sircar" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
Youell, Stephen
Sent: 29 October 2012 15:13
To: '[e-mail]'
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:[e-mail]> [e-mail] [
<mailto:[e-mail]> mailto:[e-mail]] On Behalf Of
Russ White

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

To:  <mailto:[e-mail]> [e-mail]

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:[e-mail]> [e-mail]

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

_______________________________________________

ncrg mailing list

 <mailto:[e-mail]> [e-mail]

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