Open management interfaces for NFV
0 likes1,021 views
The document discusses the challenges of managing web-scale networks and virtual network functions (VNFs), emphasizing the complexities involved with multiple vendors and tools, and the need for a vendor-neutral management approach. It introduces OpenConfig as a collaborative effort to develop common data models for network configuration and operational state, seeking to streamline network management through standard APIs and model-driven telemetry. The work aims to enhance interoperability and reduce the burden of proprietary solutions, paving the way for more efficient network monitoring and configuration.
Open management interfaces for NFV
- 1. Anees Shaikh Google Network Operations on behalf of the OpenConfig working group www.openconfig.net github.com/openconfig/public Open Management Interfaces for NFV OPNFV Summit November 2015
- 2. Challenges of managing a Web-scale network ● very large number of OIDs collected ● many CLI commands issued and scraped at high frequency ● many tools, and multiple generations of software VNF management adds additional challenges: more device variants, multi-layer monitoring, application-level coordination, diverse usage patterns, ... 2 ● 20+ network device roles ● more than half dozen vendors, multiple platforms ● 4M lines of configuration files ● up to ~30K configuration changes per month
- 3. State of management isn’t helping ... ● many proprietary integrations ○ CLIs, scripts, templates, modules, cookbooks, minions, ... ● lack of available abstractions and common APIs ● configuration scraping from devices ● SNMP monitoring -- poor scaling, lack of extensibility, proprietary MIBs ● complexity and cost have been pushed to operators ○ long qualification processes, specialized skills, ... 3
- 4. Evolving toward a vendor-neutral approach 4 Per-vendor EMS EMS A platform-specific tools, processes, skills EMS B EMS C VNF A VNF B VNF C Common OSS EMS A proprietary integrations, common interfaces upstream EMS C VNF A VNF B VNF C operator / 3rd party OSS Common VNF mgmt APIs common mgmnt API proprietary integrations, common interfaces upstream VNF A VNF B VNF C operator OSS
- 5. Model-driven management plane 5 interoperable network-wide view multiple vendor devices API common API for configuration and monitoring monitoring / collectors transport and RPC protocols that are open, streaming, secure Configuration TopologyTelemetry Models provide: ○ durable APIs ○ vendor-independent abstractions ○ forward compatibility
- 6. Model-driven streaming telemetry 6 ● stream data continuously -- with incremental updates based on subscriptions ● observe network state through a time- series data stream ● device data follows a common model ● efficient, secure transport protocols (gRPC) time-series data stream async event reporting requests for ad-hoc data gRPC endpoint telemetry collectors upstream monitoring systems
- 7. OpenConfig overview ● industry collaboration among network operators ● primary output: data models for configuration and operational state, written in YANG ● operational model: informal, structured like an open source project ● development priorities driven by operator requirements ● individual and collective engagements with major equipment vendors to drive native implementations ● also now contributing tools for consuming YANG models
- 9. OpenConfig progress Data models (configuration and operational state) ● BGP and routing policy (adopted by IETF ) ● MPLS / TE ● optical transport ● interfaces, VLANs ● more … Native implementations -- BGP+policy models ○ Cisco IOS-XR ○ Juniper JUNOS ○ Arista EOS ○ additional vendors with implementations underway 9
- 10. OpenConfig beyond data models Tools and APIs (examples) ● pyangbind -- generates Python classes from YANG models ● goyang -- Go language YANG compiler ● protocol-independent specs for config and telemetry RPCs Design patterns and usability improvements ● design patterns for operational state and model composition ● model catalog and registry 10
- 11. OpenConfig and NFV ● problems are very similar ○ lack of common APIs for monitoring and configuring VNFs ○ proprietary integration with VNFs and vendor EMSes ● apply OpenConfig approach to VNF management ○ operator-driven with vendor partnership ○ focus on the common use cases and functions ○ make model and API support a requirement for deployment 11
- 12. OPNFV opportunities 12 OPNFV model development ● develop vendor-neutral data models for common VNFs ● leverage high operator participation to define the models model implementations ● OPNFV as an open forum for vendor feedback on models ● prototype implementation, testing, and certification integrations ● exploit ODL integration to include support for YANG models ● ODL / OpenStack can provide basis for VNF managers
- 13. Summary ● network infrastructure and VNF management needs a model- driven approach ● OpenConfig is a new kind of industry collaboration ○ network operators directly contributing open data models, tools, and design patterns ● as native implementations become available, potential to significantly transform network monitoring and configuration ● approach and experience from OpenConfig can be applied directly to NFV 13
- 14. Thank you! 14