Network Complexity Research Group - Agenda Minutes 5 Nov 2012, 0900-1130 - Introduction and Agenda bashing Michael Behringer (MB), presenting the history of the RG, initially closed meeting with good people. Trying to find a definition of complexity, Complex versus complicated, from Jon Crowcroft. Lars suggested to bring the work to the IRTF. Here we are. What we need now is people with real experience and real problems. NCRG has been quiet, but has picked up recently. Framework from Geoff as a starting point for discussion. Going through the charter. We need objective definitions. Network complexity and protocol complexity Ideal outcome of the RG, to be input to IETF WG. Definition of complexity, so that we can compare protocols to select. Complexity is not necessarily a bad thing, what we do not want is gratuitous complexity. Maybe protocol complexity is easier to define than network complexity. Use cases: we don't know precisely what complexity it, but we can recognize it when we see it and we can document it. No comments about the agenda. About possible documents: - Framework draft - RFC3439 bis - use cases (2 drafts?) - definition of complexity (2 drafts?) Carlos Pignataro (CP): What is a use case draft? what do you have in mind? MB: Catastrophic failure documented, went to the root cause in detail. Describing the entire thing, the dependencies what lead to the failure. CP: You are tracing the failure to the complexity but you don't have a definition MB: I want to start from the case where complexity causes a failure. CP: It is not obvious that any catastrophic allure can lead link to complexity Lee howard: There is an inference that complexity leads to unpredictability, sometimes things are unpredictable in a good way. Maybe it can lead to good things. MB: Dave Meyer, concept of anti-fragility, in the case of the human body, diseases make me stronger, in a similar direction, so we agree. - "Modelling Complexity of Enterprise Routing Design": Xin Sun (Florida International University), Sanjay Rao (Purdue University) and Geoffrey Xie (Naval Postgraduate School). Xin Sun presenting. Some work on complexity metrics, but it is not clear how to use it for network design. The work is given a complexity metric, integrate it in network design. Focus in routing design. Metric used: number of dependencies in configuration file Brian Dickson: Comparing same design implemented in different type of devices could be useful as well. CP: In my experience configs with more references, is sometimes simpler. The simplest approach is NOT a config without references. Sometimes modularize a piece of configuration and reference it from multiple places makes it easier. MB: This is what is studied in the software community. CP: is there any analysis between this measure of complexity and things going wrong in real networks. Xin: No, we haven't made this stuffy. MB: Slide 12, Reachability matrix is not symmetric, is this intentional: Xin: in reality, it may not be symmetric, as the operator want to protect a set of server, a subnet cannot access those servers, but the servers can access the subnets. Russ White: access list to block route from coming back, in reality there is at least 3 ways you can do that and depends on how many routes you want filter, community, /24 filter or tag. Just doing the semantics doesn't represent the complexity. Second comment, there is a second level of complexity, you are removing information in the redistribution, that could appear to be a simplification. You may want to try what it does rather than model the line count, maybe a good way of doing. MB: maybe we are measuring different things, this is about config complexity. It may not be a bad thing that using different tools you end up with different results. In the case of tags versus access list, if you compare the two configs using this, the outcome would be the expected one. MB: question to all in the room. Xin has tried this with a specific network, is there anybody who could provide network data to validate the assumption of the work and check if the results are correct. There is a tool to see a graphical picture to see the network complexity. ??: Are there some dependencies that are good dependencies and others that are related to complexity? CP: How much of the config has to do with your ultimate goal? DIsconnect between network complexity and the number of dependencies. ??: are there examples where the design is simple but the config is complex? Steven ??: The question is misphrased, the problem is what do you do with the output of this complexity analysis. How does this impacts costs, availability, reliability or anything that the costumer cares about? How it maps into an operational metric. ??: more time to configure changes and higher costs and harder to maintain, error prone. Al Morton: the distinction between config complexity and network complexity. Config complexity is bad because is error prone. Second thing, CP can be the liaison with the performance metrics directorate, to help to define the metric. BD: you may want to measure, human induced error probability. The scope of the failure if someone does the wrong thing. MB: we also need to look into hardware dependencies. Lee howard: I am interesting on pressing this work forward and link between the results of the model and tickets of network problems. One of the use cases that i have been trying to apply this is firewalls or a switched network (e.g. data center network). RW: I offer as a liaison with the routing area directorate. We need to look at control plane complexity. It is an issue of state versus stretch. Steven ??: complexity as an input, how does it impact ops costs? MB: there is a tradeoff, complexity versus (availability, costs, debuggability or all of them). How many axis of complexity do you have? - "A framework for network complexity": Michael Behringer, Geoff Huston. The idea is to frame the work of the group, define milestones, steps in the right direction. Ken Kalvert ?: multicast and TE fits into the classes MB: we are not capturing it completely yet. Steven ??: How many administrations are involved in running the network? MB: this is not covered, is an organizational level. Kirietti Kompella: most of the problems start with human operator. Dependencies and interactions. CP: exposed complexity, exposed to the human, exposed complexity is totally different than complexity. Sanjay: Add a section of validation of complexity metric - Next steps