1. 1 Theophilus Benson*, Aditya Akella*, Aman Shaikh + *University of Wisconsin, Madison + ATT Labs Research

2. Adoption of Network-based Services 2 ISP Core

3. Adoption of Network-based Services 3  “By 2015, annual global IP traffic will reach 966 exabytes” [Cisco’11]  Customers adopting new applications  ISPs upgrade and purchase new equipment  Best effort ineffective for some applications

4. Adoption of Network-based Services 4 Services are a crucial part of the Internet’s ecosystem ISP Core  Host-based and network-based services  “AT&T to spend $1 billion to ramp up enterprise services”  Recover cost and improve application performance

5. Goals  Vision:  Improve service integration/upgrades  Simplify service management  Understand impediments  Service configuration files  Complexity of configuration 5 Edge ISP Core

6. Configuration is a crucial component  Configuration determines  Customer functionality  ISP interactions  Configuration is complex  Most time consuming task [Feamster ‘05 ]  Most error-prone  > 50% customer problems due to configuration errors [Yankee Group ‘04] 6 OSPF BGP

7. Configuring a Service 7 PE CE PECE a c z ISP Core Control Plane Data plane a c z a c z

8. Contributions  Analyzed 2.5 years of configurations  Show how complexity evolves over time  Worsens over time  Highlight the location of complexity  Complexity exists at the edge  Identify the cause of complexity  Due to provisioning of new customers 8 PE ISP Core CE Edge Customers Edge Customers

9. Contributions  Identified potential ways to mitigate complexity  Showed the impact of design choices on complexity 9 Vendor Complexity #1 #2 Routing Design Complexity #1 #2 #3

10. Outline  Motivation  Background  Models and Data-Set  Understanding Complexity  Mitigating Complexity  Conclusion 10

11. Configuring the Provider’s Edge  Complexity is due to:  Dependent commands 11 PE CE PECE ISP Core Ip vrf blue Rd 23234:100223 Route-target import 1000:1 Route-target export 1000:1 ! Interface ethernet1 Ip address 128.105.82.66/30 Ip vrf forwarding blue Services-policy output policy1 ! Policy-map policy1 Policy 100 20 confirm-action transmit VRF Interface Policy- map a

12. Configuring the Control-Plane Core 12 PE CE PECE Router bgp 65000 Neighbor 129.168.6.6 Neighbor 129.168.2.2 ! Ip vrf blue Rd 23234:100223 Route-target import 1000:1 Route-target export 1000:1 ! Router bgp 65000 Neighbor 129.168.2.1 ISP Core a c z a c z a c z  Complexity is due to:  Dependent commands  Maintaining consistency

13. Configuring the Data-Plane Core 13 PE CE PECE a c z a c z Interface gigethernet1 Ip address 128.105.82.66/30 ! Router ospf 2 Network 128.105.82.0/24 ! Ip vrf blue Rd 23234:100223 Route-target import 1000:1 Route-target export 1000:1 ! Interface gigethernet1 Ip address 128.105.82.65/30 ! ISP Core a  Complexity is due to:  Dependent commands  Maintaining consistency a c z

14. Models and Data-Set 14

15. Requirements for Data Models  Quantify complexity of configuration  Capture dependencies between commands  Capture consistency across devices  Use complexity metrics [Benson ‘09]  Motivated by software engineering techniques  Abstract away low level details  Abstract groups of commands  stanzas 15 Ip vrf blue Rd 23234:100223 ! Interface ethernet1 Ip address 128.105.82.66 Ip vrf forwarding blue Services-policy input policy2 !

16. Data Models  Referential Graph [Benson ‘09]  Syntactic dependencies operators must track  Network  graph of dependent stanzas  Metric: size of graph  Larger graph  more dependencies  Templates [Benson ‘09]  Clone detection used to capture uniformity 16 VRF Interface Policy- map

17. Data-Set Service% of Routers ( PE + Core) VPN48% VPLS27% VoIP5% DDoS Prev.31% Virtual Wire25% 17 Diversity allows for a comprehensive study  Collected data from tier-1 ISP for 2.5 years  5 services: VPN, VPLS, VoIP, DDoS Prev., Virtual Wire  Daily snapshots of router configuration files  Metadata (per router): vendor, role and location

18. Understanding Complexity  Provider Edge (PE) Complexity  Control-Plane Core Complexity  Data-Plane Core Complexity 18 PE ISP Core CE

19. Understanding Complexity  Provider Edge (PE) Complexity  Control-Plane Core Complexity  Data-Plane Core Complexity 19 PE ISP Core CE

20. PE Complexity over Time  Growth is due to worsening complexity  New devices have less dependencies 20 Over time, configuration tasks become tricky

21. Understanding PE Complexity  Which stanza contributes to VPLS growth? 21 Edge ISP Core VRF Interface Policy- map VRF

22. Understanding PE Complexity  Which stanza contributes to VPN growth? 22 Complexity caused by customer provisioning Edge ISP Core VRF Interface Policy- map

23. Configuration Reuse over Time 23 Specialization leads to added complexity Reuse and specialization exists Configuration overlap reduces over time –Reduction due to specialized usage of service 71% 62% 88%

24. Understanding Complexity  Data-Plane Core: service-agnostic and simple  Control-Plane Core: distinct across services  Growing number of adjacencies with PEs  PE is the most complex 24 PE ISP Core CE

25. Mitigating Complexity  Vendor Selection 25 Cost Functionality Complexity Time Complexity Time Complexity

26. How to Compare Vendors  Different vendors  different languages  Language impacts complexity  Difference in structure of functionality  Comparing vendor languages  Configurations representing same policy  Same customer  same policy on all PEs 26 PE CE PECE ISP Core Vendor1 Vendor2

27. Vendor Selection  Graph for vendor1 is consistently larger  Vendor1 requires more stanzas for same policies  Operators need to track more dependencies 27 Choice of vendor can reduce PE complexity

28. Conclusion  Studied the factors that impede services  Complexity grows over time  Modifications become time consuming  Most complexity lies in configuring customers  Varying requirements and specialized configuration  Framework to systematically consider complexity  Choice of vendor can reduce complexity 28

29. Thank You  Theophilus Benson (tbenson@cs.wisc.edu)tbenson@cs.wisc.edu  "Complex systems are built out of a myriad of simple components" 29