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)