idnits 2.17.1 draft-ietf-i2rs-architecture-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 926: '... agent MUST support two different no...' RFC 2119 keyword, line 1004: '... model (often in MUST and WHEN clauses...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1086 has weird spacing: '...fig has loca...' -- The document date (April 21, 2016) is 2927 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-10 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-protocol-security-requirements-03 == Outdated reference: A later version (-06) exists of draft-ietf-i2rs-security-environment-reqs-01 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-12 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-rfc6020bis-11 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 7277 (Obsoleted by RFC 8344) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Atlas 3 Internet-Draft Juniper Networks 4 Intended status: Informational J. Halpern 5 Expires: October 23, 2016 Ericsson 6 S. Hares 7 Huawei 8 D. Ward 9 Cisco Systems 10 T. Nadeau 11 Brocade 12 April 21, 2016 14 An Architecture for the Interface to the Routing System 15 draft-ietf-i2rs-architecture-14 17 Abstract 19 This document describes the IETF architecture for a standard, 20 programmatic interface for state transfer in and out of the Internet 21 routing system. It describes the high-level architecture, the 22 building blocks of this high-level architecture, and their interfaces 23 with particular focus on those to be standardized as part of the 24 Interface to Routing System (I2RS). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 23, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4 62 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3. Key Architectural Properties . . . . . . . . . . . . . . . . 12 65 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 12 66 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13 67 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 13 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 4.1. Identity and Authentication . . . . . . . . . . . . . . . 16 70 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 16 71 4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 17 72 4.4. I2RS in Personal Devices . . . . . . . . . . . . . . . . 18 73 5. Network Applications and I2RS Client . . . . . . . . . . . . 18 74 5.1. Example Network Application: Topology Manager . . . . . . 19 75 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 19 76 6.1. Relationship to its Routing Element . . . . . . . . . . . 19 77 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 20 78 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 20 79 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 21 80 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 21 81 6.3. Interactions with Local Configuration . . . . . . . . . . 22 82 6.3.1. Examples of Local Configuration vs. I2RS Ephemeral 83 Configuration . . . . . . . . . . . . . . . . . . . . 23 84 6.4. Routing Components and Associated I2RS Services . . . . . 25 85 6.4.1. Routing and Label Information Bases . . . . . . . . . 26 86 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 27 87 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 28 88 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 28 89 6.4.5. Information Modeling, Device Variation, and 90 Information Relationships . . . . . . . . . . . . . . 28 91 6.4.5.1. Managing Variation: Object Classes/Types and 92 Inheritance . . . . . . . . . . . . . . . . . . . 28 93 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 29 94 6.4.5.3. Managing Variation: Templating . . . . . . . . . 29 95 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 30 96 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 30 97 6.4.5.4.2. Correlation Identification . . . . . . . . . 30 98 6.4.5.4.3. Object References . . . . . . . . . . . . . . 31 99 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 31 100 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 31 101 7.1. One Control and Data Exchange Protocol . . . . . . . . . 31 102 7.2. Communication Channels . . . . . . . . . . . . . . . . . 32 103 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 32 104 7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 33 105 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 33 106 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 34 107 7.7. Information collection . . . . . . . . . . . . . . . . . 34 108 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 35 109 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 35 110 8. Operational and Manageability Considerations . . . . . . . . 36 111 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 112 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 113 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 114 11.1. Normative References . . . . . . . . . . . . . . . . . . 37 115 11.2. Informative References . . . . . . . . . . . . . . . . . 37 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 118 1. Introduction 120 Routers that form the internet routing infrastructure maintain state 121 at various layers of detail and function. For example, a typical 122 router maintains a Routing Information Base (RIB), and implements 123 routing protocols such as OSPF, IS-IS, and BGP to exchange 124 reachability information, topology information, protocol state, and 125 other information about the state of the network with other routers. 127 Routers convert all of this information into forwarding entries which 128 are then used to forward packets and flows between network elements. 129 The forwarding plane and the specified forwarding entries then 130 contain active state information that describes the expected and 131 observed operational behavior of the router and which is also needed 132 by the network applications. Network-oriented applications require 133 easy access to this information to learn the network topology, to 134 verify that programmed state is installed in the forwarding plane, to 135 measure the behavior of various flows, routes or forwarding entries, 136 as well as to understand the configured and active states of the 137 router. Network-oriented applications also require easy access to an 138 interface which will allow them to program and control state related 139 to forwarding. 141 This document sets out an architecture for a common, standards-based 142 interface to this information. This Interface to the Routing System 143 (I2RS) facilitates control and observation of the routing-related 144 state (for example, a Routing Element RIB manager's state), as well 145 as enabling network-oriented applications to be built on top of 146 today's routed networks. The I2RS is a programmatic asynchronous 147 interface for transferring state into and out of the internet routing 148 system. This I2RS architecture recognizes that the routing system 149 and a router's Operating System (OS) provide useful mechanisms that 150 applications could harness to accomplish application-level goals. 151 These network-oriented applications can leverage the I2RS 152 programmatic interface to create new ways of combining retrieval of 153 internet routing data, analyzing this data, setting state within 154 routers. 156 Fundamental to the I2RS are clear data models that define the 157 semantics of the information that can be written and read. The I2RS 158 provides a way for applications to customize network behavior while 159 leveraging the existing routing system as desired. The I2RS provides 160 a framework for applications (including controller applications) to 161 register and to request the appropriate information for each 162 particular application. 164 Although the I2RS architecture is general enough to support 165 information and data models for a variety of data, and aspects of the 166 I2RS solution may be useful in domains other than routing, I2RS and 167 this document are specifically focused on an interface for routing 168 data. 170 Security is a concern for any new interface to the routing system. 171 Section 4 provides an overview of the security considerations for the 172 I2RS architecture. The detailed requirements for I2RS protocol 173 security are contained in 174 [I-D.ietf-i2rs-protocol-security-requirements], and the detailed 175 security requirements for environment in which the I2RS protocol 176 exists in are contained in [I-D.ietf-i2rs-security-environment-reqs]. 178 1.1. Drivers for the I2RS Architecture 180 There are four key drivers that shape the I2RS architecture. First 181 is the need for an interface that is programmatic, asynchronous, and 182 offers fast, interactive access for atomic operations. Second is the 183 access to structured information and state that is frequently not 184 directly configurable or modeled in existing implementations or 185 configuration protocols. Third is the ability to subscribe to 186 structured, filterable event notifications from the router. Fourth, 187 the operation of I2RS is to be data-model driven to facilitate 188 extensibility and provide standard data-models to be used by network 189 applications. 191 I2RS is described as an asynchronous programmatic interface, the key 192 properties of which are described in Section 5 of 193 [I-D.ietf-i2rs-problem-statement]. 195 The I2RS architecture facilitates obtaining information from the 196 router. The I2RS architecture provides the ability to not only read 197 specific information, but also to subscribe to targeted information 198 streams, filtered events, and thresholded events. 200 Such an interface also facilitates the injection of ephemeral state 201 into the routing system. Ephemeral state on a router is the state 202 which does not survive a the reboot of a routing device or the reboot 203 of the software handling the I2RS software on a routing device. A 204 non-routing protocol or application could inject state into a routing 205 element via the state-insertion functionality of the I2RS and that 206 state could then be distributed in a routing or signaling protocol 207 and/or be used locally (e.g. to program the co-located forwarding 208 plane). I2RS will only permit modification of state that would be 209 safe, conceptually, to modify via local configuration; no direct 210 manipulation of protocol-internal dynamically determined data is 211 envisioned. 213 1.2. Architectural Overview 215 Figure 1 shows the basic architecture for I2RS between applications 216 using I2RS, their associated I2RS clients, and I2RS agents. 217 Applications access I2RS services through I2RS clients. A single 218 I2RS client can provide access to one or more applications. This 219 figure also shows the types of data models associated with the 220 routing system (dynamic configuration, static configuration, local 221 configuration, and routing and signaling configuration) which the 222 I2RS agent data models may access or augment. 224 Figure 1 is similar to the figure 1 found in the 225 [I-D.ietf-i2rs-problem-statement], but this figure shows additional 226 detail on how the applications utilize I2RS clients to interact with 227 I2RS agents. Figure 1 also shows a logical view of the data models 228 associated with the routing system rather than a functional view 229 (RIB, FIB, topology, policy, routing/signaling protocols, etc.) 231 In figure 1, Clients A and B each provide access to a single 232 application (application A and B respectively), while Client P 233 provides access to multiple applications. 235 Applications can access I2RS services through local or remote 236 clients. A local client operates on the same physical box as routing 237 system. In contrast, a remote client operates across the network. 238 In the figure, Applications A and B access I2RS services through 239 local clients, while Applications C, D and E access I2RS services 240 through a remote client. The details of how applications communicate 241 with a remote client is out of scope for I2RS. 243 An I2RS client can access one or more I2RS agents. In the figure 1, 244 Clients B and P access I2RS agents 1 and 2. Likewise, an I2RS agent 245 can provide service to one or more clients. In this figure, I2RS 246 agent 1 provides services to Clients A, B and P while Agent 2 247 provides services to only Clients B and P. 249 I2RS agents and clients communicate with one another using an 250 asynchronous protocol. Therefore, a single client can post multiple 251 simultaneous requests, either to a single agent or to multiple 252 agents. Furthermore, an agent can process multiple requests, either 253 from a single client or from multiple clients, simultaneously. 255 The I2RS agent provides read and write access to selected data on the 256 routing element that are organized into I2RS Services. Section 4 257 describes how access is mediated by authentication and access control 258 mechanisms. Figure 1 shows I2RS agents being able to write ephemeral 259 static state (e.g. RIB entries), and to read from dynamic static 260 (e.g. MPLS LSP-ID or number of active BGP peers). 262 In addition to read and write access, the I2RS agent allows clients 263 to subscribe to different types of notifications about events 264 affecting different object instances. One example of a notification 265 of such an event (which is unrelated to an object creation, 266 modification or deletion) is when a next-hop in the RIB is resolved 267 in a way that allows it to be used by a RIB manager for installation 268 in the forwarding plane as part of a particular route. Please see 269 Section 7.6 and Section 7.7 for details. 271 The scope of I2RS is to define the interactions between the I2RS 272 agent and the I2RS client and the associated proper behavior of the 273 I2RS agent and I2RS client. 275 ****************** ***************** ***************** 276 * Application C * * Application D * * Application E * 277 ****************** ***************** ***************** 278 ^ ^ ^ 279 | | | 280 |--------------| | |--------------| 281 | | | 282 v v v 283 *************** 284 * Client P * 285 *************** 286 ^ ^ 287 | |-------------------------| 288 *********************** | *********************** | 289 * Application A * | * Application B * | 290 * * | * * | 291 * +----------------+ * | * +----------------+ * | 292 * | Client A | * | * | Client B | * | 293 * +----------------+ * | * +----------------+ * | 294 ******* ^ ************* | ***** ^ ****** ^ ****** | 295 | | | | | 296 | |-------------| | | |-----| 297 | | -----------------------| | | 298 | | | | | 299 ************ v * v * v ********* ***************** v * v ******** 300 * +---------------------+ * * +---------------------+ * 301 * | Agent 1 | * * | Agent 2 | * 302 * +---------------------+ * * +---------------------+ * 303 * ^ ^ ^ ^ * * ^ ^ ^ ^ * 304 * | | | | * * | | | | * 305 * v | | v * * v | | v * 306 * +---------+ | | +--------+ * * +---------+ | | +--------+ * 307 * | Routing | | | | Local | * * | Routing | | | | Local | * 308 * | and | | | | Config | * * | and | | | | Config | * 309 * |Signaling| | | +--------+ * * |Signaling| | | +--------+ * 310 * +---------+ | | ^ * * +---------+ | | ^ * 311 * ^ | | | * * ^ | | | * 312 * | |----| | | * * | |----| | | * 313 * v | v v * * v | v v * 314 * +----------+ +------------+ * * +----------+ +------------+ * 315 * | Dynamic | | Static | * * | Dynamic | | Static | * 316 * | System | | System | * * | System | | System | * 317 * | State | | State | * * | State | | State | * 318 * +----------+ +------------+ * * +----------+ +------------+ * 319 * * * * 320 * Routing Element 1 * * Routing Element 2 * 321 ******************************** ******************************** 323 Figure 1: Architecture of I2RS Clients and Agents 325 Routing Element: A Routing Element implements some subset of the 326 routing system. It does not need to have a forwarding plane 327 associated with it. Examples of Routing Elements can include: 329 * A router with a forwarding plane and RIB Manager that runs IS- 330 IS, OSPF, BGP, PIM, etc., 332 * A BGP speaker acting as a Route Reflector, 333 * An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a 334 forwarding plane and associated RIB Manager, 336 * A server that runs IS-IS, OSPF, BGP and uses ForCES to control 337 a remote forwarding plane, 339 A Routing Element may be locally managed, whether via CLI, SNMP, 340 or NETCONF. 342 Routing and Signaling: This block represents that portion of the 343 Routing Element that implements part of the internet routing 344 system. It includes not merely standardized protocols (i.e. IS- 345 IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager 346 layer. 348 Local Configuration: is the black box behavior for interactions 349 between the ephemeral state that I2RS installs into the routing 350 element; and this Local Configuration is defined by this document 351 and the behaviors specified by the I2RS protocol. 353 Dynamic System State: An I2RS agent needs access to state on a 354 routing element beyond what is contained in the routing subsystem. 355 Such state may include various counters, statistics, flow data, 356 and local events. This is the subset of operational state that is 357 needed by network applications based on I2RS that is not contained 358 in the routing and signaling information. How this information is 359 provided to the I2RS agent is out of scope, but the standardized 360 information and data models for what is exposed are part of I2RS. 362 Static System State: An I2RS agent needs access to static state on 363 a routing element beyond what is contained in the routing 364 subsystem. An example of such state is specifying queueing 365 behavior for an interface or traffic. How the I2RS agent modifies 366 or obtains this information is out of scope, but the standardized 367 information and data models for what is exposed are part of I2RS. 369 I2RS agent: See the definition in Section 2. 371 Application: A network application that needs to observe the 372 network or manipulate the network to achieve its service 373 requirements. 375 I2RS client: See the definition in Section 2. 377 As can be seen in Figure 1, an I2RS client can communicate with 378 multiple I2RS agents. Similarly, an I2RS agent may communicate with 379 multiple I2RS clients - whether to respond to their requests, to send 380 notifications, etc. Timely notifications are critical so that 381 several simultaneously operating applications have up-to-date 382 information on the state of the network. 384 As can also be seen in Figure 1, an I2RS agent may communicate with 385 multiple clients. Each client may send the agent a variety of write 386 operations. In order to keep the protocol simple, two clients should 387 not attempt to write (modify) the same piece of information on an 388 I2RS agent. This is considered an error. However, such collisions 389 may happen and section 7.8 (multi-headed control) describes how the 390 I2RS agent resolves collision by first utilizing priority to resolve 391 collisions, and second by servicing the requests in a first in, first 392 served basis. The I2RS architecture includes this definition of 393 behavior for this case simply for predictability not because this is 394 an intended result. This predictability will simplify the error 395 handling and suppress oscillations. If additional error cases beyond 396 this simple treatment are required, these error cases should be 397 resolved by the network applications and management systems. 399 In contrast, although multiple I2RS clients may need to supply data 400 into the same list (e.g. a prefix or filter list), this is not 401 considered an error and must be correctly handled. The nuances so 402 that writers do not normally collide should be handled in the 403 information models. 405 The architectural goal for the I2RS is that such errors should 406 produce predictable behaviors, and be reportable to interested 407 clients. The details of the associated policy is discussed in 408 Section 7.8. The same policy mechanism (simple priority per I2RS 409 client) applies to interactions between the I2RS agent and the 410 CLI/SNMP/NETCONF as described in Section 6.3. 412 In addition it must be noted that there may be indirect interactions 413 between write operations. A basic example of this is when two 414 different but overlapping prefixes are written with different 415 forwarding behavior. Detection and avoidance of such interactions is 416 outside the scope of the I2RS work and is left to agent design and 417 implementation. 419 2. Terminology 421 The following terminology is used in this document. 423 agent or I2RS agent: An I2RS agent provides the supported I2RS 424 services from the local system's routing sub-systems by 425 interacting with the routing element to provide specified 426 behavior. The I2RS agent understands the I2RS protocol and can be 427 contacted by I2RS clients. 429 client or I2RS client: A client implements the I2RS protocol, uses 430 it to communicate with I2RS agents, and uses the I2RS services to 431 accomplish a task. It interacts with other elements of the 432 policy, provisioning, and configuration system by means outside of 433 the scope of the I2RS effort. It interacts with the I2RS agents 434 to collect information from the routing and forwarding system. 435 Based on the information and the policy oriented interactions, the 436 I2RS client may also interact with I2RS agents to modify the state 437 of their associated routing systems to achieve operational goals. 438 An I2RS client can be seen as the part of an application that uses 439 and supports I2RS and could be a software library. 441 service or I2RS Service: For the purposes of I2RS, a service refers 442 to a set of related state access functions together with the 443 policies that control their usage. The expectation is that a 444 service will be represented by a data-model. For instance, 'RIB 445 service' could be an example of a service that gives access to 446 state held in a device's RIB. 448 read scope: The read scope of an I2RS client within an I2RS agent 449 is the set of information which the I2RS client is authorized to 450 read within the I2RS agent. The read scope specifies the access 451 restrictions to both see the existence of data and read the value 452 of that data. 454 notification scope: The set of events and associated information 455 that the I2RS client can request be pushed by the I2RS agent. 456 I2RS clients have the ability to register for specific events and 457 information streams, but must be constrained by the access 458 restrictions associated with their notification scope. 460 write scope: The set of field values which the I2RS client is 461 authorized to write (i.e. add, modify or delete). This access can 462 restrict what data can be modified or created, and what specific 463 value sets and ranges can be installed. 465 scope: When unspecified as either read scope, write scope, or 466 notification scope, the term scope applies to the read scope, 467 write scope, and notification scope. 469 resources: A resource is an I2RS-specific use of memory, storage, 470 or execution that a client may consume due to its I2RS operations. 471 The amount of each such resource that a client may consume in the 472 context of a particular agent may be constrained based upon the 473 client's security role. An example of such a resource could 474 include the number of notifications registered for. These are not 475 protocol-specific resources or network-specific resources. 477 role or security role: A security role specifies the scope, 478 resources, priorities, etc. that a client or agent has. If a 479 identity has multiple roles in the security system, the identity 480 is permitted to perform any operations any of those roles permit. 481 Multiple identities may use the same security role. 483 identity: A client is associated with exactly one specific 484 identity. State can be attributed to a particular identity. It 485 is possible for multiple communication channels to use the same 486 identity; in that case, the assumption is that the associated 487 client is coordinating such communication. 489 Identity and scope: A single identity can be associated with 490 multiple roles. Each role has its own scope and an identity 491 associated with multiple roles can use the combined scope of all 492 its roles. More formally, each identity has: 494 a read-scope that is the logical OR of the read-scopes 495 associated with its roles, 497 a write-scope that is the logical OR of the write-scopes 498 associated with its roles, and 500 a notification-scope that is the logical OR of the 501 notification-scopes associated with its roles. 503 secondary identity: An I2RS client may supply a secondary opaque 504 identifier for a secondary identity that is not interpreted by the 505 I2RS agent. An example of the use of the secondary opaque 506 identifier is when the I2RS client is a go-between for multiple 507 applications and it is necessary to track which application has 508 requested a particular operation. 510 ephemeral data: is data which does not persist across a reboot 511 (software or hardware) or a power on/off condition. Ephemeral 512 data can be configured data or data recorded from operations of 513 the router. Ephemeral configuration data also has the property 514 that a system cannot roll back to a previous ephemeral 515 configuration state. 517 safe modification of routing state via I2RS: are I2RS ephemeral 518 configuration changes which which modify local configuration 519 rather than the direct modification of protocol-internal state. 520 Direct modifications to protocol-internal state may have unsafe 521 consequences. 523 groups: NETCONF Network Access [RFC6536] uses the term group in 524 terms of an Administrative group which supports the well- 525 established distinction between a root account and other types of 526 less-privileged conceptual user accounts. Group still refers to a 527 single identity (e.g. root) which is shared by a group of users. 529 routing system/subsystem: is a set of software and hardware that 530 handles determining where packets are forwarded to which the I2RS 531 system connects. The term "packets" may be qualified to be layer 532 1 frames, layer 2 frames or layer 3 packets. The phrase "Internet 533 routing system" implies the packets which have IP as layer 3. A 534 routing "subsystem" indicates that the routing software/hardware 535 is only the subsystem of another larger system. 537 3. Key Architectural Properties 539 Several key architectural properties for the I2RS protocol are 540 elucidated below (simplicity, extensibility, and model-driven 541 programmatic interfaces). However, some architecture properties such 542 as performance and scaling are not described below because they are 543 discussed in [I-D.ietf-i2rs-problem-statement], may vary based on the 544 particular use-cases. 546 3.1. Simplicity 548 There have been many efforts over the years to improve the access to 549 the information available to the routing and forwarding system. 550 Making such information visible and usable to network management and 551 applications has many well-understood benefits. There are two 552 related challenges in doing so. First, the quantity and diversity of 553 information potentially available is very large. Second, the 554 variation both in the structure of the data and in the kinds of 555 operations required tends to introduce protocol complexity. 557 While the types of operations contemplated here are complex in their 558 nature, it is critical that I2RS be easily deployable and robust. 559 Adding complexity beyond what is needed to satisfy well known and 560 understood requirements would hinder the ease of implementation, the 561 robustness of the protocol, and the deployability of the protocol. 562 Overly complex data models tend to ossify information sets by 563 attempting to describe and close off every possible option, 564 complicating extensibility. 566 Thus, one of the key aims for I2RS is the keep the protocol and 567 modeling architecture simple. So for each architectural component or 568 aspect, we ask ourselves "do we need this complexity, or is the 569 behavior merely nice to have?" If we need the complexity, we should 570 ask ourselves "Is this the simpliest way to provide in the I2RS 571 external interface?" 573 3.2. Extensibility 575 Extensibility of the protocol and data model is very important. In 576 particular, given the necessary scope limitations of the initial 577 work, it is critical that the initial design include strong support 578 for extensibility. 580 The scope of I2RS work is being designed in phases to provide 581 deliverable and deployable results at every phase. Each phase will 582 have a specific set of requirements, and the I2RS protocol and data 583 models will progress toward these requirements. Therefore, it is 584 clearly desirable for the I2RS data models to be easily and highly 585 extensible to represent additional aspects of the network elements or 586 network systems. It should be easy to integrate data models from the 587 I2RS with other data. This reinforces the criticality of designing 588 the data models to be highly extensible, preferably in a regular and 589 simple fashion. 591 The I2RS Working Group is defining operations for the I2RS protocol. 592 It would be optimistic to assume that more and different ones may not 593 be needed when the scope of I2RS increases. Thus, it is important to 594 consider extensibility not only of the underlying services' data 595 models, but also of the primitives and protocol operations. 597 3.3. Model-Driven Programmatic Interfaces 599 A critical component of I2RS is the standard information and data 600 models with their associated semantics. While many components of the 601 routing system are standardized, associated data models for them are 602 not yet available. Instead, each router uses different information, 603 different mechanisms, and different CLI which makes a standard 604 interface for use by applications extremely cumbersome to develop and 605 maintain. Well-known data modeling languages exist and may be used 606 for defining the data models for I2RS. 608 There are several key benefits for I2RS in using model-driven 609 architecture and protocol(s). First, it allows for data-model 610 focused processing of management data that provides modular 611 implementation in I2RS clients and I2RS agents. The I2RS client only 612 needs to implement the models the I2RS client is able to access. The 613 I2RS agent only needs to implement the data models the I2RS agent 614 supports. 616 Second, tools can automate checking and manipulating data; this is 617 particularly valuable for both extensibility and for the ability to 618 easily manipulate and check proprietary data-models. 620 The different services provided by I2RS can correspond to separate 621 data-models. An I2RS agent may indicate which data-models are 622 supported. 624 The purpose of the data model is to provide a definition of the 625 information regarding the routing system that can be used in 626 operational networks. If routing information is being modeled for 627 the first time, a logical information model may be standardized prior 628 to creating the data model. 630 4. Security Considerations 632 This I2RS architecture describes interfaces that clearly require 633 serious consideration of security. As an architecture, I2RS has been 634 designed to reuse existing protocols that carry network management 635 information. Two of the existing protocols which are being reused 636 for I2RS protocol version 1 are NETCONF [RFC6241] and RESTCONF 637 [I-D.ietf-netconf-restconf]. Additional protocol may be reused in 638 future versions of the I2RS protocol. 640 The I2RS protocol design process will be to specify additional 641 requirements (including security) for the existing protocols in order 642 in order to support the I2RS architecture. After an existing 643 protocol, (e.g. NETCONF or RESTCONF) has been altered to fit the 644 I2RS requirements, then it will be reviewed to determine if it meets 645 these requirements. During this review of changes to existing 646 protocols to serve the I2RS architecture, an in-depth security review 647 of the revised protocol should be done. 649 Due to the re-use strategy of the I2RS architecture, this security 650 section describes the assumed security environment for I2RS with 651 additional details on: a) identity and authentication, b) 652 authorization, and c) client redundancy. Each protocol proposed for 653 inclusion as an I2RS protocol will need to be evaluated for the 654 security constraints of the protocol. The detailed requirements for 655 the I2RS protocol and the I2RS security environment will be defined 656 within these global security environments. 658 The I2RS protocol security requirements for I2RS protocol version 1 659 are contained in [I-D.ietf-i2rs-protocol-security-requirements], and 660 the global I2RS security environment requirements for protocol 661 version 1 are contained [I-D.ietf-i2rs-security-environment-reqs]. 663 First, here is a brief description of the assumed security 664 environment for I2RS. The I2RS agent associated with a Routing 665 Element is a trusted part of that Routing Element. For example, it 666 may be part of a vendor-distributed signed software image for the 667 entire Routing Element or it may be trusted signed application that 668 an operator has installed. The I2RS agent is assumed to have a 669 separate authentication and authorization channel by which it can 670 validate both the identity and permissions associated with an I2RS 671 client. To support numerous and speedy interactions between the I2RS 672 agent and I2RS client, it is assumed that the I2RS agent can also 673 cache that particular I2RS clients are trusted and their associated 674 authorized scope. This implies that the permission information may 675 be old either in a pull model until the I2RS agent re-requests it, or 676 in a push model until the authentication and authorization channel 677 can notify the I2RS agent of changes. 679 Mutual authentication between the I2RS client and I2RS agent is 680 required. An I2RS client must be able to trust that the I2RS agent 681 is attached to the relevant Routing Element so that write/modify 682 operations are correctly applied and so that information received 683 from the I2RS agent can be trusted by the I2RS client. 685 An I2RS client is not automatically trustworthy. Each I2RS client is 686 associated with identity with a set of scope limitations. 687 Applications using an I2RS should be aware that the scope limitations 688 of an I2RS client are based on its identity (see section 4.1) and the 689 assigned role that that identity has sets specific authorization 690 limits on performation actions on an I2RS agent (see section 4.2). 691 For example, one I2RS client may only be able to read a static route 692 table, but another client may be able add an ephemeral route to the 693 static route table. 695 If the I2RS client is acting as a broker for multiple applications, 696 then managing the security, authentication and authorization for that 697 communication is out of scope; nothing prevents the broker from using 698 I2RS protocol and a separate authentication and authorization channel 699 from being used. Regardless of mechanism, an I2RS client that is 700 acting as a broker is responsible for determining that applications 701 using it are trusted and permitted to make the particular requests. 703 Different levels of integrity, confidentiality, and replay protection 704 are relevant for different aspects of I2RS. The primary 705 communication channel that is used for client authentication and then 706 used by the client to write data requires integrity, confidentiality 707 and replay protection. Appropriate selection of a default required 708 transport protocol is the preferred way of meeting these 709 requirements. 711 Other communications via I2RS may not require integrity, 712 confidentiality, and replay protection. For instance, if an I2RS 713 client subscribes to an information stream of prefix announcements 714 from OSPF, those may require integrity but probably not 715 confidentiality or replay protection. Similarly, an information 716 stream of interface statistics may not even require guaranteed 717 delivery. In Section 7.2, additional login regarding multiple 718 communication channels and their use is provided. From the security 719 perspective, it is critical to realize that an I2RS agent may open a 720 new communication channel based upon information provided by an I2RS 721 client (as described in Section 7.2). For example, an I2RS client 722 may request notifications of certain events and the agent will open a 723 communication channel to report such events. Therefore, to avoid an 724 indirect attack, such a request must be done in the context of an 725 authenticated and authorized client whose communications cannot have 726 been altered. 728 4.1. Identity and Authentication 730 As discussed above, all control exchanges between the I2RS client and 731 agent should be authenticated and integrity protected (such that the 732 contents cannot be changed without detection). Further, manipulation 733 of the system must be accurately attributable. In an ideal 734 architecture, even information collection and notification should be 735 protected; this may be subject to engineering tradeoffs during the 736 design. 738 I2RS clients may be operating on behalf of other applications. While 739 those applications' identities are not needed for authentication or 740 authorization, each application should have a unique opaque 741 identifier that can be provided by the I2RS client to the I2RS agent 742 for purposes of tracking attribution of operations to an application 743 identifier (and from that to the application's identity). This 744 tracking of operations to an application supports I2RS functionality 745 for tracing actions (to aid troubleshooting in routers) and logging 746 of network changes. 748 4.2. Authorization 750 All operations using I2RS, both observation and manipulation, should 751 be subject to appropriate authorization controls. Such authorization 752 is based on the identity and assigned role of the I2RS client 753 performing the operations and the I2RS agent in the network element. 754 Multiple Identities may use the same role(s). As noted in the 755 definition of the identity and role above, if multiple roles are 756 associated with an identity then the identity is authorized to 757 perform any operation authorized by any of its roles. 759 I2RS agents, in performing information collection and manipulation, 760 will be acting on behalf of the I2RS clients. As such, each 761 operation authorization will be based on the lower of the two 762 permissions of the agent itself and of the authenticated client. The 763 mechanism by which this authorization is applied within the device is 764 outside of the scope of I2RS. 766 The appropriate or necessary level of granularity for scope can 767 depend upon the particular I2RS Service and the implementation's 768 granularity. An approach to a similar access control problem is 769 defined in the NetConf Access Control Model (NACM) [RFC6536]; it 770 allows arbitrary access to be specified for a data node instance 771 identifier while defining meaningful manipulable defaults. The 772 identity within NACM [RFC6536] can be specify as either a user name 773 or a group user name (e.g. Root), and this name is linked a scope 774 policy that is contained in a set of access control rules. 775 Similarly, it is expected the I2RS identity links to one role which 776 has a scope policy specified by a set of access control rules. This 777 scope policy can be provided via Local Configuration, exposed as an 778 I2RS Service for manipulation by authorized clients, or via some 779 other method (e.g. AAA service) 781 While the I2RS agent allows access based on the I2RS client's scope 782 policy, this does not mean the access is required to arrive on a 783 particular transport connection or from a particular I2RS client by 784 the I2RS architecture. The operator-applied scope policy may/may not 785 restrict the transport connection or the identities that can access a 786 local I2RS agent. 788 When an I2RS client is authenticated, its identity is provided to the 789 I2RS agent, and this identity links to a role which links to the 790 scope policy. Multiple identities may belong to the same role; for 791 example, such a role might be an Internal-Routes-Monitor that allows 792 reading of the portion of the I2RS RIB associated with IP prefixes 793 used for internal device addresses in the AS." 795 4.3. Client Redundancy 797 I2RS must support client redundancy. At the simplest, this can be 798 handled by having a primary and a backup network application that 799 both use the same client identity and can successfully authenticate 800 as such. Since I2RS does not require a continuous transport 801 connection and supports multiple transport sessions, this can provide 802 some basic redundancy. However, it does not address the need for 803 troubleshooting and logging of network changes to be informed about 804 which network application is actually active. At a minimum, basic 805 transport information about each connection and time can be logged 806 with the identity. 808 4.4. I2RS in Personal Devices 810 If an I2RS agent or I2RS client is tightly correlated with a person 811 (such as if an I2RS agent is running on someone's phone to control 812 tethering) then this usage can raise privacy issues, over and above 813 the security issues normally need to be handled in I2RS. One example 814 of an I2RS interaction that could raise privacy issues is if the I2RS 815 interaction enabled easier location tracking of a person's phone. 816 The I2RS protocol and data models should consider if privacy issues 817 can arise when clients or agents are used for such use cases. 819 5. Network Applications and I2RS Client 821 I2RS is expected to be used by network-oriented applications in 822 different architectures. While the interface between a network- 823 oriented application and the I2RS client is outside the scope of 824 I2RS, considering the different architectures is important to 825 sufficiently specify I2RS. 827 In the simplest architecture of direct access, a network-oriented 828 application has an I2RS client as a library or driver for 829 communication with routing elements. 831 In the broker architecture, multiple network-oriented applications 832 communicate in an unspecified fashion to a broker application that 833 contains an I2RS client. That broker application requires additional 834 functionality for authentication and authorization of the network- 835 oriented applications; such functionality is out of scope for I2RS 836 but similar considerations to those described in Section 4.2 do 837 apply. As discussed in Section 4.1, the broker I2RS client should 838 determine distinct opaque identifiers for each network-oriented 839 application that is using it. The broker I2RS client can pass along 840 the appropriate value as a secondary identifier which can be used for 841 tracking attribution of operations. 843 In a third architecture, a routing element or network-oriented 844 application that uses an I2RS client to access services on a 845 different routing element may also contain an I2RS agent to provide 846 services to other network-oriented applications. However, where the 847 needed information and data models for those services differs from 848 that of a conventional routing element, those models are, at least 849 initially, out of scope for I2RS. Below is an example of such a 850 network application 852 5.1. Example Network Application: Topology Manager 854 A Topology Manager includes an I2RS client that uses the I2RS data 855 models and protocol to collect information about the state of the 856 network by communicating directly with one or more I2RS agents. From 857 these I2RS agents, the Topology Manager collects routing 858 configuration and operational data, such as interface and label- 859 switched path (LSP) information. In addition, the Topology Manager 860 may collect link-state data in several ways - either via I2RS models, 861 by peering with BGP-LS[RFC7752] or listening into the IGP. 863 The set of functionality and collected information that is the 864 Topology Manager may be embedded as a component of a larger 865 application, such as a path computation application. As a stand- 866 alone application, the Topology Manager could be useful to other 867 network applications by providing a coherent picture of the network 868 state accessible via another interface. That interface might use the 869 same I2RS protocol and could provide a topology service using 870 extensions to the I2RS data models. 872 6. I2RS Agent Role and Functionality 874 The I2RS agent is part of a routing element. As such, it has 875 relationships with that routing element as a whole, and with various 876 components of that routing element. 878 6.1. Relationship to its Routing Element 880 A Routing Element may be implemented with a wide variety of different 881 architectures: an integrated router, a split architecture, 882 distributed architecture, etc. The architecture does not need to 883 affect the general I2RS agent behavior. 885 For scalability and generality, the I2RS agent may be responsible for 886 collecting and delivering large amounts of data from various parts of 887 the routing element. Those parts may or may not actually be part of 888 a single physical device. Thus, for scalability and robustness, it 889 is important that the architecture allow for a distributed set of 890 reporting components providing collected data from the I2RS agent 891 back to the relevant I2RS clients. There may be multiple I2RS agents 892 within the same router. In such a case, they must have non- 893 overlapping sets of information which they manipulate. 895 To facilitate operations, deployment and troubleshooting, it is 896 important that traceability of the requests received by I2RS agent's 897 and actions taken be supported via a common data model. 899 6.2. I2RS State Storage 901 State modification requests are sent to the I2RS agent in a routing 902 element by I2RS clients. The I2RS agent is responsible for applying 903 these changes to the system, subject to the authorization discussed 904 above. The I2RS agent will retain knowledge of the changes it has 905 applied, and the client on whose behalf it applied the changes. The 906 I2RS agent will also store active subscriptions. These sets of data 907 form the I2RS data store. This data is retained by the agent until 908 the state is removed by the client, overridden by some other 909 operation such as CLI, or the device reboots. Meaningful logging of 910 the application and removal of changes is recommended. I2RS applied 911 changes to the routing element state will not be retained across 912 routing element reboot. The I2RS data store is not preserved across 913 routing element reboots; thus the I2RS agent will not attempt to 914 reapply such changes after a reboot. 916 6.2.1. I2RS Agent Failure 918 It is expected that an I2RS agent may fail independently of the 919 associated routing element. This could happen because I2RS is 920 disabled on the routing element or because the I2RS agent, a separate 921 process or even running on a separate processor, experiences an 922 unexpected failure. Just as routing state learned from a failed 923 source is removed, the ephemeral I2RS state will usually be removed 924 shortly after the failure is detected or as part of a graceful 925 shutdown process. To handle these two types of failures, the I2RS 926 agent MUST support two different notifications: a notification for 927 the I2RS agent terminating gracefully, and a notification for the 928 I2RS agent starting up after an unexpected failure. The two 929 notifications are described below followed by the a description of 930 their use in unexpected failures and graceful shutdowns. 932 NOTIFICATION_I2RS_AGENT_TERMINATING: This notification reports that 933 the associated I2RS agent is shutting down gracefully, and that 934 I2RS ephemeral state will be removed. It can optionally include a 935 timestamp indicating when the I2RS agent will shutdown. Use of 936 this timestamp assumes that time synchronization has been done and 937 the timestamp should not have granularity finer than one second 938 because better accuracy of shutdown time is not guaranteed. 940 NOTIFICATION_I2RS_AGENT_STARTING: This notification signals to the 941 I2RS client(s) that the associated I2RS agent has started. It 942 includes an agent-boot-count that indicates how many times the 943 I2RS agent has restarted since the associated routing element 944 restarted. The agent-boot-count allows an I2RS client to 945 determine if the I2RS agent has restarted. (Note: This 946 notification will on be sent by the I2RS agent to I2RS clients 947 which are known by the I2RS agent after a reboot. How the I2RS 948 agent retains the knowledge of these I2RS clients is out of scope 949 of this architecture.) 951 There are two different failure types that are possible and each has 952 different behavior. 954 Unexpected failure: In this case, the I2RS agent has unexpectedly 955 crashed and thus cannot notify its clients of anything. Since 956 I2RS does not require a persistent connection between the I2RS 957 client and I2RS agent, it is necessary to have a mechanism for the 958 I2RS agent to notify I2RS clients that had subscriptions or 959 written ephemeral state; such I2RS clients should be cached by the 960 I2RS agent's system in persistent storage. When the I2RS agent 961 starts, it should send a NOTIFICATION_I2RS_AGENT_STARTING to each 962 cached I2RS client. 964 Graceful shutdowns: In this case, the I2RS agent can do specific 965 limited work as part of the process of being disabled. The I2RS 966 agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all its 967 cached I2RS clients. If the I2RS agent restarts after a graceful 968 termination, it will send a NOTIFICATION_I2RS_AGENT_STARTING to 969 each cached I2RS client. 971 6.2.2. Starting and Ending 973 When an I2RS client applies changes via the I2RS protocol, those 974 changes are applied and left until removed or the routing element 975 reboots. The network application may make decisions about what to 976 request via I2RS based upon a variety of conditions that imply 977 different start times and stop times. That complexity is managed by 978 the network application and is not handled by I2RS. 980 6.2.3. Reversion 982 An I2RS agent may decide that some state should no longer be applied. 983 An I2RS client may instruct an agent to remove state it has applied. 984 In all such cases, the state will revert to what it would have been 985 without the I2RS client-agent interaction; that state is generally 986 whatever was specified via the CLI, NETCONF, SNMP, etc. I2RS agents 987 will not store multiple alternative states, nor try to determine 988 which one among such a plurality it should fall back to. Thus, the 989 model followed is not like the RIB, where multiple routes are stored 990 at different preferences. (For I2RS state in the presence of two 991 I2RS clients, please see section 1.2 and section 7.8) 992 An I2RS client may register for notifications, subject to its 993 notification scope, regarding state modification or removal by a 994 particular I2RS client. 996 6.3. Interactions with Local Configuration 998 Changes may originate from either Local Configuration or from I2RS. 999 The modifications and data stored by I2RS are separate from the local 1000 device configuration, but conflicts between the two must be resolved 1001 in a deterministic manner that respects operator-applied policy. The 1002 deterministic manner is the result of general I2RS rules, system 1003 rules, knobs adjusted by operator-applied policy, and the rules 1004 associated with the YANG data model (often in MUST and WHEN clauses 1005 for dependencies). 1007 The operator-applied policy knobs can determine whether the Local 1008 Configuration overrides a particular I2RS client's request or vice 1009 versa. Normally, most devices will have an operator-applied policy 1010 that will prioritize the I2RS client's ephemeral configuration 1011 changes so that ephemeral data overides the Local Configuration. 1013 These operator-applied policy knobs can be implemented in many ways. 1014 One way is for the routing element to configure a priority on the 1015 Local Configuration and and a priority on the I2RS client's write of 1016 the ephemeral configuration. The I2RS mechanism would compare the 1017 I2RS client's priority to write with that priority assigned to the 1018 Local Configuration in order to determine whether Local Configuration 1019 or I2RS Client's write of ephemeral data wins. 1021 To make sure the I2RS clients requests are what the operator desires, 1022 the I2RS data modules have a general rule that by default the Local 1023 Configuration always wins over the I2RS ephemeral configuration. 1025 The reason for this general rule is if there is no operator-applied 1026 policy to turn on I2RS ephemeral overwrites of Local Configuration, 1027 then the I2RS overwrites should not occur. This general rule allows 1028 the I2RS agents to be installed in routing systems, and the 1029 communication tested between I2RS clients and I2RS agents without the 1030 I2RS agent overwriting configuration state. For more details, see 1031 the examples below. 1033 For the case when the I2RS ephemeral state always wins for a data 1034 model, if there is an I2RS ephemeral state value is installed instead 1035 of the local configuration state. The local configuration 1036 information is stored so that if/when I2RS client removes I2RS 1037 ephemeral state the local configuration state can be restored. 1039 When the Local Configuration always wins, some communication between 1040 that subsystem and the I2RS agent is still necessary. As an I2RS 1041 agent connects to the routing sub-system, the I2RS agent must also 1042 communicate with the Local Configuration to exchange model 1043 information so the I2RS agent knows the details of each specific 1044 device configuration change that the I2RS agent is permitted to 1045 modify. In addition, when the system determines, that a client's 1046 I2RS state is preempted, the I2RS agent must notify the affected I2RS 1047 clients; how the system determines this is implementation-dependent. 1049 It is critical that policy based upon the source is used because the 1050 resolution cannot be time-based. Simply allowing the most recent 1051 state to prevail could cause race conditions where the final state is 1052 not repeatably deterministic. 1054 6.3.1. Examples of Local Configuration vs. I2RS Ephemeral Configuration 1056 A set of examples are useful in order to illustrated these 1057 architecture principles. Assume there are three routers: router A, 1058 router B, and router C. There are two operator-applied policy knobs 1059 that these three routers must have regarding ephemeral state. 1061 Policy Knob 1: Ephemeral configuration overwrites local 1062 configuration. 1064 Policy Knob 2: Update of local configuration value supercedes and 1065 overwrites the ephemeral configuration. 1067 For Policy Knob 1, the routers with I2RS agent receiving a write for 1068 an ephemeral entry in a Data Model must consider the following: 1070 1. Does the operator policy allow the ephemeral configuration 1071 changes to have priority over existing local configuration? 1073 2. Does the YANG data model have any rules associated with the 1074 ephemeral configuration (such as "MUST" or "WHEN" rule)? 1076 For this example, there is no "MUST" or "WHEN" rule in the data being 1077 written. 1079 The policy settings are: 1081 Policy Knob 1 Policy Knob 2 1082 ================ =============== 1083 Router A ephemeral has ephemeral has 1084 priority priority 1086 Router B local config has local config has 1087 priority priority 1089 Router C ephemeral has local config 1090 priority has priority 1092 Router A has the normal operator policy in Policy Knob 1 and Policy 1093 Knob 2 that prioritizes ephemeral configuration over Local 1094 Configuration in the I2RS agent. An I2RS client sends a write to an 1095 ephemeral configuration value via I2RS agent in Router A. The I2RS 1096 agent overwrites the configuration value in the intended 1097 configuration, and the I2RS agent returns an acknowledgement of the 1098 write. If the Local Configuration value changes, Router A stays with 1099 the ephemeral configuration written by the I2RS client. 1101 Router B's operator has no desire to allow ephemeral writes to 1102 overwrite Local Configuration even though it has installed an I2RS 1103 agent. Router B's policy prioritizes the Local Configuration over 1104 the ephemeral write. When the I2RS agent on Router B receives a 1105 write from an I2RS client, the I2RS agent will check the operator 1106 Policy Knob 1 and return a response to the I2RS client indicating the 1107 operator policy did not allow the overwriting of the Local 1108 Configuration. 1110 Router B case demonstrates why the I2RS architecture sets the default 1111 to the Local Configuration wins. Since I2RS functionality is new, 1112 the operator must enable it. Otherwise, the I2RS ephemeral 1113 functionality is off. Router B's operators can install the I2RS code 1114 and test responses without engaging the I2RS overwrite function. 1116 Router C's operator sets the Policy Knob 1 for the I2RS clients to 1117 overwrite existing Local Configuration and the Policy Knob 2 for the 1118 Local Configuration changes to update ephemeral state. To understand 1119 why an operator might set the policy knobs this way, consider that 1120 Router C is under the control of an operator that has a back-end 1121 system that re-writes the the Local Configuration of all systems at 1122 11pm each night. Any ephemeral change to the network is only 1123 supposed to last until 11pm when the next Local Configuration changes 1124 are rolled out from the back-end system. The I2RS client writes the 1125 ephemeral state during the day, and the I2RS agent on router C 1126 updates the value. At 11pm, the back-end configuration system 1127 updates the Local Configuration via NETCONF and the I2RS agent is 1128 notified the Local Configuration updated this value. The I2RS agent 1129 notifies the I2RS client that the value has been overwritten by the 1130 Local Configuration. The I2RS client in this use case is a part of 1131 an application that tracks any ephemeral state changes to make sure 1132 all ephemeral changes are included in the next configuration run. 1134 6.4. Routing Components and Associated I2RS Services 1136 For simplicity, each logical protocol or set of functionality that 1137 can be compactly described in a separable information and data model 1138 is considered as a separate I2RS Service. A routing element need not 1139 implement all routing components described nor provide the associated 1140 I2RS services. I2RS Services should include a capability model so 1141 that peers can determine which parts of the service are supported. 1142 Each I2RS Service requires an information model that describes at 1143 least the following: data that can be read, data that can be written, 1144 notifications that can be subscribed to, and the capability model 1145 mentioned above. 1147 The initial services included in the I2RS architecture are as 1148 follows. 1150 *************************** ************** ***************** 1151 * I2RS Protocol * * * * Dynamic * 1152 * * * Interfaces * * Data & * 1153 * +--------+ +-------+ * * * * Statistics * 1154 * | Client | | Agent | * ************** ***************** 1155 * +--------+ +-------+ * 1156 * * ************** ************* 1157 *************************** * * * * 1158 * Policy * * Base QoS * 1159 ******************** ******** * Templates * * Templates * 1160 * +--------+ * * * * * ************* 1161 * BGP | BGP-LS | * * PIM * ************** 1162 * +--------+ * * * 1163 ******************** ******** **************************** 1164 * MPLS +---------+ +-----+ * 1165 ********************************** * | RSVP-TE | | LDP | * 1166 * IGPs +------+ +------+ * * +---------+ +-----+ * 1167 * +--------+ | OSPF | |IS-IS | * * +--------+ * 1168 * | Common | +------+ +------+ * * | Common | * 1169 * +--------+ * * +--------+ * 1170 ********************************** **************************** 1172 ************************************************************** 1173 * RIB Manager * 1174 * +-------------------+ +---------------+ +------------+ * 1175 * | Unicast/multicast | | Policy-Based | | RIB Policy | * 1176 * | RIBs & LIBs | | Routing | | Controls | * 1177 * | route instances | | (ACLs, etc) | +------------+ * 1178 * +-------------------+ +---------------+ * 1179 ************************************************************** 1181 Figure 2: Anticipated I2RS Services 1183 There are relationships between different I2RS Services - whether 1184 those be the need for the RIB to refer to specific interfaces, the 1185 desire to refer to common complex types (e.g. links, nodes, IP 1186 addresses), or the ability to refer to implementation-specific 1187 functionality (e.g. pre-defined templates to be applied to interfaces 1188 or for QoS behaviors that traffic is direct into). Section 6.4.5 1189 discusses information modeling constructs and the range of 1190 relationship types that are applicable. 1192 6.4.1. Routing and Label Information Bases 1194 Routing elements may maintain one or more Information Bases. 1195 Examples include Routing Information Bases such as IPv4/IPv6 Unicast 1196 or IPv4/IPv6 Multicast. Another such example includes the MPLS Label 1197 Information Bases, per-platform or per-interface or per-context. 1199 This functionality, exposed via an I2RS Service, must interact 1200 smoothly with the same mechanisms that the routing element already 1201 uses to handle RIB input from multiple sources, so as to safely 1202 change the system state. Conceptually, this can be handled by having 1203 the I2RS agent communicate with a RIB Manager as a separate routing 1204 source. 1206 The point-to-multipoint state added to the RIB does not need to match 1207 to well-known multicast protocol installed state. The I2RS agent can 1208 create arbitrary replication state in the RIB, subject to the 1209 advertised capabilities of the routing element. 1211 6.4.2. IGPs, BGP and Multicast Protocols 1213 A separate I2RS Service can expose each routing protocol on the 1214 device. Such I2RS services may include a number of different kinds 1215 of operations: 1217 o reading the various internal RIB(s) of the routing protocol is 1218 often helpful for understanding the state of the network. 1219 Directly writing to these protocol-specific RIBs or databases is 1220 out of scope for I2RS. 1222 o reading the various pieces of policy information the particular 1223 protocol instance is using to drive its operations. 1225 o writing policy information such as interface attributes that are 1226 specific to the routing protocol or BGP policy that may indirectly 1227 manipulate attributes of routes carried in BGP. 1229 o writing routes or prefixes to be advertised via the protocol. 1231 o joining/removing interfaces from the multicast trees. 1233 o subscribing to an information stream of route changes 1235 o receiving notifications about peers coming up or going down. 1237 For example, the interaction with OSPF might include modifying the 1238 local routing element's link metrics, announcing a locally-attached 1239 prefix, or reading some of the OSPF link-state database. However, 1240 direct modification of the link-state database must not be allowed in 1241 order to preserve network state consistency. 1243 6.4.3. MPLS 1245 I2RS Services will be needed to expose the protocols that create 1246 transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. 1247 BGP, LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, 1248 L2VPNs, etc). This should include all local information about LSPs 1249 originating in, transiting, or terminating in this Routing Element. 1251 6.4.4. Policy and QoS Mechanisms 1253 Many network elements have separate policy and QoS mechanisms, 1254 including knobs which affect local path computation and queue control 1255 capabilities. These capabilities vary widely across implementations, 1256 and I2RS cannot model the full range of information collection or 1257 manipulation of these attributes. A core set does need to be 1258 included in the I2RS information models and supported in the expected 1259 interfaces between the I2RS agent and the network element, in order 1260 to provide basic capabilities and the hooks for future extensibility. 1262 By taking advantage of extensibility and sub-classing, information 1263 models can specify use of a basic model that can be replaced by a 1264 more detailed model. 1266 6.4.5. Information Modeling, Device Variation, and Information 1267 Relationships 1269 I2RS depends heavily on information models of the relevant aspects of 1270 the Routing Elements to be manipulated. These models drive the data 1271 models and protocol operations for I2RS. It is important that these 1272 information models deal well with a wide variety of actual 1273 implementations of Routing Elements, as seen between different 1274 products and different vendors. There are three ways that I2RS 1275 information models can address these variations: class or type 1276 inheritance, optional features, and templating. 1278 6.4.5.1. Managing Variation: Object Classes/Types and Inheritance 1280 Information modelled by I2RS from a Routing Element can be described 1281 in terms of classes or types or object. Different valid inheritance 1282 definitions can apply. What is appropriate for I2RS to use is not 1283 determined in this architecture; for simplicity, class and subclass 1284 will be used as the example terminology. This I2RS architecture does 1285 require the ability to address variation in Routing Elements by 1286 allowing information models to define parent or base classes and 1287 subclasses. 1289 The base or parent class defines the common aspects that all Routing 1290 Elements are expected to support. Individual subclasses can 1291 represent variations and additional capabilities. When applicable, 1292 there may be several levels of refinement. The I2RS protocol can 1293 then provide mechanisms to allow an I2RS client to determine which 1294 classes a given I2RS agent has available. I2RS clients which only 1295 want basic capabilities can operate purely in terms of base or parent 1296 classes, while a client needing more details or features can work 1297 with the supported sub-class(es). 1299 As part of I2RS information modeling, clear rules should be specified 1300 for how the parent class and subclass can relate; for example, what 1301 changes can a subclass make to its parent? The description of such 1302 rules should be done so that it can apply across data modeling tools 1303 until the I2RS data modeling language is selected. 1305 6.4.5.2. Managing Variation: Optionality 1307 I2RS Information Models must be clear about what aspects are 1308 optional. For instance, must an instance of a class always contain a 1309 particular data field X? If so, must the client provide a value for 1310 X when creating the object or is there a well-defined default value? 1311 From the Routing Element perspective, in the above example, each 1312 Information model should provide information that: 1314 o Is X required for the data field to be accepted and applied? 1316 o If X is optional, then how does "X" as an optional portion of data 1317 field interact with the required aspects of the data field? 1319 o Does the data field have defaults for the mandatory portion of the 1320 field and the optional portions of the field 1322 o Is X required to be within a particular set of values (e.g. range, 1323 length of strings)? 1325 The information model needs to be clear about what read or write 1326 values are set by client and what responses or actions are required 1327 by the agent. It is important to indicate what is required or 1328 optional in client values and agent responses/actions. 1330 6.4.5.3. Managing Variation: Templating 1332 A template is a collection of information to address a problem; it 1333 cuts across the notions of class and object instances. A template 1334 provides a set of defined values for a set of information fields and 1335 can specify a set of values that must be provided to complete the 1336 template. Further, a flexible template scheme may allow some of the 1337 defined values can be over-written. 1339 For instance, assigning traffic to a particular service class might 1340 be done by specifying a template Queueing with a parameter to 1341 indicate Gold, Silver, or Best Effort. The details of how that is 1342 carried out are not modeled. This does assume that the necessary 1343 templates are made available on the Routing Element via some 1344 mechanism other than I2RS. The idea is that by providing suitable 1345 templates for tasks that need to be accomplished, with templates 1346 implemented differently for different kinds of Routing Elements, the 1347 client can easily interact with the Routing Element without concern 1348 for the variations which are handled by values included in the 1349 template. 1351 If implementation variation can be exposed in other ways, templates 1352 may not be needed. However, templates themselves could be objects 1353 referenced in the protocol messages, with Routing Elements being 1354 configured with the proper templates to complete the operation. This 1355 is a topic for further discussion. 1357 6.4.5.4. Object Relationships 1359 Objects (in a Routing Element or otherwise) do not exist in 1360 isolation. They are related to each other. One of the important 1361 things a class definition does is represent the relationships between 1362 instances of different classes. These relationships can be very 1363 simple, or quite complicated. The following lists the information 1364 relationships that the information models need to support. 1366 6.4.5.4.1. Initialization 1368 The simplest relationship is that one object instance is initialized 1369 by copying another. For example, one may have an object instance 1370 that represents the default setup for a tunnel, and all new tunnels 1371 have fields copied from there if they are not set as part of 1372 establishment. This is closely related to the templates discussed 1373 above, but not identical. Since the relationship is only momentary 1374 it is often not formally represented in modeling, but only captured 1375 in the semantic description of the default object. 1377 6.4.5.4.2. Correlation Identification 1379 Often, it suffices to indicate in one object that it is related to a 1380 second object, without having a strong binding between the two. So 1381 an Identifier is used to represent the relationship. This can be 1382 used to allow for late binding, or a weak binding that does not even 1383 need to exist. A policy name in an object might indicate that if a 1384 policy by that name exists, it is to be applied under some 1385 circumstance. In modeling, this is often represented by the type of 1386 the value. 1388 6.4.5.4.3. Object References 1390 Sometimes the relationship between objects is stronger. A valid ARP 1391 entry has to point to the active interface over which it was derived. 1392 This is the classic meaning of an object reference in programming. 1393 It can be used for relationships like containment or dependence. 1394 This is usually represented by an explicit modeling link. 1396 6.4.5.4.4. Active Reference 1398 There is an even stronger form of coupling between objects if changes 1399 in one of the two objects are always to be reflected in the state of 1400 the other. For example, if a Tunnel has an MTU (maximum transmit 1401 unit), and link MTU changes need to immediately propagate to the 1402 Tunnel MTU, then the tunnel is actively coupled to the link 1403 interface. This kind of active state coupling implies some sort of 1404 internal bookkeeping to ensure consistency, often conceptualized as a 1405 subscription model across objects. 1407 7. I2RS Client Agent Interface 1409 7.1. One Control and Data Exchange Protocol 1411 This I2RS architecture assumes a data-model driven protocol where the 1412 data-models are defined in YANG 1.1 ([I-D.ietf-netmod-rfc6020bis]), 1413 and associated YANG based model drafts ([RFC6991], [RFC7223], 1414 [RFC7224], [RFC7277], [RFC7317]). Two the protocols to be expanded 1415 to support the I2RS protocol are NETCONF [RFC6241] and RESTCONF 1416 [I-D.ietf-netconf-restconf]. This helps meet the goal of simplicity 1417 and thereby enhances deployability. The I2RS protocol may need to 1418 use several underlying transports (TCP, SCTP (stream control 1419 transport protocol), DCCP (Datagram Congestion Control Protocol)), 1420 with suitable authentication and integrity protection mechanisms. 1421 These different transports can support different types of 1422 communication (e.g. control, reading, notifications, and information 1423 collection) and different sets of data. Whatever transport is used 1424 for the data exchange, it must also support suitable congestion 1425 control mechanisms. The transports chosen should be operator and 1426 implementor friendly to ease adoption. 1428 Each version of the I2RS protocol will specify the following: a) 1429 which transports the I2RS protocol may used by the I2RS protocol. b) 1430 which transports are mandatory to implement, and c) which transports 1431 are optional to implement. 1433 7.2. Communication Channels 1435 Multiple communication channels and multiple types of communication 1436 channels are required. There may be a range of requirements (e.g. 1437 confidentiality, reliability), and to support the scaling there may 1438 need to be channels originating from multiple sub-components of a 1439 routing element and/or to multiple parts of an I2RS client. All such 1440 communication channels will use the same higher-layer I2RS protocol 1441 (which combines secure transport and I2RS contextual information). 1442 The use of additional channels for communication will be coordinated 1443 between the I2RS client and the I2RS agent using this protocol. 1445 I2RS protocol communication may be delivered in-band via the routing 1446 system's data plane. I2RS protocol communication might be delivered 1447 out-of-band via a management interface. Depending on what operations 1448 are requested, it is possible for the I2RS protocol communication to 1449 cause the in-band communication channels to stop working; this could 1450 cause the I2RS agent to become unreachable across that communication 1451 channel. 1453 7.3. Capability Negotiation 1455 The support for different protocol capabilities and I2RS Services 1456 will vary across I2RS clients and Routing Elements supporting I2RS 1457 agents. Since each I2RS Service is required to include a capability 1458 model (see Section 6.4), negotiation at the protocol level can be 1459 restricted to protocol specifics and which I2RS Services are 1460 supported. 1462 Capability negotiation (such as which transports are supported beyond 1463 the minimum required to implement) will clearly be necessary. It is 1464 important that such negotiations be kept simple and robust, as such 1465 mechanisms are often a source of difficulty in implementation and 1466 deployment. 1468 The protocol capability negotiation can be segmented into the basic 1469 version negotiation (required to ensure basic communication), and the 1470 more complex capability exchange which can take place within the base 1471 protocol mechanisms. In particular, the more complex protocol and 1472 mechanism negotiation can be addressed by defining information models 1473 for both the I2RS agent and the I2RS client. These information 1474 models can describe the various capability options. This can then 1475 represent and be used to communicate important information about the 1476 agent, and the capabilities thereof. 1478 7.4. Scope Policy Specifications 1480 As section 4.1 and 4.2 describe, each I2RS client will have a unique 1481 identity and it may have a secondary identity (see section 2) to aid 1482 in troubleshooting. As section 4 indicates, all authentication and 1483 authorization mechanisms are based on the primary Identity which 1484 links to a role with scope policy for reading data, for writing data, 1485 and limitations on the resources that can be consumed. The 1486 specifications for data scope policy (for read, write, or resources 1487 consumption) need to specify the data being controlled by the policy, 1488 and acceptable ranges of values for the data. 1490 7.5. Connectivity 1492 An I2RS client may or may not maintain an active communication 1493 channel with an I2RS agent. Therefore, an I2RS agent may need to 1494 open a communication channel to the client to communicate previously 1495 requested information. The lack of an active communication channel 1496 does not imply that the associated I2RS client is non-functional. 1497 When communication is required, the I2RS agent or I2RS client can 1498 open a new communication channel. 1500 State held by an I2RS agent that is owned by an I2RS client should 1501 not be removed or cleaned up when a client is no longer communicating 1502 - even if the agent cannot successfully open a new communication 1503 channel to the client. 1505 For many applications, it may be desirable to clean up state if a 1506 network application dies before removing the state it has created. 1507 Typically, this is dealt with in terms of network application 1508 redundancy. If stronger mechanisms are desired, mechanisms outside 1509 of I2RS may allow a supervisory network application to monitor I2RS 1510 clients, and based on policy known to the supervisor clean up state 1511 if applications die. More complex mechanisms instantiated in the 1512 I2RS agent would add complications to the I2RS protocol and are thus 1513 left for future work. 1515 Some examples of such a mechanism include the following. In one 1516 option, the client could request state clean-up if a particular 1517 transport session is terminated. The second is to allow state 1518 expiration, expressed as a policy associated with the I2RS client's 1519 role. The state expiration could occur after there has been no 1520 successful communication channel to or from the I2RS client for the 1521 policy-specified duration. 1523 7.6. Notifications 1525 As with any policy system interacting with the network, the I2RS 1526 client needs to be able to receive notifications of changes in 1527 network state. Notifications here refers to changes which are 1528 unanticipated, represent events outside the control of the systems 1529 (such as interface failures on controlled devices), or are 1530 sufficiently sparse as to be anomalous in some fashion. A 1531 notification may also be due to a regular event. 1533 Such events may be of interest to multiple I2RS clients controlling 1534 data handled by an I2RS agent, and to multiple other I2RS clients 1535 which are collecting information without exerting control. The 1536 architecture therefore requires that it be practical for I2RS clients 1537 to register for a range of notifications, and for the I2RS agents to 1538 send notifications to a number of clients. The I2RS client should be 1539 able to filter the specific notifications that will be received; the 1540 specific types of events and filtering operations can vary by 1541 information model and need to be specified as part of the information 1542 model. 1544 The I2RS information model needs to include representation of these 1545 events. As discussed earlier, the capability information in the 1546 model will allow I2RS clients to understand which events a given I2RS 1547 agent is capable of generating. 1549 For performance and scaling by the I2RS client and general 1550 information confidentiality, an I2RS client needs to be able to 1551 register for just the events it is interested in. It is also 1552 possible that I2RS might provide a stream of notifications via a 1553 publish/subscribe mechanism that is not amenable to having the I2RS 1554 agent do the filtering. 1556 7.7. Information collection 1558 One of the other important aspects of the I2RS is that it is intended 1559 to simplify collecting information about the state of network 1560 elements. This includes both getting a snapshot of a large amount of 1561 data about the current state of the network element, and subscribing 1562 to a feed of the ongoing changes to the set of data or a subset 1563 thereof. This is considered architecturally separate from 1564 notifications due to the differences in information rate and total 1565 volume. 1567 7.8. Multi-Headed Control 1569 As was described earlier, an I2RS agent interacts with multiple I2RS 1570 clients who are actively controlling the network element. From an 1571 architecture and design perspective, the assumption is that by means 1572 outside of this system the data to be manipulated within the network 1573 element is appropriately partitioned so that any given piece of 1574 information is only being manipulated by a single I2RS client. 1576 Nonetheless, unexpected interactions happen and two (or more) I2RS 1577 clients may attempt to manipulate the same piece of data. This is 1578 considered an error case. This architecture does not attempt to 1579 determine what the right state of data should be when such a 1580 collision happens. Rather, the architecture mandates that there be 1581 decidable means by which I2RS agents handle the collisions. The 1582 mechanism for ensuring predictability is to have a simple priority 1583 associated with each I2RS clients, and the highest priority change 1584 remains in effect. In the case of priority ties, the first I2RS 1585 client whose attribution is associated with the data will keep 1586 control. 1588 In order for this approach to multi-headed control to be useful for 1589 I2RS clients, it is important that it is possible for an I2RS client 1590 to register for changes to any changes made by I2RS to data that it 1591 may care about. This is included in the I2RS event mechanisms. This 1592 also needs to apply to changes made by CLI/NETCONF/SNMP within the 1593 write-scope of the I2RS agent, as the same priority mechanism (even 1594 if it is "CLI always wins") applies there. The I2RS client may then 1595 respond to the situation as it sees fit. 1597 7.9. Transactions 1599 In the interest of simplicity, the I2RS architecture does not include 1600 multi-message atomicity and rollback mechanisms. Rather, it includes 1601 a small range of error handling for a set of operations included in a 1602 single message. An I2RS client may indicate one of the following 1603 three error handling for a given message with multiple operations 1604 which it sends to an I2RS agent: 1606 Perform all or none: This traditional SNMP semantic indicates that 1607 other I2RS agent will keep enough state when handling a single 1608 message to roll back the operations within that message. Either 1609 all the operations will succeed, or none of them will be applied 1610 and an error message will report the single failure which caused 1611 them not to be applied. This is useful when there are, for 1612 example, mutual dependencies across operations in the message. 1614 Perform until error: In this case, the operations in the message 1615 are applied in the specified order. When an error occurs, no 1616 further operations are applied, and an error is returned 1617 indicating the failure. This is useful if there are dependencies 1618 among the operations and they can be topologically sorted. 1620 Perform all storing errors: In this case, the I2RS agent will 1621 attempt to perform all the operations in the message, and will 1622 return error indications for each one that fails. This is useful 1623 when there is no dependency across the operation, or where the 1624 I2RS client would prefer to sort out the effect of errors on its 1625 own. 1627 In the interest of robustness and clarity of protocol state, the 1628 protocol will include an explicit reply to modification or write 1629 operations even when they fully succeed. 1631 8. Operational and Manageability Considerations 1633 In order to facilitate troubleshooting of routing elements 1634 implementing I2RS agents, the routing elements should provide for a 1635 mechanism to show actively provisioned I2RS state and other I2RS 1636 agent internal information. Note that this information may contain 1637 highly sensitive material subject to the Security Considerations of 1638 any data models implemented by that agent and thus must be protected 1639 according to those considerations. Preferably, this mechanism should 1640 use a different privileged means other than simply connecting as an 1641 I2RS client to learn the data. Using a different mechanism should 1642 improve traceability and failure management. 1644 Manageability plays a key aspect in I2RS. Some initial examples 1645 include: 1647 Resource Limitations: Using I2RS, applications can consume 1648 resources, whether those be operations in a time-frame, entries in 1649 the RIB, stored operations to be triggered, etc. The ability to 1650 set resource limits based upon authorization is important. 1652 Configuration Interactions: The interaction of state installed via 1653 the I2RS and via a router's configuration needs to be clearly 1654 defined. As described in this architecture, a simple priority 1655 that is configured is used to provide sufficient policy 1656 flexibility. 1658 Traceability of Interactions: The ability to trace the interactions 1659 of the requests received by the I2RS agent's and actions taken by 1660 the I2RS agents is needed so that operations can monitor I2RS 1661 agents during deployment, and troubleshoot software or network 1662 problems. 1664 Notification Subscription Service: The ability for an I2RS client to 1665 subscribe to a notification stream pushed from the I2RS agent 1666 (rather than having I2RS client poll the I2RS agent) provides a 1667 more scalable notification handling for the I2RS agent-client 1668 interactions. 1670 9. IANA Considerations 1672 This document includes no request to IANA. 1674 10. Acknowledgements 1676 Significant portions of this draft came from draft-ward-i2rs- 1677 framework-00 and draft-atlas-i2rs-policy-framework-00. 1679 The authors would like to thank Nitin Bahadur, Shane Amante, Ed 1680 Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe 1681 Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott 1682 Brim, Thomas Narten, Dean Bogdanovic, Tom Petch, Robert Raszuk, 1683 Sriganesh Kini, John Mattsson, Nancy Cam-Winget, DaCheng Zhang, Qin 1684 Wu, Ahmed Abro, Salman Asadullah, Eric Yu, Deborah Brungard, Russ 1685 Housley, Russ White, Charlie Kaufman, Benoit Claise, Spencer Dawkins, 1686 and Stephen Farrell for their suggestions and review. 1688 11. References 1690 11.1. Normative References 1692 [I-D.ietf-i2rs-problem-statement] 1693 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 1694 Routing System Problem Statement", draft-ietf-i2rs- 1695 problem-statement-10 (work in progress), February 2016. 1697 11.2. Informative References 1699 [I-D.ietf-i2rs-protocol-security-requirements] 1700 Hares, S., Migault, D., and J. Halpern, "I2RS Security 1701 Related Requirements", draft-ietf-i2rs-protocol-security- 1702 requirements-03 (work in progress), March 2016. 1704 [I-D.ietf-i2rs-security-environment-reqs] 1705 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 1706 Security Requirements", draft-ietf-i2rs-security- 1707 environment-reqs-01 (work in progress), April 2016. 1709 [I-D.ietf-netconf-restconf] 1710 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1711 Protocol", draft-ietf-netconf-restconf-12 (work in 1712 progress), April 2016. 1714 [I-D.ietf-netmod-rfc6020bis] 1715 Bjorklund, M., "The YANG 1.1 Data Modeling Language", 1716 draft-ietf-netmod-rfc6020bis-11 (work in progress), 1717 February 2016. 1719 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1720 and A. Bierman, Ed., "Network Configuration Protocol 1721 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1722 . 1724 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1725 Protocol (NETCONF) Access Control Model", RFC 6536, 1726 DOI 10.17487/RFC6536, March 2012, 1727 . 1729 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1730 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1731 . 1733 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1734 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1735 . 1737 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1738 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1739 . 1741 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 1742 RFC 7277, DOI 10.17487/RFC7277, June 2014, 1743 . 1745 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1746 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1747 2014, . 1749 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1750 S. Ray, "North-Bound Distribution of Link-State and 1751 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1752 DOI 10.17487/RFC7752, March 2016, 1753 . 1755 Authors' Addresses 1757 Alia Atlas 1758 Juniper Networks 1759 10 Technology Park Drive 1760 Westford, MA 01886 1761 USA 1763 Email: akatlas@juniper.net 1765 Joel Halpern 1766 Ericsson 1768 Email: Joel.Halpern@ericsson.com 1770 Susan Hares 1771 Huawei 1773 Email: shares@ndzh.com 1775 Dave Ward 1776 Cisco Systems 1777 Tasman Drive 1778 San Jose, CA 95134 1779 USA 1781 Email: wardd@cisco.com 1783 Thomas D. Nadeau 1784 Brocade 1786 Email: tnadeau@lucidvision.com