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