Download - Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic [email protected]@juniper.net v0.1
![Page 2: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/2.jpg)
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.
![Page 3: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/3.jpg)
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
![Page 4: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/4.jpg)
I2RS Agent and Client architecture
daemon
Managementdaemon
daemon
daemon
daemon
NETCONF
Network admin
Cfg store
![Page 5: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/5.jpg)
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; }}
![Page 6: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/6.jpg)
I2RS Agent and Client architecture
routingdaemon
Managementdaemon
firewallagent
routingagent
daemon
daemon
firewalldaemon
NETCONF
Network admin
Cfg store
agent
![Page 7: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/7.jpg)
Client policy definition
Define policy for clients which agents they can accessclients { client-Anne{ authentication local; access { filtering; routing; analytics; } }
client-Bill{
authentication RADIUS;
access {
filtering;
analytics;
}
}
}
![Page 8: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/8.jpg)
I2RS Agent and Client architecture
routingdaemon
Managementdaemon
firewallagent
routingagent
daemon
daemon
firewalldaemon
NETCONF
Network admin
Cfg store
Client Bill
Client AnneRESTCONF
RESTCONF
analyticsagent
![Page 9: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/9.jpg)
Filter model (simple)
filter id
match_func
action_func
address_family
IP protocol
src port
dest port
accept
discard
policer
count
loginet_v4
inet_v6
![Page 10: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/10.jpg)
Device configuration vs modifying operational state
• NETCONF and RESTCONF provide mechanism to configure devices, but not to change operational state
![Page 11: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/11.jpg)
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:1. The Content layer consists of configuration data and notification data2. The Operations layer defines a set of base protocol operations to
retrieve and edit the configuration data.3. The Messages layer provides a mechanism for encoding remote
procedure calls (RPCs) and notifications4. The Secure Transport layer provides a secure and reliable transport of
messages between a client and a server.
![Page 12: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/12.jpg)
NETCONF cnt’d
Content
Operations
RPC
Transport
Configuration data<configuration> <services> <ssh> <root-login>allow</root-login> </ssh> <xnm-clear-text> </xnm-clear-text> <netconf> <ssh> </ssh> </netconf> </services> </configuration>
<get-config>, <commit-config>
<rpc>, <rpc-reply>
SSH, SSL
Notification data
<notification>
![Page 13: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/13.jpg)
Pros
• Can’t modify operational daemon state directly
• Multiple configuration data stores
• Commit model• RPC based
Cons• IETF Standards track
configuration protocol• Selective data retrieval
with filtering• Provides data validation
and verification
NETCONF
![Page 14: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/14.jpg)
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
![Page 15: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/15.jpg)
Cons
• No network locking model• Can’t modify operational
state of network device• Using JSON only simple
meta-data is supported
Pros• 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
RESTCONF
![Page 16: Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic deanb@juniper.netdeanb@juniper.net v0.1](https://reader036.vdocuments.us/reader036/viewer/2022082709/56649f555503460f94c79071/html5/thumbnails/16.jpg)
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 NETCONFor • PUT/POST/PATCH to the operational resource in RESTCONF