Automation Principles for Designing Network Elements
In this application note, we discuss automation's role in network management as well as how to implement best practice automation support in network elements using NETCONF and YANG.
|
Device Transactionality
In this application note, we review basic transactionality principles and then describe differences between transactional and non-transactional devices as well as discuss common transactionality issues. We also present an example of how to solve these issues using an adapter built around ConfD.
|
Migrate from a CLI NED to a NETCONF NED
This document describes how to migrate from a CLI NED to a NETCONF NED for an existing Cisco Network Services Orchestrator (NSO) service application.
|
YANG Patch
RESTCONF provides a standard RESTful API that vendors can implement to make it easy for customers to work with a uniform REST interface across all devices rather than a diverse set of vendor-defined proprietary REST interfaces.
One weakness of RESTCONF, as defined in RFC 8040, when compared with NETCONF, is in its inability to combine multiple different edit operations into a single operation and therefore a single transaction.
To remedy this, the IETF NETCONF Working Group created a new media type, the YANG Patch media type, which is used with the HTTP PATCH method.
|
Test Vectors - from CLI to NETCONF
Device management in one form or the other has been around as long as devices themselves. Historically, various paths have been taken to address the problem of configuring and tracking the device. NETCONF frequently and most usually takes the role of a newcomer that replaces existing legacy APIs like CLI. How can we take advantage of existing management API test vectors and re-use them with new NETCONF interfaces?
|