110 likes | 124 Views
Explore the evolution of network manageability, from traditional CLI-based approaches to model-based manageability using YANG. Learn about the benefits, challenges, and potential impact of this shift in network management paradigms.
E N D
The Evolution of Network Manageability DevOps SDN NFV telemetry NETCONF API XML CLI Expect TCL streaming YANG gRPCI2RS Perl KPI JSON SNMP BGP-LS Chef OpenFlow NMDA Spherical Routers in Vacuum PCEP programmability OVSDB NetFlow ASIC pubsub RESTCONF automation MIB intent ASN.1 SLA controller VM AI Python Protbuf SSH FCAPS NMS IPFIX Syslog data-model Thrift AnsiblegNMI push XPath OID ForCES namespace
The network has to work • Manageability is essential and yet often overlooked. • Feature and feature’s manageability parity. • Configuration vs state vs statistics. • Manageability and automation.
Current state of affairs • CLI domination. • SNMP has a long history. • Thought impact coming from other domains. • Parametrized script templates have a trend. • Can we do any better?
What do operators want? • Ease of practical use. • Separation and correlation of configuration and state. • Text format is preferred. • Focus broader than just on a single network element. • A common schema for networks and network services. • Data-oriented vs task-oriented operations. • The single source of truth. • Ordering of operations.
SNMP limitations • Assumptions and dependencies of platform identifiers. • Everything is a table. • Transactional model complexity. • SNMP provides mostly data-centric view. • UDP based transport, implementation complexity. • Intermixing of configuration and state. • No self-describing schema.
Model-based manageability • Separation of configuration data from methods of transporting of that data. • Model abstracts the functionality of network element – to a level. • Focus on software components and not on human operator. • Feedback loops. • Intent – what to do vs how to do. • Model is used for generating the API contract.
The components • Modelling language (YANG) • Encodings (XML, JSON, CBOR, protobuf, your own) • Transports (NETCONF, RESTCONF, gNMI, your own) • Models • Tooling • Education
The modelling language - YANG • Just another DSL, nothing more. • An extensible and flexible one. • Hierarchy of objects, relationship and conditions among objects. • Model itself is separated from transports and encodings. • Model may contain part of business logic. • Strong ties to software engineering domain – CORBA. • A fundamental difference between a schema and data based on that schema.
Types of Models • Element • Network • Service Can use the same modelling language! Service Model Service Model Network Model Element Model Element Model Element Model Router Router Router
Questions that you wanted to ask • Is this yet another science fiction project? • SNMP + Perl scripts work just fine for me, why should I care? • My favourite vendor has got an NMS anyway. • Is my CCIE irrelevant then? • I am a network engineer, not a software engineer. • This seems to be really complex. • Can I deploy all of this right now? Where do I sign? • YANG is a replacement for Python, right? • Is CLI outlawed now? • Will this allow for a seamless migration from vendor X to vendor Y? • How and where could I start with all of this? • Models do replace the business logic, right? • Is YANG the only and all-encompassing solution for all manageability needs?
Discussion • Do you care? • Would you deploy this? • What help would you need?