Subject: Re: [ncrg] New Draft: Network Complexity Framework

From: "Scott Weeks" <[email-masked]>
Date: Tue, 23 Oct 2012 17:36:16 -0700

::  As I have experienced, today networks can be classified 
:: into Telecom & Enterprise ones.

I'm not so sure about that.  In this situation if it's not a 
telcom network it must be an enterprise network.  What about 
gov't/DoD networks?  They're not either as far as I can tell.
In which category would you put university networks?  They're
not enterprise.  Maybe we need to define enterprise network?

scott

--- [email-masked] wrote:

From: Rana Sircar <[email-masked]>
To: "Michael Behringer (mbehring)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ncrg] New Draft: Network Complexity Framework
Date: Sun, 21 Oct 2012 22:05:34 +0530

Hi Michael,

Thanks for the very nice Draft. The Draft is quite informative &
thought-out.

Here are my 2 cents:
• As I have experienced, today networks can be classified into Telecom &
Enterprise ones. Most of the large networks are Brown-field networks & to a
lesser % we have Green-field scenarios. This is well covered in the Draft,
where you talk of backward compatibility. That apart, networks have also
got to be differentiated based on Access (Radio or Cable or mix) or Metro /
Core & Signaling. This is important since the Constraints & Design goals
are very different for each & thereby the complexity.
• Requirements for Network Design is typically the first stage. Based on
requirements the projects are undertaken. The next obvious stages are
Architecture, Planning, Design, Implementation & Operations / Management.
Complexity plays an important role at all these stages. Ability to measure
Complexity or put some order to it is important.
• This brings in an important measure of complexity in any network –
Interfaces – number of interfaces and or the types of interfaces. Consider
a hypothetical scenario - A completely homogeneous network that is almost
Plug & Play. This would be the simplest to Architect, Implement & maintain.
The other ends of the spectrum are the networks where everything changes
dynamically all the time.
• You do mention ”Good, Fast, Cheap”, but from Complexity perspective Good
becomes a bit difficult to measure – How Good is Good or Or Bad is it. This
was written in 1996. In 2012, many technologies are already commoditized
and as any PM would mention, Scope should play a big role. So, no wonder
that the PM looks at Scope, Cost & Time.

I noticed that you are open to co-authors. I am not sure if you would
accept me as a co-author since I am between jobs. But needless to say, I
would be very keen to contribute, if allowed.

Best Regards,
Rana Pratap Sircar
GSM+919899003705|

On 15 October 2012 22:16, Michael Behringer (mbehring)
<[email-masked]>wrote:

> Complexity group,
>
> As promised a long time ago, finally I created a first draft of the
> framework document:
> http://tools.ietf.org/html/draft-behringer-complexity-framework
>
> Please note that this document is VERY draft. It needs a lot of additions,
> references to existing research, etc. There is a lot more existing material
> that should be referenced. I didn't have the time to do this before the
> deadline, and would indeed be very happy if some people would step forward
> and help make this document more complete.
>
> If you can help (as a co-author) to make this document valuable, please
> shout! :-)
>
> Any comments, suggestions, references, please reply-all!
>
> To be discussed in our meeting on the 5th of November.
>
> Michael
>
> _______________________________________________
> ncrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/ncrg
>

_______________________________________________
ncrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/ncrg

---

From: ken carlberg <[email-masked]>
Date: Wed, 24 Oct 2012 07:05:54 -0400

one could use the broader term, transit and stub networks.  Government/DoD networks can be viewed in this form, though Wikipedia (which is not the definitive answer on all things :-) would say that transit networks like DISN is an "enterprise" network.  I'm also more used tot he term "stub" network instead of enterprise, but its really a function of the terms we're first exposed to.

I would also view most universities like UCL and Cambridge as "enterprise" or "stub" networks, and JANET as the transit network connecting them to the rest of the Internet.

-ken

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 24 Oct 2012 12:25:47 +0000

A small step back: Why is it important that we classify networks that early in the game? I would argue that a good metric should apply to any network type? It seems to me that if we stick to generic terms that apply to any network, the research would be easier to use in different environments? 

In the use cases of course I'd expect concrete examples. 

But, I'm open to suggestions. Rana made the original comment: What would you propose to add/change in the draft? I'm not entirely clear on that. 

Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ken carlberg
> Sent: 24 October 2012 13:06
> To: [email-masked]
> Cc: [email-masked]
> one could use the broader term, transit and stub networks.
> Government/DoD networks can be viewed in this form, though Wikipedia
> (which is not the definitive answer on all things :-) would say that transit
> networks like DISN is an "enterprise" network.  I'm also more used tot he
> term "stub" network instead of enterprise, but its really a function of the
> terms we're first exposed to.
> 
> I would also view most universities like UCL and Cambridge as "enterprise"
> or "stub" networks, and JANET as the transit network connecting them to
> the rest of the Internet.
> 
> -ken
> 
> 
> > I'm not so sure about that.  In this situation if it's not a telcom
> > network it must be an enterprise network.  What about gov't/DoD
> > networks?  They're not either as far as I can tell.
> > In which category would you put university networks?  They're not
> > enterprise.  Maybe we need to define enterprise network?
> >
> > scott
> >
> >
> > * As I have experienced, today networks can be classified into Telecom
> > & Enterprise ones. Most of the large networks are Brown-field networks
> > & to a lesser % we have Green-field scenarios. This is well covered in
> > the Draft, where you talk of backward compatibility. That apart,
> > networks have also got to be differentiated based on Access (Radio or
> > Cable or mix) or Metro / Core & Signaling. This is important since the
> > Constraints & Design goals are very different for each & thereby the
> complexity.
> > * Requirements for Network Design is typically the first stage. Based
> > on requirements the projects are undertaken. The next obvious stages
> > are Architecture, Planning, Design, Implementation & Operations /
> Management.
> > Complexity plays an important role at all these stages. Ability to
> > measure Complexity or put some order to it is important.
> > * This brings in an important measure of complexity in any network -
> > Interfaces - number of interfaces and or the types of interfaces.
> > Consider a hypothetical scenario - A completely homogeneous network
> > that is almost Plug & Play. This would be the simplest to Architect,
> Implement & maintain.
> > The other ends of the spectrum are the networks where everything
> > changes dynamically all the time.
> > * You do mention "Good, Fast, Cheap", but from Complexity perspective
> > Good becomes a bit difficult to measure - How Good is Good or Or Bad
> > is it. This was written in 1996. In 2012, many technologies are
> > already commoditized and as any PM would mention, Scope should play a
> > big role. So, no wonder that the PM looks at Scope, Cost & Time.
> >
> > accept me as a co-author since I am between jobs. But needless to say,
> > I would be very keen to contribute, if allowed.
> >
> > Best Regards,
> > Rana Pratap Sircar
> > GSM+919899003705|
> >
> >
> >> Please note that this document is VERY draft. It needs a lot of
> >> additions, references to existing research, etc. There is a lot more
> >> existing material that should be referenced. I didn't have the time
> >> to do this before the deadline, and would indeed be very happy if
> >> some people would step forward and help make this document more
> complete.
> >>
> >> If you can help (as a co-author) to make this document valuable,
> >> please shout! :-)
> >>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 24 Oct 2012 12:28:53 +0000

Ken: The department of computer science in the university of Cambridge would likely see themselves as stub and the university as transit. Conversely, a large tier-1 SP might consider JANET a stub network.

But again, one step back, what does this classification add to the draft? 

Michael

---

From: ken carlberg <[email-masked]>
Date: Wed, 24 Oct 2012 09:04:36 -0400

Hi Michael,

> But again, one step back, what does this classification add to the draft? 

originally, I was just responding to the one side comment instead of its focus on the draft itself.  However, within the context of framework draft, I would use the second sentence of your draft as a starting point ...

     "Network designers generally seek to find the simplest design
     that fulfils a set of requirements."

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

But I'll easily concede that these distinctions can be quite blurry at times, with a significant factor being the size and other characteristics of the network (ie, services offered, topological distribution, etc.).  Hence, I would qualify the above paragraph in terms of a probability or propensity when distinguishing stubs from transits.

-ken

ps, and I would disagree your characterizations about Cambridge and JANET, but that is something we can talk about over a pint sometime :-)

---

From: Russ White <[email-masked]>
Date: Sun, 28 Oct 2012 08:57:24 -0400

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

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

---

From: "Youell, Stephen" <[email-masked]>
Date: Mon, 29 Oct 2012 09:43:19 +0000

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) to flush the complexity out!

Steve.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ White
Sent: Sunday, October 28, 2012 12:57 PM
To: [email-masked]
Subject: Re: [ncrg] New Draft: Network Complexity Framework

Russ

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 29 Oct 2012 14:17:15 +0000

> Youell, Stephen
> Sent: 29 October 2012 10:43
> To: [email-masked]'
> 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

> Russ White
> > ...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--
> And so on... The only real "stub" is a host (and even then things that look
> like a host might actually transit).
> 
> Russ

---

From: "Rana Pratap Sircar" <[email-masked]>
Date: Tue, 30 Oct 2012 22:10:17 +0530

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

To:  <mailto:[email-masked]> [email-masked]

 

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

Russ

ncrg mailing list

 <mailto:[email-masked]> [email-masked]

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

ncrg mailing list

 <mailto:[email-masked]> [email-masked]

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