[ncrg] Minutes from the last NCRG Meeting

"Michael Behringer (mbehring)" <mbehring@cisco.com> Mon, 24 March 2014 15:54 UTC

Return-Path: <mbehring@cisco.com>
X-Original-To: ncrg@ietfa.amsl.com
Delivered-To: ncrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8CC791A0232 for <ncrg@ietfa.amsl.com>; Mon, 24 Mar 2014 08:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.81
X-Spam-Status: No, score=-6.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0Y8_VsxO-ofg for <ncrg@ietfa.amsl.com>; Mon, 24 Mar 2014 08:53:50 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 35DDD1A0239 for <ncrg@irtf.org>; Mon, 24 Mar 2014 08:53:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21398; q=dns/txt; s=iport; t=1395676423; x=1396886023; h=from:to:subject:date:message-id:mime-version; bh=FK0HsYj9oLvM/rqw9UOvsgNpCCMulwyK2lw0H6m5Us4=; b=LRXKrQ7Ood0ht+2R5CMh3pwc8FVtkg7HafhgHO3gCLG6FVddOQR0QiHp bR3uxPO7EmE2qtSDrKPfxUKNNZS1+lIWBx7CbmYn/30PpEVlr+LhLhtYi 5qv4c3tk4SYbz1j//0vh+xcXGDWbVWKAaEFcvDf461h/jY8qQN+tDqCLz k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AioFAOZUMFOtJV2Z/2dsb2JhbABPCoJCRDtXwm2BGhZ0gicBAgItRRkBKlYmAQQbAYdwDZ0DsUgXjh4rg1yBFASUGkSWHYMtgWkEPg
X-IronPort-AV: E=Sophos; i="4.97,721,1389744000"; d="scan'208,217"; a="29903185"
Received: from rcdn-core-2.cisco.com ([]) by alln-iport-5.cisco.com with ESMTP; 24 Mar 2014 15:53:26 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com []) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2OFrQcO014974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <ncrg@irtf.org>; Mon, 24 Mar 2014 15:53:26 GMT
Received: from xmb-rcd-x14.cisco.com ([]) by xhc-aln-x10.cisco.com ([]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 10:53:26 -0500
From: "Michael Behringer (mbehring)" <mbehring@cisco.com>
To: "ncrg@irtf.org" <ncrg@irtf.org>
Thread-Topic: Minutes from the last NCRG Meeting
Thread-Index: Ac9HePJ4WxjwQwP8Qh2Le1su7pHq2A==
Date: Mon, 24 Mar 2014 15:53:25 +0000
Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9C2B82@xmb-rcd-x14.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9C2B82xmbrcdx14ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ncrg/Jv5J3G0s-8jChxPp6m_YdCo1zyc
Subject: [ncrg] Minutes from the last NCRG Meeting
X-BeenThere: ncrg@irtf.org
X-Mailman-Version: 2.1.15
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: Mon, 24 Mar 2014 15:54:02 -0000

Thanks a lot to Jean Mahoney, who took notes at the meeting, see below.

If you have any comments, please respond here. If there are no notes, I'll upload those minutes on Thu.



Network Complexity Research Group (NCRG)

Tuesday, March 4th; 1610-1840  Afternoon Session III, Park Suite

Agenda bashing and current status of RG
Presentation: http://www.ietf.org/proceedings/89/slides/slides-89-ncrg-0.pptx
Presenter: Michael

Michael presented chair slides

Macro Trends: Complexity and SDN
Presentation: https://datatracker.ietf.org/meeting/89/materials.html#wg-ncrg
Presenter: Dave Meyer

Canceled: Dave Meyer was not able to make it.

Tradeoffs in Network Complexity
Draft: draft-irtf-ncrg-network-design-complexity-00
Presentation: http://www.ietf.org/proceedings/89/slides/slides-89-ncrg-1.pptx
Presenter: Russ White

No questions

Michael - how to take it forward? No one can disagree with the info presented. How to help network designers?

Russ - the more tradeoffs that we can document, the better. We'll have to close the draft at some point. It would be nice to find a structure around here are 5 categories and then one example in each one. Then we could expand later.

Alvaro - the network is a system with multiple axes. When you mentioned metrics. I don't think we can come up with a number.

Russ - if the draft guides the researcher to look at tradeoffs.

Alvaro - For example, if I reduce control plane by 50% but also reduce optimality by 30%, can look at it further.

Michael - I think people agree that a single metric won't work, but we can look at a particular metric and talk about how it changes.

Russ - state vs stretch - how can a researcher measure that?

Alvaro - what is driving the decisions is subjective. Identify tradeoffs, then what comes after? What's the carrot to make it palatable for network design. Look at it not only the research perspective, but also from the engineering perspective.

Russ - also modeling networks to find non-obvious dimensions.

Michael - are there metrics in the draft?

Russ - There are metrics around routing state.

Michael - I think we should document those. Look at the metrics for one example. If you have 2 sites, tunneling is easier, when you have 500, it's not.

Russ - in this draft or separate?

Michael - this draft.

Alvaro - I say no. Document the tradeoffs here. Add a separate draft.

Dirk - Can you compare the complexity of different approaches to various use cases. Like service chaining.

Russ - good idea - spring vs openflow vs MPLS for service chaining. Look at one use case and think of all the ways to do it.

ACTION: Michael - if you have any ideas, please post to the list or create a draft.

Complexity: the good, the bad and the ugly
Presentation: http://www.ietf.org/proceedings/89/slides/slides-89-ncrg-2.pdf
Presenter: Dimitri Papadimitriou

Dimitri - This is a starting point for a research perspective

Michael - Many of the keywords are in the framework draft. What do you mean "agree" on this slide (slide 14 Conclusion)?

Dimitri - it's not IETF consensus - do we have a common definition of the property. What is the common bottom line for minimal resiliency for instance?

Michael - we don't have to agree on how resilient something has to be.

Russ - We need to agree that resiliency includes/doesn't include micro-loops. We need to put it down.

Dimitri - we have an engineering definition of resiliency, there's a biological definition - the ability to reach another, defined state. There's also the engineering definition of robustness - it can do alright for more cases, but not be able to survive a disaster.

Michael - there is a discussion in the framework draft.

Dimitri - it would be good to have document.

Alex - no, this is a research group.

Dimitri - need more meat. It's important to progress.

Russ - You mention a lot of papers in your presentation. we have a wiki with a small collection (http://networkcomplexity.org/). It would be nice to have working group reading list.

Dimitri - it's a good idea.

Michael - that was the intention of the wiki, but it died. I take your contribution as -

Russ - Volunteering?

Michael - In order to edit the wiki, I need to add you to the wiki editor list. Drop me a line if you are interested.

Dimitri - I volunteer to add a reading list.

ACTION: Michael to set up accounts for Russ and Dimitri

ACTION: Dimitri to contribute reading list to the wiki.

Michael displayed the framework draft (page 6) - is this where your resiliency definition comes in.

Dimitri - you can measure stretch. You have to have objectives to have a correct interpretation of tradeoffs.

Michael - comment on robustness - in one of the meetings several years ago - robustness is a metametric. It's robustness against something - security is robustness against attacks, scalability is robustness against growth.

Dimitri - We need to distinguish metrics - metrics are what you measure.

Michael - robustness is the goal?

Dimitri - what is your capability to evolve within certain constraints. Need a terminology section at the beginning of the document.

Michael - terminology is not currently in the doc.

Dimitri - in Section 5 - clarify function, structure and behavior. Then you can analyze it.

Michael - we'll restructure the draft. Let's discuss it.

Michael - in my opinion what you are describing - Russ - on the wire. Dimitir's higher level.

Alvaro - We are creating a relationship tree - if I change this, then that. Then we can look at dependencies and tradeoffs and how it impacts costs.

Michael - Here's the wiki. The reading list needs contributions. Here are workshops.

Dimitri - There is the USRR Workshop in Ghent, Belgium, in April to discuss the interplay between sustainability, resilience, and robustness in networks.

Michael - we could have another workshop. Who is interested in attending?

Room - Some hands

ACTION: Dimitri to send information about the meeting to the list. (http://www.internet-science.eu/usrr14)