1 / 16

Protocol for I2RS I2RS WG IETF #89 London, UK

Protocol for I2RS I2RS WG IETF #89 London, UK. Dean Bogdanovic deanb@juniper.net v0.1. Definitions.

genera
Download Presentation

Protocol for I2RS I2RS WG IETF #89 London, UK

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. Protocol for I2RSI2RS WGIETF #89 London, UK Dean Bogdanovicdeanb@juniper.net v0.1

  2. Definitions • Persistent data store – data store on network element where management system writes configuration data. The persistent data has to survive reboot process, as well it has to provide access to historical config changes • Ephemeral data store – data store where management system writes temporary configuration data. The ephemeral data store doesn’t survive reboot process, as well doesn’t provide access to historical config changes. Ephemeral config data isn’t verified. • Operational state – state of control daemon. It can be changed by reading persistent or ephemeral config store, control protocols or through exposed APIs.

  3. Intro • Reviewing RESTCONF and NETCONF capabilities for I2RS use • YANG is assumed as Data Language for I2RS • Assumptions: I2RS Agent and Clients have access to YANG DM

  4. I2RS Agent and Client architecture Cfg store Management daemon NETCONF daemon Network admin daemon daemon daemon

  5. Configuration model Need mechanism to define service templates to be exposed to the clients via agents • agents{ • routing{ • routing-services-template; • } • filtering{ • filtering-services-template; • } • }

  6. I2RS Agent and Client architecture Cfg store Management daemon NETCONF routing daemon Network admin routing agent daemon firewall agent daemon firewall daemon agent

  7. Client policy definition client-Bill{ authentication RADIUS; access { filtering; analytics; } } } Define policy for clients which agents they can access clients { client-Anne{ authentication local; access { filtering; routing; analytics; } }

  8. I2RS Agent and Client architecture Cfg store Management daemon NETCONF routing daemon Network admin Client Anne routing agent daemon RESTCONF firewall agent daemon Client Bill RESTCONF firewall daemon analytics agent

  9. Filter model (simple) IP protocol src port dest port filter id match_func action_func address_family accept discard policer count log inet_v4 inet_v6

  10. Device configuration vs modifying operational state • NETCONF and RESTCONF provide mechanism to configure devices, but not to change operational state

  11. NETCONF • Network Configuration Protocol (RFC 6241) • Operations are realized on top of RPCs • Uses XML for configuration data as well as protocol messages • The NETCONF protocol can be conceptually partitioned into four layers: • The Content layer consists of configuration data and notification data • The Operations layer defines a set of base protocol operations to retrieve and edit the configuration data. • The Messages layer provides a mechanism for encoding remote procedure calls (RPCs) and notifications • The Secure Transport layer provides a secure and reliable transport of messages between a client and a server.

  12. NETCONF cnt’d Configuration data <configuration> <services> <ssh> <root-login>allow</root-login> </ssh> <xnm-clear-text> </xnm-clear-text> <netconf> <ssh> </ssh> </netconf> </services> </configuration> Notification data Content Operations <get-config>, <commit-config> RPC <rpc>, <rpc-reply> <notification> Transport SSH, SSL

  13. Pros NETCONF Cons • Can’t modify operational daemon state directly • Multiple configuration data stores • Commit model • RPC based • IETF Standards track configuration protocol • Selective data retrieval with filtering • Provides data validation and verification

  14. RESTCONF • IETF draft draft-bierman-netconf-restconf-04 • defined as simplified interface to resource-oriented device abstractions • not intended to provide full capabilities as NETCONF

  15. Cons RESTCONF Pros • No network locking model • Can’t modify operational state of network device • Using JSON only simple meta-data is supported • Unified data store • Provides atomicity of transaction • Simplified defaults handling • Allows multiple edits (with PATCH) within single message • Providing abstracted simplified config model • Supports XML and JSON • Streaming via Server-Sent-Events • Edit collision detection

  16. RESTCONF and NETCONF Gaps • Both protocols will need some new mechanism in order to be able to install operational state on the device: • <edit-operational> in NETCONF • or • PUT/POST/PATCH to the operational resource in RESTCONF

More Related