1 / 36

Demystifying Configuration Challenges and Trade -Offs in Network-based ISP Services

Theophilus Benson *, Aditya Akella *, Aman Shaikh + *University of Wisconsin, Madison + ATT Labs Research. Demystifying Configuration Challenges and Trade -Offs in Network-based ISP Services. Adoption of Network-based Services. ISP Core. Adoption of Network-based Services.

helene
Download Presentation

Demystifying Configuration Challenges and Trade -Offs in Network-based ISP Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Theophilus Benson*, AdityaAkella*, Aman Shaikh+ *University of Wisconsin, Madison + ATT Labs Research Demystifying Configuration Challenges and Trade-Offs in Network-based ISP Services

  2. Adoption of Network-based Services ISP Core

  3. Adoption of Network-based Services • “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 • Host-based and network-based services • “AT&T to spend $1 billion to ramp up enterprise services” • Recover cost and improve application performance ISP Core • Services are a crucial part of the Internet’s ecosystem

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

  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] OSPF BGP

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

  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 ISP Core PE CE PE Edge Customers Edge Customers

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

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

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

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

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

  14. Models and Data-Set

  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 Ipvrf blue Rd 23234:100223 ! Interface ethernet1 Ip address 128.105.82.66Ipvrf forwarding blue Services-policy input policy2 !

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

  17. Data-Set • 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 • Diversity allows for a comprehensive study

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

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

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

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

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

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

  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 ISP Core PE CE PE

  25. Mitigating Complexity • Vendor Selection Complexity Complexity Functionality Time Time Cost 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 Vendor2 Vendor1 ISP Core PE CE CE PE

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

  28. Conclusion • Studied the factors that impedeservices • 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

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

  30. Related Works • Customer usage patterns • Traffic matrixes [Garimella’07,Qiu’09,] • Control plane state [Raghunath’05] • Techniques for optimizing services • Improve hardware usage [Kim’08,Raghunath’07] • Very little on configuration • Modeling Class-of-Service [Sung’08] • Root cause analysis [Mahimkar’10, Turner’10] • Complementary to understanding complexity PE CE ISP Core CE PE

  31. Future Works • Automated simplification of configuration • Utilizing insights on design choices • New abstraction layer • Policy language for simpler configuration • Translates language to configuration • Correlate complexity with manageability

  32. Customer Provisioning • Customer provisioning causes complexity • Provisioning should slightly increase complexity • Similar functionality for all customers • Small change in configurations • Modular configuration languages • Reuse of configurations between customers

  33. Similarities Across Customers • Customers are not created equally • VPLS: 2 types of customers • VPN: Multiple types of customers • Groups of customers use services differently • Differences in requirements introduces complexity

More Related