1 NETCONF and RESTCONF Roque Gagliano

2 Origins of NETCONF and YANG (the Beginning)Several meetings at events in 2001 (NANOG-22, RIPE-40, LISA-XV, IETF 52) Operators expressing opinion that the developments in IETF do not really address requirements configuration management. June of 2002, the Internet Architecture Board (IAB) held invitational workshop on Network Management [RFC3535] to Identify a list of technologies relevant for network management with their strengths and weaknesses Identify the most important operator needs.

3 RFC 3535: Results from IAB Workshop

4 RFC3535: Operator requirements for a new configuration protocolEase of use Separation between configuration and state data Ability to compare across-devices, across-vendors Service and network management, not device management Network-wide transactions Devices figure out order of commands(ACID…anyways) No unnecessarily changes Backup/restore configuration Validation of configuration Standardized data models Support for multiple configuraiton sets Delayed, orchestrated activation Role-based access control

5 Implications of RFC 3535, legacy situationOSS NMS EMS Cost and complexity Information leakage Cost Lack of atomicity Ordering problem

6 Implications of RFC 3535, with transactionsOSS NMS EMS Reduced Cost and complexity Require transactions Cost/ Value

7 Best Practices Coming TogetherCLI Best Practices Operator Requirements SNMP Experience NETCONF and YANG

8 YANG – A Data Modeling Language for NetworkingWhy you should care: YANG is a full, formal contract language with rich syntax and semantics to build applications on Human readable, and easy to learn representation Hierarchical configuration data models Reusable types and groupings (structured types) Extensibility through augmentation mechanisms Supports definition of operations (RPCs) Formal constraints for configuration validation Data modularity through modules and sub-modules Well defined versioning rules

9 YANG standard models In the making:Standard content library still small but rapidly growing Most foundational models are in place Complement “top-down” definitions with models that are synthetically generated (think Google Translate) Base document: RFC 6020 YANG + NETCONF: RFC 6241 IETF approved documents: Common types (RFC 6991) IANA Interface types (RFC 7224) Interface management (RFC 7223) IP management (RFC 7277) System management (RFC 7317) IPFIX configuration (RFC 6728) SNMP configuration (RFC 7407) In the making: Syslog configuration ACL configuration Network topology, L3 topology BGP, OSPF Netconf monitoring, Netconf access control (NACM) L2VPN, PIM, MPLS-LDP,

10 NETCONF Protocol Introduction

11 NETCONF – A Protocol to Manipulate ConfigurationIETF network management protocol Distinction between configuration and state data Multiple configuration data stores (candidate, running, startup) Configuration change validations Configuration change transactions Selective data retrieval with filtering Streaming and playback of event notifications Extensible remote procedure call mechanism NETCONF Notifications support New work on pushing pub/subs to expand NETCONF into telemetry Why you should care: NETCONF provides the fundamental programming features for comfortable and robust automation of network services

12 Self-service portal Service Fulfillment and related parts of OSS/BSS (except Service Assurance) Call center CPQ Customers & accounts Order capture engine Product configuration Products & Price Catalog Knowledge base Contracts & SLAs Customer care Installed assets Billing Order Management CPQ = Configure, Price and Quote Field Service Service provisioning Supply Chain Service activation Resource inventory

13 What is NETCONF? Why NETCONF?NETCONF (Network Configuration Protocol) is an IETF configuration management protocol not only config access, also operational state data NETCONF uses XML (as you are going to see) Why NETCONF? Easy to Use Separates Config and Operational Data Lots of Tooling Next-Gen Configuration Management Requirements RFC3535 Accessible Format Error Checking Backup/Restore Capability Human and Machine Friendly

14 What is an ACID transactionAtomicity: Transactions are indivisible, all-or-nothing Consistency: Transactions are all-at-once There is no internal order inside a transaction, it is a set of changes, not a sequence Independence: Parallel transactions do not interfere with each other Transactions appear to happen always-in-sequence Durability Committed data always-sticks, i.e. remains in the system even in the case of a fail- over, power failure, restart, etc

15 NETCONF IETF Standard InformationV 1.0 V 1.1 Extension RFC 6535 Background and Requirements RFC 6241 1.1 Base NETCONF Protocol RFC 5277 Notifications RFC 4741 1.0 Base NETCONF Protocol RFC 6242 NETCONF over SSH RFC 5717 Partial Locking RFC 4742 RFC 6243 With defaults RFC 6244 NETCONF + YANG Architectural Overview

16 NETCONF Protocol StackClient initiated session Content SSH Server Client Operations Reason: Connection-oriented (TCP) Authenticated Reliable Secure Messages Transport

17 NETCONF Protocol Stack Content Server Operations Client NETCONF Messages: Remote Procedure Call (RPC) Messages RPC Client’s Request Methods: Controller NMS Script Manual Transport

18 NETCONF Protocol StackOPERATION DESCRIPTION Retrieve data from the running configuration Retrieve running configuration or device statistic Modify a configuration database operation = merge (default), delete, create, replace, remove test-option (:validate), error-option Copy a configuration database Delete a configuration database Commit candidate configuration to the running db / Lock or unlock a configuration datastore system Terminate this session Force Termination of session event notification subscription asynchronously message from server to client when an event of interest has occurred Content Operations Messages Transport

19 NETCONF Protocol Stack urn:ietf:params:netconf:base:1.0 urn:ietf:params:netconf:capability:candidate:1.0 urn:ietf:params:netconf:capability:notification:1.0 ]]>]]> Content Operations Messages Transport

20 NETCONF Configuration Data StoresStartup Running Candidate Files… / URLs… Named configuration stores Each data store may hold a full copy of the configuration Running is mandatory, Startup and Candidate optional (capabilities :startup, :candidate) Running may or may not be directly writable (:writable-running) Need to copy from other stores if not directly writable Candidate is required for network wide transactions

21 NETCONF Call Flow (1) 1) Client sends HELLO message to Server. It includes its Capabilities. >>>>out 16-Dec-2016::14:25: device=pe2 urn:ietf:params:netconf:base:1.0urn:ietf:params:netconf:base:1.1

22 NETCONF Capabilities exchangeAllows extensibility of the protocol Are transmitted in the ”hello” message and set what each party is capable of: Some from NETCONF standards Each YANG modules supported by the server is also a capability. YANG modules include revision number Other extensions The manager uses the capabilities to determinate what operations can send to the server

23 NETCONF Capabilities :notification, :interleave (RFC 5277)Optional Capabilities (RFC 6241) Other Capabilities :notification, :interleave (RFC 5277) :partial-lock (RFC 5717) :with-defaults (RFC 6243) :ietf-netconf-monitoring (RFC 6022) And you can define your own, like :actions (tail-f) :inactive (tail-f) :writable-running! :candidate! :confirmed-commit! :rollback-on-error! :validate! :startup! :url (scheme=http, ftp, file, …) :xpath (filters)

24 NETCONF Call Flow (2): Hello from server urn:ietf:params:netconf:base:1.0 urn:ietf:params:netconf:base:1.1 urn:ietf:params:netconf:capability:candidate:1.0 urn:ietf:params:netconf:capability:confirmed-commit:1.0 urn:ietf:params:netconf:capability:confirmed-commit:1.1 urn:ietf:params:netconf:capability:xpath:1.0 urn:ietf:params:netconf:capability:validate:1.0 urn:ietf:params:netconf:capability:validate:1.1 urn:ietf:params:netconf:capability:rollback-on-error:1.0 http://tail-f.com/ns/netconf/with-defaults/1.0 http://tail-f.com/ns/netconf/actions/1.0 http://tail-f.com/ns/netconf/extensions urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&also-supported=report-all-tagged urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?revision= &module=ietf-netconf-with-defaults urn:ietf:params:netconf:capability:yang-library:1.0?revision= &module-set-id=c9f8a470ce0ddaa46d30ed57fae7d5bb http://xml.juniper.net/xnm/1.1/xnm?module=junos urn:ietf:params:xml:ns:yang:iana-crypt-hash?module=iana-crypt-hash&revision= &features=crypt-hash-sha-512,crypt-hash-sha-256,crypt-hash-md5 urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&revision= urn:ietf:params:xml:ns:yang:ietf-netconf-notifications?module=ietf-netconf-notifications&revision= urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring?module=ietf-restconf-monitoring&revision= urn:ietf:params:xml:ns:yang:ietf-yang-library?module=ietf-yang-library&revision= urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&revision= urn:juniper-rpc?module=junos-rpc 13]]>]]>

25 NETCONF Call Flow (3): Lock in candidate

26 NETCONF Call Flow (4): Edit Config test-then-setrollback-on-error curso_mvdeo

27 NETCONF edit-config nc:test-option (:validate)!test-then-set (default) set! test (:base:1.1)! nc:error-option! stop-on-error (default) continue-on-error! rollback-on-error (:rollback-on-error)! nc:operation! merge! replace! create! delete !  Error if item does not exists remove (:base:1.1)!  No error if item does not exists

28 NETCONF Call Flow (5): Confirmed commit

29 NETCONF Call Flow (6): Commit

30 NETCONF Call Flow (7): Close session Note: You can also “kill” a session (not that polite)

31 NETCONF Protocol Stack SummaryContent Config data, Notification (XML) Operations , , etc Server Client Messages , Transport SSH

32 NETCONF Opensource toolsPython NETCONF Client library: https://github.com/ncclient/ncclient Java NETCONF Client library: https://github.com/tail-f-systems/JNC C NETCONF Client library: https://github.com/CESNET/libnetconf More:

33 ResTful:Representational state transferCharacteristics Stateless operations: server does not keep any state between requests Textual representation: typically JSON or XML Resources specified in URI Pre-defined Verbs: GET, POST, PUT, DELETE, PATCH, … ReSTful gained popularity because: Performance Scalability Simplicity Portability

34 ResTful does not mean “standard API” And “documented” is not “open”Vendors are now exposing ResTful configuration APIs The problem is that every API differs on: HTTP options Authentication Verbs interpretation Encoding Etc. The conclusion is that a “Driver” is still needed for every configuration devices In general, the Swagger Specification (from OpenAPI project) is addressing the documentation problem For CRUD operations, the IETF defined RESTCONF using YANG modeling language

35 RESTCONF - Standard HTTP-based configuration protocolStill an emerging story (at IETF queue) RESTful protocol to access YANG defined data Representational State Transfer, i.e. server maintains no session state URIs reflect data hierarchy in a Netconf datastore HTTPS as transport Data encaded with either XML or JSON Operations

36 NETCONF and RESTCONF are not equalRESTCONF does not have concept of transaction across calls and therefore cannot implement “network wide transactions” Some operations missing: There is no “Validate” call in RESTCONF Missing “copy-config” NOTIFICATION support in RESTCONF depends on W3C event streaming recommendation (not widely available)

37 Some RESTCONF featuresMUST support TLS and MUST NOT be used without TLS support (mandatory security) Authentication: password (HTTP auth.) or client-certificate Resources: Root Resources Discovery available (for exampel /restconf) Media types: JSON and XML encoding supported API Resources ({+restconf}/…): Child Resource Description data Contains all data resources operations Data-model-specific operations yang-library-version ietf-yang-library module date

38 Example DATA Operations Retrieving Server capabilitiesGET /restconf/data/ietf-restconf-monitoring:restconf-state/\ capabilities HTTP/1.1 Host: example.com Accept: application/yang-data+xml HTTP/ OK Date: Mon, 23 Apr :02:00 GMT Server: example-server Cache-Control: no-cache Last-Modified: Sun, 22 Apr :00:14 GMT Content-Type: application/yang-data+xml Bierman, et al. Expires April 30, 2017 [Page 115] Internet-Draft RESTCONF October 2016 \ urn:ietf:params:restconf:capability:defaults:1.0?\ basic-mode=explicit\ \ urn:ietf:params:restconf:capability:with-defaults:1.0\ \ urn:ietf:params:restconf:capability:depth:1.0\

39 Example DATA Operations Creating a new resourcemodule example-jukebox { namespace "http://example.com/ns/example-jukebox"; prefix "jbox"; container jukebox { list artist { key name; leaf name { type string { length "1 .. max"; } } }} YANG POST /restconf/data/example-jukebox:jukebox/library HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "example-jukebox:artist" : [ "name" : "Foo Fighters" } ] } RESTCONF Query RESTCONF Response HTTP/ Created Date: Mon, 23 Apr :02:00 GMT Server: example-server Location: https://example.com/restconf/data/example-jukebox:jukebox/library/artist=Foo%20Fighters Last-Modified: Mon, 23 Apr :02:00 GMT ETag: "b3830f23a4c"

40 Example Operation Resourcemodule example-ops { namespace "https://example.com/ns/example-ops"; prefix "ops"; rpc reboot { input { leaf delay { units seconds; type uint32; default 0; } leaf message { type string; } leaf language { type string; } } } rpc get-reboot-info { output { leaf reboot-time { units seconds; type uint32; } leaf language { type string; }

41 Example Operation ResourcePOST /restconf/operations/example-ops:reboot HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "example-ops:input" : { "delay" : 600, "message" : "Going down for system maintenance", "language" : "en-US" } HTTP/ No Content Date: Mon, 25 Apr :01:00 GMT Server: example-server

42 Example Operation ResourcePOST /restconf/operations/example-ops:get-reboot-info HTTP/1.1 Host: example.com Accept: application/yang-data+json HTTP/ OK Date: Mon, 25 Apr :10:30 GMT Server: example-server Content-Type: application/yang-data+json { "example-ops:output" : { "reboot-time" : 30, "message" : "Going down for system maintenance", "language" : "en-US" }