idnits 2.17.1 draft-ietf-i2rs-architecture-02.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 893: '...ink-state database MUST NOT allowed in...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2014) is 3725 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-00 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-04 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 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: August 16, 2014 Ericsson 6 S. Hares 7 Hickory Hill Consulting 8 D. Ward 9 Cisco Systems 10 T. Nadeau 11 Brocade 12 February 12, 2014 14 An Architecture for the Interface to the Routing System 15 draft-ietf-i2rs-architecture-02 17 Abstract 19 This document describes an architecture for a standard, programmatic 20 interface for state transfer in and out of the Internet's routing 21 system. It describes the basic architecture, the components, and 22 their interfaces with particular focus on those to be standardized as 23 part of I2RS. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 16, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4 61 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3. Key Architectural Properties . . . . . . . . . . . . . . . . 10 64 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10 66 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 4.1. Identity and Authentication . . . . . . . . . . . . . . . 12 69 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 13 70 5. Network Applications and I2RS Client . . . . . . . . . . . . 13 71 5.1. Example Network Application: Topology Manager . . . . . . 14 72 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 14 73 6.1. Relationship to its Routing Element . . . . . . . . . . . 15 74 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 15 75 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 15 76 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 16 77 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 16 78 6.3. Interactions with Local Config . . . . . . . . . . . . . 17 79 6.4. Routing Components and Associated I2RS Services . . . . . 17 80 6.4.1. Routing and Label Information Bases . . . . . . . . . 18 81 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 19 82 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 19 83 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 20 84 6.4.5. Information Modeling, Device Variation, and 85 Information Relationships . . . . . . . . . . . . . . 20 86 6.4.5.1. Managing Variation: Object Classes/Types and 87 Inheritance . . . . . . . . . . . . . . . . . . . 20 88 6.4.5.1.1. Managing Variation: Optionality . . . . . . . 21 89 6.4.5.1.2. Managing Variation: Templating . . . . . . . 21 90 6.4.5.1.3. Object Relationships . . . . . . . . . . . . 22 91 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 23 92 7.1. One Control and Data Exchange Protocol . . . . . . . . . 23 93 7.2. Communication Channels . . . . . . . . . . . . . . . . . 23 94 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 23 95 7.4. Identity and Security Role . . . . . . . . . . . . . . . 24 96 7.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 24 98 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 24 99 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 25 100 7.7. Information collection . . . . . . . . . . . . . . . . . 26 101 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 26 102 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 27 103 8. Manageability Considerations . . . . . . . . . . . . . . . . 27 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 105 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 106 11. Informative References . . . . . . . . . . . . . . . . . . . 28 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 109 1. Introduction 111 Routers that form the Internet's routing infrastructure maintain 112 state at various layers of detail and function. For example, a 113 typical router maintains a Routing Information Base (RIB), and 114 implements routing protocols such as OSPF, ISIS, and BGP to exchange 115 protocol state and other information about the state of the network 116 with other routers. 118 Routers know how to convert all of this information into the 119 forwarding operations that are installed in the forwarding plane. 120 The forwarding plane and the specified forwarding operations then 121 contain active state information that describes the expected and 122 observed operational behavior of the router and which is also needed 123 by the network applications. Network-oriented applications require 124 easy access to this information to learn the network topology, to 125 verify that programmed state is installed in the forwarding plane, to 126 measure the behavior of various flows, routes or forwarding entries, 127 as well as to understand the configured and active states of the 128 router. 130 This document sets out an architecture for a common, standards-based 131 interface to this information. This Interface to the Routing System 132 (I2RS) facilitates control and observation of the routing-related 133 state (for example, a Routing Element RIB manager's state), as well 134 as enabling network-oriented applications to be built on top of 135 today's routed networks. The I2RS is a programmatic asynchronous 136 interface for transferring state into and out of the Internet's 137 routing system. This I2RS architecture recognizes that the routing 138 system and a router's OS provide useful mechanisms that applications 139 could harness to accomplish application-level goals. 141 Fundamental to the I2RS are clear data models that define the 142 semantics of the information that can be written and read. The I2RS 143 provides a framework for registering for and requesting the 144 appropriate information for each particular application. The I2RS 145 provides a way for applications to customize network behavior while 146 leveraging the existing routing system as desired. 148 Although the I2RS architecture is general enough to support 149 information and data models for a variety of data, the I2RS, and 150 therefore this document, are specifically focused on an interface for 151 routing data. 153 1.1. Drivers for the I2RS Architecture 155 There are four key drivers that shape the I2RS architecture. First 156 is the need for an interface that is programmatic, asynchronous, and 157 offers fast, interactive access. Second is the access to structured 158 information and state that is frequently not directly configurable or 159 modeled in existing implementations or configuration protocols. 160 Third is the ability to subscribe to structured, filterable event 161 notifications from the router. Fourth, the operation of I2RS is to 162 be data-model driven to facilitate extensibility and provide standard 163 data-models to be used by network applications. 165 I2RS is described as an asynchronous programmatic interface, the key 166 properties of which are described in Section 5 of 167 [I-D.ietf-i2rs-problem-statement]. 169 The I2RS facilitates obtaining information from the router. The I2RS 170 provides the ability to not only read specific information, but also 171 to subscribe to targeted information streams and filtered and 172 thresholded events. 174 Such an interface also facilitates the injection of ephemeral state 175 into the routing system. A non-routing protocol or application could 176 inject state into a routing element via the state-insertion 177 functionality of the I2RS and that state could then be distributed in 178 a routing or signaling protocol and/or be used locally (e.g. to 179 program the co-located forwarding plane). I2RS will only permit 180 modification of state that would be safe, conceptually, to modify via 181 local configuration; no direct manipulation of protocol-internal 182 dynamically determined data is envisioned. 184 1.2. Architectural Overview 186 Figure 1 shows the basic architecture for I2RS between applications 187 using I2RS, their associated I2RS Clients, and I2RS Agents. 188 Applications access I2RS services through I2RS clients. A single 189 client can provide access to one or more applications. In the 190 figure, Clients A and B provide access to a single application, while 191 Client P provides access to multiple applications. 193 Applications can access I2RS services through local or remote 194 clients. In the figure, Applicatons A and B access I2RS services 195 through local clients, while Applications C, D and E access I2RS 196 services through a remote client. 198 An I2RS Client can access one or more I2RS agents. In the figure, 199 Clients B and P access I2RS Agents 1 and 2. Likewise, an I2RS Agent 200 can provide service to one or more clients. In the figure, I2RS 201 Agent 1 provides services to Clients A, B and P while Agent 2 202 provides services to only Clients B and P. 204 I2RS agents and clients communicate with one another using an 205 asynchronous protocol. Therefore, a single client can post multiple 206 simultaneous requests, either to a single agent or to multiple 207 agents. Furthermore, an agent can process multiple requests, either 208 from a single client or from multiple clients, simultaneously. 210 The I2RS agent provides read and write access to selected data on the 211 routing element that are organized into I2RS Services. 212 Section Section 4 describes how access is mediated by authentication 213 and access control mechanisms. In addition to read and write access, 214 the I2RS agent allows clients to subscribe to different types of 215 notifications about events affecting different object instances. An 216 example not related to the creation, modification or deletion of an 217 object instance is when a next-hop in the RIB is resolved enough to 218 be used or when a particular route is selected by the RIB Manager for 219 installation into the forwarding plane. Please see Section 7.6 and 220 Section 7.7 for details. 222 The scope of I2RS is to define the interactions between the I2RS 223 agent and the I2RS client and the associated proper behavior of the 224 I2RS agent and I2RS client. 226 ****************** ***************** ***************** 227 * Application C * * Application D * * Application E * 228 ****************** ***************** ***************** 229 ^ ^ ^ 230 | | | 231 |--------------| | |--------------| 232 | | | 233 v v v 234 *************** 235 * Client P * 236 *************** 237 ^ ^ 238 | |-------------------------| 239 *********************** | *********************** | 240 * Application A * | * Application B * | 241 * * | * * | 242 * +----------------+ * | * +----------------+ * | 243 * | Client A | * | * | Client B | * | 244 * +----------------+ * | * +----------------+ * | 245 ******* ^ ************* | ***** ^ ****** ^ ****** | 246 | | | | | 247 | |-------------| | | |-----| 248 | | -----------------------| | | 249 | | | | | 250 ************ v * v * v ********* ***************** v * v ******** 251 * +---------------------+ * * +---------------------+ * 252 * | Agent 1 | * * | Agent 2 | * 253 * +---------------------+ * * +---------------------+ * 254 * ^ ^ ^ ^ * * ^ ^ ^ ^ * 255 * | | | | * * | | | | * 256 * v | | v * * v | | v * 257 * +---------+ | | +--------+ * * +---------+ | | +--------+ * 258 * | Routing | | | | Local | * * | Routing | | | | Local | * 259 * | and | | | | Config | * * | and | | | | Config | * 260 * |Signaling| | | +--------+ * * |Signaling| | | +--------+ * 261 * +---------+ | | ^ * * +---------+ | | ^ * 262 * ^ | |scoped | * * ^ | |scoped | * 263 * | |----| | | * * | |----| | | * 264 * v | v v * * v | v v * 265 * +----------+ +------------+ * * +----------+ +------------+ * 266 * | Dynamic | | Static | * * | Dynamic | | Static | * 267 * | System | | System | * * | System | | System | * 268 * | State | | State | * * | State | | State | * 269 * +----------+ +------------+ * * +----------+ +------------+ * 270 * * * * 271 * Routing Element 1 * * Routing Element 2 * 272 ******************************** ******************************** 274 Figure 1: Architecture of I2RS clients and agents 276 Routing Element: A Routing Element implements some subset of the 277 routing system. It does not need to have a forwarding plane 278 associated with it. Examples of Routing Elements can include: 280 * A router with a forwarding plane and RIB Manager that runs 281 ISIS, OSPF, BGP, PIM, etc. 283 * A server that runs BGP as a Route Reflector 285 * An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a 286 forwarding plane and associated RIB Manager. 288 * A server that runs ISIS, OSPF, BGP and uses ForCES to control a 289 remote forwarding plane. 291 A Routing Element may be locally managed, whether via CLI, SNMP, 292 or NETCONF. 294 Routing and Signaling: This block represents that portion of the 295 Routing Element that implements part of the Internet routing 296 system. It includes not merely standardized protocols (i.e. IS- 297 IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager 298 layer. 300 Local Config: A Routing Element will provide the ability to 301 configure and manage it. The Local Config may be provided via a 302 combination of CLI, NETCONF, SNMP, etc. The black box behavior 303 for interactions between the state that I2RS installs into the 304 routing element and the Local Config must be defined. 306 Dynamic System State: An I2RS agent needs access to state on a 307 routing element beyond what is contained in the routing subsystem. 308 Such state may include various counters, statistics, and local 309 events. This is the subset of operational state that is needed by 310 network applications based on I2RS that is not contained in the 311 routing and signaling information. How this information is 312 provided to the I2RS agent is out of scope, but the standardized 313 information and data models for what is exposed are part of I2RS. 315 Static System State: An I2RS agent needs access to static state on 316 a routing element beyond what is contained in the routing 317 subsystem. An example of such state is specifying queueing 318 behavior for an interface or traffic. How the I2RS agent modifies 319 or obtains this information is out of scope, but the standardized 320 information and data models for what is exposed are part of I2RS. 322 I2RS Agent: See the definition in Section 2. 324 Application: A network application that needs to observe the 325 network or manipulate the network to achieve its service 326 requirements. 328 I2RS Client: See the definition in Section 2. 330 As can be seen in Figure 1, an I2RS client can communicate with 331 multiple I2RS agents. An I2RS client may connect to one or more I2RS 332 agents based upon its needs. Similarly, an I2RS agent may 333 communicate with multiple I2RS clients - whether to respond to their 334 requests, to send notifications, etc. Timely notifications are 335 critical so that several simultaneously operating applications have 336 up-to-date information on the state of the network. 338 As can also be seen in Figure 1, an I2RS Agent may communicate with 339 multiple clients. Each client may send the agent a variety of write 340 operations. In order to keep the protocol simple, the current view 341 is that two clients should not be attempting to write (modify) the 342 same piece of information. Such collisions may happen, but are 343 considered error cases that should be resolved by the network 344 applications and management systems. 346 In contrast, although multiple I2RS clients may need to supply data 347 into the same list (e.g. a prefix or filter list), this is not 348 considered an error and must be correctly handled. The nuances so 349 that writers do not normally collide should be handled in the 350 information models. 352 The architectural goal for the I2RS is that such errors should 353 produce predictable behaviors, and be reportable to interested 354 clients. The details of the associated policy is discussed in 355 Section 7.8. The same policy mechanism (simple priority per I2RS 356 client) applies to interactions between the I2RS agent and the CLI/ 357 SNMP/NETCONF as described in Section 6.3. 359 In addition it must be noted that there may be indirect interactions 360 between write operations. A tivial example of this is when two 361 different but overlapping prefixes are written with different 362 forwarding behavior. Detection and avoidance of such interactions is 363 outside the scope of the I2RS work and is left to agent design and 364 implementation. 366 2. Terminology 368 The following terminology is used in this document. 370 agent or I2RS Agent: An I2RS agent provides the supported I2RS 371 services from the local system's routing sub-systems by 372 interacting with the routing element to provide specified 373 behavior. The I2RS agent understands the I2RS protocol and can be 374 contacted by I2RS clients. 376 client or I2RS Client: A client implements the I2RS protocol, uses 377 it to communicate with I2RS Agents, and uses the I2RS services to 378 accomplish a task. It interacts with other elements of the 379 policy, provisioning, and configuration system by means outside of 380 the scope of the I2RS effort. It interacts with the I2RS agents 381 to collect information from the routing and forwarding system. 382 Based on the information and the policy oriented interactions, the 383 I2RS client may also interact with I2RS agents to modify the state 384 of the routing system the client interacts with to achieve 385 operational goals. An I2RS client can be seen as the part of an 386 application that uses and supports I2RS and could be a software 387 library. 389 service or I2RS Service: For the purposes of I2RS, a service refers 390 to a set of related state access functions together with the 391 policies that control their usage. The expectation is that a 392 service will be represented by a data-model. For instance, 'RIB 393 service' could be an example of a service that gives access to 394 state held in a device's RIB. 396 read scope: The set of information which the I2RS client is 397 authorized to read. The read scope specifies the access 398 restrictions to both see the existence of data and read the value 399 of that data. 401 notification scope: The set of events and associated information 402 that the I2RS Client can request be pushed by the I2RS Agent. 403 I2RS Clients have the ability to register for specific events and 404 information streams, but must be constrained by the access 405 restrictions associated with their notification scope. 407 write scope: The set of field values which the I2RS client is 408 authorized to write (i.e. add, modify or delete). This access can 409 restrict what data can be modified or created, and what specific 410 value sets and ranges can be installed. 412 scope: When unspecified as either read scope, write scope, or 413 notification scope, the term scope applies to the read scope, 414 write scope, and notification scope. 416 resources: A resource is an I2RS-specific use of memory, storage, 417 or execution that a client may consume due to its I2RS operations. 418 The amount of each such resource that a client may consume in the 419 context of a particular agent may be constrained based upon the 420 client's security role. An example of such a resource could 421 include the number of notifications registered for. These are not 422 protocol-specific resources or network-specific resources. 424 role or security role: A security role specifies the scope, 425 resources, priorities, etc. that a client or agent has. 427 identity: A client is associated with exactly one specific 428 identity. State can be attributed to a particular identity. It 429 is possible for multiple communication channels to use the same 430 identity; in that case, the assumption is that the associated 431 client is coordinating such communication. 433 secondary identity: An I2RS Client may supply a secondary opaque 434 identity that is not interpreted by the I2RS Agent. An example 435 use is when the I2RS Client is a go-between for multiple 436 applications and it is necessary to track which application has 437 requested a particular operation. 439 3. Key Architectural Properties 441 3.1. Simplicity 443 There have been many efforts over the years to improve the access to 444 the information available to the routing and forwarding system. 445 Making such information visible and usable to network management and 446 applications has many well-understood benefits. There are two 447 related challenges in doing so. First, the quantity and diversity of 448 information potentially available is very large. Second, the 449 variation both in the structure of the data and in the kinds of 450 operations required tends to introduce protocol complexity. 452 Having noted that, it is also critical to the utility of I2RS that it 453 be easily deployable and robust. Complexity in the protocol hinders 454 implementation, robustness, and deployability. Also, data models 455 complexity may complicate extensibility. 457 Thus, one of the key aims for I2RS is the keep the protocol and 458 modeling architecture simple. So for each architectural component or 459 aspect, we ask ourselves "do we need this complexity, or is the 460 behavior merely nice to have?" Protocol parsimony is clearly a goal. 462 3.2. Extensibility 464 Naturally, extensibility of the protocol and data model is very 465 important. In particular, given the necessary scope limitations of 466 the initial work, it is critical that the initial design include 467 strong support for extensibility. 469 The scope of the I2RS work is being restricted in the interests of 470 achieving a deliverable and deployable result. The I2RS Working 471 Group is modeling only a subset of the data of interest. It is 472 clearly desirable for the data models defined in the I2RS to be 473 useful in more general settings. It should be easy to integrate data 474 models from the I2RS with other data. Other work should be able to 475 easily extend it to represent additional aspects of the network 476 elements or network systems. This reinforces the criticality of 477 designing the data models to be highly extensible, preferably in a 478 regular and simple fashion. 480 The I2RS Working Group is defining operations for the I2RS protocol. 481 It would be optimistic to assume that more and different ones may not 482 be needed when the scope of I2RS increases. Thus, it is important to 483 consider extensibility not only of the underlying services' data 484 models, but also of the primitives and protocol operations. 486 3.3. Model-Driven Programmatic Interfaces 488 A critical component of I2RS is the standard information and data 489 models with their associated semantics. While many components of the 490 routing system are standardized, associated data models for them are 491 not yet available. Instead, each router uses different information, 492 different mechanisms, and different CLI which makes a standard 493 interface for use by applications extremely cumbersome to develop and 494 maintain. Well-known data modeling languages exist and may be used 495 for defining the data models for I2RS. 497 There are several key benefits for I2RS in using model-driven 498 architecture and protocol(s). First, it allows for transferring 499 data-models whose content is not explicitly implemented or 500 understood. Second, tools can automate checking and manipulating 501 data; this is particularly valuable for both extensibility and for 502 the ability to easily manipulate and check proprietary data-models. 504 The different services provided by I2RS can correspond to separate 505 data-models. An I2RS agent may indicate which data-models are 506 supported. 508 4. Security Considerations 510 This I2RS architecture describes interfaces that clearly require 511 serious consideration of security. First, here is a brief 512 description of the assumed security environment for I2RS. The I2RS 513 Agent associated with a Routing Element is a trusted part of that 514 Routing Element. For example, it may be part of a vendor-distributed 515 signed software image for the entire Routing Element or it may be 516 trusted signed application that an operator has installed. The I2RS 517 Agent is assumed to have a separate authentication and authorization 518 channel by which it can validate both the identity and permissions 519 associated with an I2RS Client. To support numerous and speedy 520 interactions between the I2RS Agent and I2RS Client, it is assumed 521 that the I2RS Agent can also cache that particular I2RS Clients are 522 trusted and their associated authorized scope. This implies that 523 either in a pull model, the permission information may be old until 524 the I2RS Agent rerequests it, or in a push model, that the 525 authentication and authorization channel can notify the I2RS Agent of 526 changes. 528 An I2RS Client is not automatically trustworthy. It has identity 529 information and applications using that I2RS Client should be aware 530 of the scope limitations of that I2RS Client. If the I2RS Client is 531 acting as a broker for multiple applications, managing the security, 532 authentication and authorization for that communication is out of 533 scope; nothing prevents I2RS and a separate authentication and 534 authorization channel from being used. Regardless of mechanism, an 535 I2RS Client that is acting as a broker is responsible for determining 536 that applications using it are trusted and permitted to make the 537 particular requests. 539 Different levels of integrity, confidentiality, and replay protection 540 are relevant for different aspects of I2RS. The primary 541 communication channel that is used for client authentication and then 542 used by the client to write data requires integrity, privacy and 543 replay protection. Appropriate selection of a default required 544 transport protocol is the preferred way of meeting these 545 requirements. 547 Other communications via I2RS will not require integrity, 548 confidentiality, and replay protection. For instance, if an I2RS 549 Client subscribes to an information stream of prefix announcements 550 from OSPF, those may require integrity but probably not 551 confidentiality or replay protection. Similarly, an information 552 stream of interface statistics may not even require guaranteed 553 delivery. In Section 7.2, more reasoning for multiple communication 554 channels is provided. From the security perspective, it is critical 555 to realize that an I2RS Agent may open a new communication channel 556 based upon information provided by an I2RS Client; to avoid an 557 indirect attack, such a request must be done in the context of an 558 authenticated and authorized client whose communications cannot have 559 been altered. 561 4.1. Identity and Authentication 563 As discussed above, all control exchanges between the I2RS client and 564 agent should be authenticated and integrity protected (such that the 565 contents cannot be changed without detection). Further, manipulation 566 of the system must be accurately attributable. In an ideal 567 architecture, even information collection and notification should be 568 protected; this may be subject to engineering tradeoffs during the 569 design. 571 I2RS clients may be operating on behalf of other applications. While 572 those applications' identities are not needed for authentication or 573 authorization, each application should have a unique opaque 574 identifier that can be provided by the I2RS client to the I2RS agent 575 for purposes of tracking attribution of operations to support 576 functionality such as accounting and troubleshooting. 578 4.2. Authorization 580 All operations using I2RS, both observation and manipulation, should 581 be subject to appropriate authorization controls. Such authorization 582 is based on the identity and assigned role of the I2RS client 583 performing the operations and the I2RS agent in the network element. 585 I2RS Agents, in performing information collection and manipulation, 586 will be acting on behalf of the I2RS clients. As such, each 587 operation authorization will be based on the lower of the two 588 permissions of the agent itself and of the authenticated client. The 589 mechanism by which this authorization is applied within the device is 590 outside of the scope of I2RS. 592 The appropriate or necessary level of granularity for scope can 593 depend upon the particular I2RS Service and the implementation's 594 granularity. An approach to a similar access control problem is 595 defined in the NetConf Access Control Model[RFC6536]; it allows 596 arbitrary access to be specified for a data node instance identifier 597 while defining meaningful manipulable defaults. The ability to 598 specify one or more groups or roles that a particular I2RS Client 599 belongs and then define access controls in terms of those groups or 600 roles is expected. When a client is authenticated, its group or role 601 membership should be provided to the I2RS Agent. The set of access 602 control rules that an I2RS Agent uses would need to be either 603 provided via Local Config, exposed as an I2RS Service for 604 manipulation by authorized clients, or via some other method. 606 5. Network Applications and I2RS Client 608 I2RS is expected to be used by network-oriented applications in 609 different architectures. While the interface between a network- 610 oriented application and the I2RS client is outside the scope of 611 I2RS, considering the different architectures is important to 612 sufficiently specify I2RS. 614 In the simplest architecture, a network-oriented application has an 615 I2RS client as a library or driver for communication with routing 616 elements. 618 In the broker architecture, multiple network-oriented applications 619 communicate in an unspecified fashion to a broker application that 620 contains an I2RS Client. That broker application requires additional 621 functionality for authentication and authorization of the network- 622 oriented applications; such functionality is out of scope for I2RS 623 but similar considerations to those described in Section 4.2 do 624 apply. As discussed in Section 4.1, the broker I2RS Client should 625 determine distinct opaque identifiers for each network-oriented 626 application that is using it. The the broker I2RS Client can pass 627 along the appropriate value as a secondary identifier which can be 628 used for tracking attribution of operations. 630 In the third architecture, a routing element or network-oriented 631 application that uses an I2RS Client to access services on a 632 different routing element may also contain an I2RS agent to provide 633 services to other network-oriented applications. However, where the 634 needed information and data models for those services differs from 635 that of a conventional routing element, those models are, at least 636 initially, out of scope for I2RS. Below is an example of such a 637 network application 639 5.1. Example Network Application: Topology Manager 641 A Topology Manager includes an I2RS client that uses the I2RS data 642 models and protocol to collect information about the state of the 643 network by communicating directly with one or more I2RS agents. From 644 these I2RS agents, the Topology Manager collects routing 645 configuration and operational data, such as interface and label- 646 switched path (LSP) information. In addition, the Topology Manager 647 may collect link-state data in several ways - either via I2RS models, 648 by peering with BGP-LS[I-D.ietf-idr-ls-distribution] or listening 649 into the IGP. 651 The set of functionality and collected information that is the 652 Topology Manager may be embedded as a component of a larger 653 application, such as a path computation application. As a stand- 654 alone application, the Topology Manager could be useful to other 655 network applications by providing a coherent picture of the network 656 state accessible via another interface. That interface might use the 657 same I2RS protocol and could provide a topology service using 658 extensions to the I2RS data models. 660 6. I2RS Agent Role and Functionality 662 The I2RS Agent is part of a routing element. As such, it has 663 relationships with that routing element as a whole, and with various 664 components of that routing element. 666 6.1. Relationship to its Routing Element 668 A Routing Element may be implemented with a wide variety of different 669 architectures: an integrated router, a split architecture, 670 distributed architecture, etc. The architecture does not need to 671 affect the general I2RS agent behavior. 673 For scalability and generality, the I2RS agent may be responsible for 674 collecting and delivering large amounts of data from various parts of 675 the routing element. Those parts may or may not actually be part of 676 a single physical device. Thus, for scalability and robustness, it 677 is important that the architecture allow for a distributed set of 678 reporting components providing collected data from the I2RS agent 679 back to the relevant I2RS clients. As currently envisioned, a given 680 I2RS agent would have only one locus per I2RS service for 681 manipulation of routing element state. 683 6.2. I2RS State Storage 685 State modification requests are sent to the I2RS agent in a routing 686 element by I2RS clients. The I2RS agent is responsible for applying 687 these changes to the system, subject to the authorization discussed 688 above. The I2RS agent will retain knowledge of the changes it has 689 applied, and the client on whose behalf it applied the changes. The 690 I2RS agent will also store active subscriptions. These sets of data 691 form the I2RS data store. This data is retained by the agent until 692 the state is removed by the client, overridden by some other 693 operation such as CLI, or the device reboots. Meaningful logging of 694 the application and removal of changes is recommended. I2RS applied 695 changes to the routing element state will not be retained across 696 routing element reboot. The I2RS data store is not preserved across 697 routing element reboots; thus the I2RS agent will not attempt to 698 reapply such changes after a reboot. 700 6.2.1. I2RS Agent Failure 702 If it is possible for an I2RS Agent to fail independently of the 703 associated routing element, the behavior for any associated ephemeral 704 I2RS state needs to be clearly described. The I2RS state should be 705 preserved until the associated routing element has itself rebooted or 706 until the I2RS state is explicitly torn down. This is desirable 707 since the I2RS Client has no way of learning that an I2RS Agent has 708 unexpected failed until that I2RS Agent has restarted; in the 709 interval between failure and recovery, the I2RS Client will be 710 assuming that its ephemeral state remains. If failure of the I2RS 711 agent causes the ephemeral I2RS state to be removed, then this should 712 be indicated via a capability. 714 There are two different failure types that are possible and each has 715 different behavior. 717 Unexpected failure: In this case, the I2RS Agent has unexpectedly 718 crashed and thus cannot notify its clients of anything. If an 719 I2RS Agent can crash separately from its associated routing 720 element, then that I2RS Agent must cache each known I2RS Client. 721 When an I2RS Agent starts, it notifies each saved I2RS Client that 722 the I2RS Agent is up and includes an agent-boot-count that 723 indicates how many times the I2RS Agent has restarted since the 724 associated routing element restarted. The agent-boot-count allows 725 an I2RS Client to determine if the I2RS Agent has restarted; if 726 so, the I2RS Client may need to resubscribe to notifications and 727 information streams. The I2RS Agent should also indicate whether 728 the I2RS ephemeral state was preserved in the Routing Element. 730 Graceful failure: In this case, the I2RS Agent can do specific 731 limited work as part of the process of being disabled. First, the 732 I2RS Agent can optionally notify all its clients that their state 733 is being torn down; if no such notification is sent, then that 734 ephemeral state is not torn down. Second, the I2RS Agent must 735 notify all its cached clients that the agent is going down. 737 6.2.2. Starting and Ending 739 When an I2RS client applies changes via the I2RS protocol, those 740 changes are applied and left until removed or the routing element 741 reboots. The network application may make decisions about what to 742 request via I2RS based upon a variety of conditions that imply 743 different start times and stop times. That complexity is managed by 744 the network application and is not handled by I2RS. 746 6.2.3. Reversion 748 An I2RS Agent may decide that some state should no longer be applied. 749 An I2RS Client may instruct an Agent to remove state it has applied. 750 In all such cases, the state will revert to what it would have been 751 without the I2RS; that state is generally whatever was specified via 752 the CLI, NETCONF, SNMP, etc. I2RS Agents will not store multiple 753 alternative states, nor try to determine which one among such a 754 plurality it should fall back to. Thus, the model followed is not 755 like the RIB, where multiple routes are stored at different 756 preferences. 758 An I2RS Client may register for notifications, subject to its 759 notification scope, regarding state modification or removal by a 760 particular I2RS Client. 762 6.3. Interactions with Local Config 764 Changes may originate from either Local Config or from I2RS. The 765 modifications and data stored by I2RS are separate from the local 766 device configuration, but conflicts between the two must be resolved 767 in a deterministic manner that respects operator-applied policy. 768 That policy can determine whether Local Config overrides a particular 769 I2RS client's request or vice versa. To achieve this end, either by 770 default Local Config always wins or, optionally, a routing element 771 may permit a priority to be configured on the device for the Local 772 Config mechanism. The policy mechanism in the later case is 773 comparing the I2RS client's priority with that priority assigned to 774 the Local Config. 776 When the Local Config always wins, some communication between that 777 subsystem and the I2RS Agent is still necessary. That communication 778 contains the details of each specific device configuration change 779 that the I2RS Agent is permitted to modify. In addition, when the 780 system determines, that a client's I2RS state is preempted, the I2RS 781 agent must notify the affected I2RS agents; how the system determines 782 this is implementation-dependent. 784 It is critical that policy based upon the source is used because the 785 resolution cannot be time-based. Simply allowing the most recent 786 state to prevail could cause race conditions where the final state is 787 not repeatably deterministic. 789 6.4. Routing Components and Associated I2RS Services 791 For simplicity, each logical protocol or set of functionality that 792 can be compactly described in a separable information and data model 793 is considered as a separate I2RS Service. A routing element need not 794 implement all routing components described nor provide the associated 795 I2RS services. When a full implementation is not mandatory, an I2RS 796 Service should include a capability model so that implementations can 797 indicate which parts of the service are supported. Each I2RS Service 798 requires an information model that describes at least the following: 799 data that can be read, data that can be written, notifications that 800 can be subscribed to, and the capability model mentioned above. 802 The initial services included in the I2RS architecture are as 803 follows. 805 *************************** ************** ***************** 806 * I2RS Protocol * * * * Dynamic * 807 * * * Interfaces * * Data & * 808 * +--------+ +-------+ * * * * Statistics * 809 * | Client | | Agent | * ************** ***************** 810 * +--------+ +-------+ * 811 * * ************** ************* 812 *************************** * * * * 813 * Policy * * Base QoS * 814 ******************** ******** * Templates * * Templates * 815 * +--------+ * * * * * ************* 816 * BGP | BGP-LS | * * PIM * ************** 817 * +--------+ * * * 818 ******************** ******** **************************** 819 * MPLS +---------+ +-----+ * 820 ********************************** * | RSVP-TE | | LDP | * 821 * IGPs +------+ +------+ * * +---------+ +-----+ * 822 * +--------+ | OSPF | | ISIS | * * +--------+ * 823 * | Common | +------+ +------+ * * | Common | * 824 * +--------+ * * +--------+ * 825 ********************************** **************************** 827 ************************************************************** 828 * RIB Manager * 829 * +-------------------+ +---------------+ +------------+ * 830 * | Unicast/multicast | | Policy-Based | | RIB Policy | * 831 * | RIBs & LIBs | | Routing | | Controls | * 832 * | route instances | | (ACLs, etc) | +------------+ * 833 * +-------------------+ +---------------+ * 834 ************************************************************** 836 Figure 2: Anticipated I2RS Services 838 There are relationships between different I2RS Services - whether 839 those be the need for the RIB to refer to specific interfaces, the 840 desire to refer to common complex types (e.g. links, nodes, IP 841 addresses), or the ability to refer to implementation-specific 842 functionality (e.g. pre-defined templates to be applied to interfaces 843 or for QoS behaviors that traffic is direct into). 844 Section Section 6.4.5 discussing information modeling constructs and 845 the range of relationship types that are applicable. 847 6.4.1. Routing and Label Information Bases 849 Routing elements may maintain one or more Information Bases. 850 Examples include Routing Information Bases such as IPv4/IPv6 Unicast 851 or IPv4/IPv6 Multicast. Another such example includes the MPLS Label 852 Information Bases, per-platform- or per-interface." This 853 functionality, exposed via an I2RS Service, must interact smoothly 854 with the same mechanisms that the routing element already uses to 855 handle RIB input from multiple sources, so as to safely change the 856 system state. Conceptually, this can be handled by having the I2RS 857 Agent communicate with a RIB Manager as a separate routing source. 859 The point-to-multipoint state added to the RIB does not need to match 860 to well-known multicast protocol installed state. The I2RS Agent can 861 create arbitrary replication state in the RIB, subject to the 862 advertised capabilities of the routing element. 864 6.4.2. IGPs, BGP and Multicast Protocols 866 A separate I2RS Service can expose each routing protocol on the 867 device. Such I2RS services may include a number of different kinds 868 of operations: 870 o reading the various internal RIB(s) of the routing protocol is 871 often helpful for understanding the state of the network. 872 Directly writing to these protocol-specific RIBs or databases is 873 out of scope for I2RS. 875 o reading the various pieces of policy information the particular 876 protocol instance is using to drive its operations. 878 o writing policy information such as interface attributes that are 879 specific to the routing protocol or BGP policy that may indirectly 880 manipulate attributes of routes carried in BGP. 882 o writing routes or prefixes to be advertised via the protocol. 884 o joining/removing interfaces from the multicast trees 886 o subscribing to an information stream of route changes 888 o receiving notifications about peers coming up or going down 890 For example, the interaction with OSPF might include modifying the 891 local routing element's link metrics, announcing a locally-attached 892 prefix, or reading some of the OSPF link-state database. However, 893 direct modification of of the link-state database MUST NOT allowed in 894 order to preserve network state consistency. 896 6.4.3. MPLS 898 I2RS Services will be needed to expose the protocols that create 899 transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP, 900 LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, 901 L2VPNs, etc). This should include all local information about LSPs 902 originating in, transiting, or terminating in this Routing Element. 904 6.4.4. Policy and QoS Mechanisms 906 Many network elements have separate policy and QoS mechanisms, 907 including knobs which affect local path computation and queue control 908 capabilities. These capabilities vary widely across implementations, 909 and I2RS cannot model the full range of information collection or 910 manipulation of these attributes. A core set does need to be 911 included in the I2RS information models and supported in the expected 912 interfaces between the I2RS Agent and the network element, in order 913 to provide basic capabilities and the hooks for future extensibility. 915 By taking advantage of extensibility and sub-classing, information 916 models can specify use of a basic model that can be replaced by a 917 more detailed model. 919 6.4.5. Information Modeling, Device Variation, and Information 920 Relationships 922 I2RS depends heavily on information models of the relevant aspects of 923 the Routing Elements to be manipulated. These models drive the data 924 models and protocol operations for I2RS. It is important that these 925 informational models deal well with a wide variety of actual 926 implementations of Routing Elements, as seen between different 927 products and different vendors. There are three ways that I2RS 928 information models can address these variations: class or type 929 inheritance, optional features, and templating. 931 6.4.5.1. Managing Variation: Object Classes/Types and Inheritance 933 Information modeled by I2RS from a Routing Element can be described 934 in terms of classes or types or object. Different valid inheritance 935 definitions can apply. What is appropriate for I2RS to use is not 936 determined in this architecture; for simplicity, class and subclass 937 will be used as the example terminology. This I2RS architecture does 938 require the ability to address variation in Routing Elements by 939 allowing information models to define parent or base classes and 940 subclasses. 942 The base or parent class defines the common aspects that all Routing 943 Elements are expected to support. Individual subclasses can 944 represent variations and additional capabilities. When applicable, 945 there may be several levels of refinement. The I2RS protocol can 946 then provide mechanisms to allow an I2RS client to determine which 947 classes a given I2RS Agent has available. Clients which only want 948 basic capabilities can operate purely in terms of base or parent 949 classes, while a client needing more details or features can work 950 with the supported sub-class(es). 952 As part of I2RS information modeling, clear rules should be specified 953 for how the parent class and subclass can relate; for example, what 954 changes a subclass can make to its parent? The description of such 955 rules should be done so that it can apply across data modeling tools 956 until the I2RS data modeling language is selected. 958 6.4.5.1.1. Managing Variation: Optionality 960 I2RS Information Models must be clear about what aspects are 961 optional. For instance, must an instance of a class always contain a 962 particular data field X? If so, must the client provide a value for 963 X when creating the object or is there a well-defined default value? 964 From the Routing Element perspective, in the above example, is 965 support of X required so that values for X can be accepted and 966 processed? If not, how does the I2RS client determine whether the 967 I2RS agent can accept and apply values for X? 969 Optional behavior can also be extended to the ranges of values a 970 given piece of information can take, the length of strings, the 971 existence of particular events, and other aspects of information. 972 The information model needs to be clear about what is required of the 973 clients, what is required of agents, and what is permitted to each 974 one. 976 6.4.5.1.2. Managing Variation: Templating 978 A template is a collection of information to address a problem; it 979 cuts across the notions of class and object instances. A template 980 provides a set of defined values for a set of information fields and 981 can specify a set of values that must be provided to complete the 982 template. Further, a flexible template scheme may that some of the 983 defined values can be over-written. 985 For instance, assigning traffic to a particular service class might 986 be done by specifying a template Queueing with a parameter to 987 indicate Gold, Silver, or Best Effort. The details of how that is 988 carried out are not modeled. This does assume that the necessary 989 templates are made available on the Routing Element via some 990 mechanism other than I2RS. The idea is that by providing suitable 991 templates for tasks that need to be accomplished, with templates 992 implemented differently for different kinds of Routing Elements, the 993 client can easily interact with the Routing Element without concern 994 for the variations which are handled by values included in the 995 template. 997 If implementation variation can be exposed in other ways, templates 998 may not be needed. However, templates themselves could be objects 999 referenced in the protocol messages, with Routing Elements being 1000 configured with the proper templates to complete the operation. This 1001 is a topic for further discussion. 1003 6.4.5.1.3. Object Relationships 1005 Objects (in a Routing Element or otherwise) do not exist in 1006 isolation. They are related to each other. One of the important 1007 things a class definition does is represent the relationships between 1008 instances of different classes. These relationships can be very 1009 simple, or quite complicated. The following lists the information 1010 relationships that the information models need to support. 1011 [[Editors' note: All of these are for discussion, and it is expected 1012 that the list may be changed during WG discussion.]] 1014 6.4.5.1.3.1. Initialization 1016 The simplest relationship is that one object instances is initialized 1017 by copying another. For example, one may have an object instance 1018 that represents the default setup for a tunnel, and all new tunnels 1019 have fields copied from there if they are not set as part of 1020 establishment. This is closely related to the templates discussed 1021 above, but not identical. Since the relationship is only momentary 1022 it is often not formally represented in modeling, but only captured 1023 in the semantic description of the default object. 1025 6.4.5.1.3.2. Correlation Identification 1027 Often, it suffices to indicate in one object that it is related to a 1028 second object, without having a strong binding between the two. So 1029 an Identifier is used to represent the relationship. This can be 1030 used to allow for late binding, or a weak binding that does not even 1031 need to exist. A policy name in an object might indicate that if a 1032 policy by that name exists, it is to be applied under some 1033 circumstance. In modeling this is often represented by the type of 1034 the value. 1036 6.4.5.1.3.3. Object References 1038 Sometimes the relationship between objects is stronger. A valid ARP 1039 entry has to point to the active interface over which it was derived. 1040 This is the classic meaning of an object reference in programming. 1041 It can be used for relationships like containment or dependence. 1042 This is usually represented by an explicit modeling link. 1044 6.4.5.1.3.4. Active Reference 1046 There is an even stronger form of coupling between objects if changes 1047 in one of the two objects are always to be reflected in the state of 1048 the other. For example, if a Tunnel has an MTU, and link MTU changes 1049 need to immediately propagate to the Tunnel MTU, then the tunnel is 1050 actively coupled to the link interface. This kind of active state 1051 coupling implies some sort of internal bookkeeping to ensure 1052 consistency, often conceptualized as a subscription model across 1053 objects. 1055 7. I2RS Client Agent Interface 1057 7.1. One Control and Data Exchange Protocol 1059 This I2RS Architecture presumes that there is one I2RS protocol for 1060 control and data exchange. This helps meet the goal of simplicity 1061 and thereby enhances deployability. Whether such a protocol is built 1062 upon extending existing mechanisms or requires a new mechanism is 1063 under active investigation. That protocol may use several underlying 1064 transports (TCP, SCTP, DCCP), with suitable authentication and 1065 integrity protection mechanisms. These different transports can 1066 support different types of communication (e.g. control, reading, 1067 notifications, and information collection) and different sets of 1068 data. Whatever transport is used for the data exchange, it must also 1069 support suitable congestion control mechanisms. 1071 7.2. Communication Channels 1073 Multiple communication channels and multiple types of communication 1074 channels are required. There may be a range of requirements (e.g. 1075 confidentiality, reliability), and to support the scaling there may 1076 need to be channels originating from multiple sub-components of a 1077 routing element and/or to multiple parts of an I2RS client. All such 1078 communication channels will use the same higher level protocol. Use 1079 of additional channels for communication will be coordinated between 1080 the I2RS client and the I2RS agent. 1082 7.3. Capability Negotiation 1084 The support for different protocol capabilities and I2RS Services 1085 will vary across I2RS Clients and Routing Elements supporting I2RS 1086 Agents. Since each I2RS Service is required to include a capability 1087 model (see Section 6.4), negotiation at the protocol level can be 1088 restricted to protocol specifics and which I2RS Services are 1089 supported. 1091 Capability negotiation (such as which transports are supported beyond 1092 the minimum required to implement) will clearly be necessary. It is 1093 important that such negotiations be kept simple and robust, as such 1094 mechanisms are often a source of difficulty in implementation and 1095 deployment. 1097 The protocol capability negotiation can be segmented into the basic 1098 version negotiation (required to ensure basic communication), and the 1099 more complex capability exchange which can take place within the base 1100 protocol mechanisms. In particular, the more complex protocol and 1101 mechanism negotiation can be addressed by defining information models 1102 for both the I2RS Agent and the I2RS Client. These information 1103 models can describe the various capability options. This can then 1104 represent and be used to communicate important information about the 1105 agent, and the capabilities thereof. 1107 7.4. Identity and Security Role 1109 Each I2RS Client will have a unique identity; it can also have 1110 secondary identities to be used for troubleshooting. A secondary 1111 identity is merely a unique, opaque identifier that may be helpful in 1112 troubleshooting. Via authentication and authorization mechanisms 1113 based on the primary unique identity, the I2RS Client will have a 1114 specific scope for reading data, for writing data, and limitations on 1115 the resources that can be consumed. The scopes need to specify both 1116 the data and the value ranges. 1118 7.4.1. Client Redundancy 1120 I2RS must support client redundancy. At the simplest, this can be 1121 handled by having a primary and a backup network application that 1122 both use the same client identity and can successfully authenticate 1123 as such. Since I2RS does not require a continuous transport 1124 connection and supports multiple transport sessions, this can provide 1125 some basic redundancy. However, it does not address concerns for 1126 troubleshooting and accountability about knowing which network 1127 application is actually active. At a minimum, basic transport 1128 information about each connection and time can be logged with the 1129 identity. 1131 7.5. Connectivity 1133 A client may or may not maintain an active communication channel with 1134 an agent. Therefore, an agent may need to open a communication 1135 channel to the client to communicate previously requested 1136 information. The lack of an active communication channel does not 1137 imply that the associated client is non-functional. When 1138 communication is required, the agent or client can open a new 1139 communication channel. 1141 State held by an agent that is owned by a client should not be 1142 removed or cleaned up when a client is no longer communicating - even 1143 if the agent cannot successfully open a new communication channel to 1144 the client. 1146 For many applications, it may be desirable to clean up state if a 1147 network application dies before removing the state it has created. 1148 Typically, this is dealt with in terms of network application 1149 redundancy. If stronger mechanisms are desired, mechanisms outside 1150 of I2RS may allow a supervisory network application to monitor I2RS 1151 clients, and based on policy known to the supervisor clean up state 1152 if applications die. More complex mechanism instantiated in the I2RS 1153 agent would add complications to the I2RS protocol and are thus left 1154 for future work. 1156 Some examples of such a mechanism include the following. In one 1157 option, the client could request state clean-up if a particular 1158 transport session is terminated. The second is to allow state 1159 expiration, expressed as a policy associated with the I2RS client's 1160 role. The state expiration could occur after there has been no 1161 successful communication channel to or from the I2RS client for the 1162 policy-specified duration. 1164 7.6. Notifications 1166 As with any policy system interacting with the network, the I2RS 1167 Client needs to be able to receive notifications of changes in 1168 network state. Notifications here refers to changes which are 1169 unanticipated, represent events outside the control of the systems 1170 (such as interface failures on controlled devices), or are 1171 sufficiently sparse as to be anomalous in some fashion. A 1172 notification may also be due to a regular event. 1174 Such events may be of interest to multiple I2RS Clients controlling 1175 data handled by an I2RS Agent, and to multiple other I2RS clients 1176 which are collecting information without exerting control. The 1177 architecture therefore requires that it be practical for I2RS Clients 1178 to register for a range of notifications, and for the I2RS Agents to 1179 send notifications to a number of Clients. The I2RS Client should be 1180 able to filter the specific notifications that will be received; the 1181 specific types of events and filtering operations can vary by 1182 information model and need to be specified as part of the information 1183 model. 1185 The I2RS information model needs to include representation of these 1186 events. As discussed earlier, the capability information in the 1187 model will allow I2RS clients to understand which events a given I2RS 1188 Agent is capable of generating. 1190 For performance and scaling by the I2RS client and general 1191 information privacy, an I2RS Client needs to be able to register for 1192 just the events it is interested in. It is also possible that I2RS 1193 might might provide a stream of notifications via a publish/subscribe 1194 mechanism that is not amenable to having the I2RS agent do the 1195 filtering. 1197 7.7. Information collection 1199 One of the other important aspects of the I2RS is that it is intended 1200 to simplify collecting information about the state of network 1201 elements. This includes both getting a snapshot of a large amount of 1202 data about the current state of the network element, and subscribing 1203 to a feed of the ongoing changes to the set of data or a subset 1204 thereof. This is considered architecturally separate from 1205 notifications due to the differences in information rate and total 1206 volume. 1208 7.8. Multi-Headed Control 1210 As was described earlier, an I2RS Agent interacts with multiple I2RS 1211 Clients who are actively controlling the network element. From an 1212 architecture and design perspective, the assumption is that by means 1213 outside of this system the data to be manipulated within the network 1214 element is appropriately partitioned so that any given piece of 1215 information is only being manipulated by a single I2RS Client. 1217 Nonetheless, unexpected interactions happen and two (or more) I2RS 1218 clients may attempt to manipulate the same piece of data. This is 1219 considered an error case. This architecture does not attempt to 1220 determine what the right state of data should be when such a 1221 collision happens. Rather, the architecture mandates that there be 1222 decidable means by which I2RS Agents handle the collisions. The 1223 mechanism for this is to have a simple priority associated with each 1224 I2RS clients, and the highest priority change remains in effect. In 1225 the case of priority ties, the first client whose attribution is 1226 associated with the data will keep control. 1228 In order for this approach to multi-headed control to be useful for 1229 I2RS Clients, it is important that it be possible for an I2RS Client 1230 to register for changes to any changes made by I2RS to data that it 1231 may care about. This is included in the I2RS event mechanisms. This 1232 also needs to apply to changes made by CLI/NETCONF/SNMP within the 1233 write-scope of the I2RS Agent, as the same priority mechanism (even 1234 if it is "CLI always wins") applies there. The I2RS client may then 1235 respond to the situation as it sees fit. 1237 7.9. Transactions 1239 In the interest of simplicity, the I2RS architecture does not include 1240 multi-message atomicity and rollback mechanisms. Rather, it includes 1241 a small range of error handling for a set of operations included in a 1242 single message. An I2RS Client may indicate one of the following 1243 three error handling for a given message with multiple operations 1244 which it sends to an I2RS Agent: 1246 Perform all or none: This traditional SNMP semantic indicates that 1247 other I2RS agent will keep enough state when handling a single 1248 message to roll back the operations within that message. Either 1249 all the operations will succeed, or none of them will be applied 1250 and an error message will report the single failure which caused 1251 them not to be applied. This is useful when there are, for 1252 example, mutual dependencies across operations in the message. 1254 Perform until error: In this case, the operations in the message 1255 are applied in the specified order. When an error occurs, no 1256 further operations are applied, and an error is returned 1257 indicating the failure. This is useful if there are dependencies 1258 among the operations and they can be topologically sorted. 1260 Perform all storing errors: In this case, the I2RS Agent will 1261 attempt to perform all the operations in the message, and will 1262 return error indications for each one that fails. This is useful 1263 when there is no dependency across the operation, or where the 1264 client would prefer to sort out the effect of errors on its own. 1266 In the interest of robustness and clarity of protocol state, the 1267 protocol will include an explicit reply to modification or write 1268 operations even when they fully succeed. 1270 8. Manageability Considerations 1272 Manageability plays a key aspect in I2RS. Some initial examples 1273 include: 1275 Resource Limitations: Using I2RS, applications can consume 1276 resources, whether those be operations in a time-frame, entries in 1277 the RIB, stored operations to be triggered, etc. The ability to 1278 set resource limits based upon authorization is important. 1280 Configuration Interactions: The interaction of state installed via 1281 the I2RS and via a router's configuration needs to be clearly 1282 defined. As described in this architecture, a simple priority 1283 that is configured is used to provide sufficient policy 1284 flexibility. 1286 9. IANA Considerations 1288 This document includes no request to IANA. 1290 10. Acknowledgements 1292 Significant portions of this draft came from draft-ward-i2rs- 1293 framework-00 and draft-atlas-i2rs-policy-framework-00. 1295 The authors would like to thank Nitin Bahadur, Shane Amante, Ed 1296 Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe 1297 Clarke, Juergen Schoenwalder, Jamal Hadi Salim, Scott Brim, and 1298 Thomas Narten for their suggestions and review. 1300 11. Informative References 1302 [I-D.ietf-i2rs-problem-statement] 1303 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 1304 Routing System Problem Statement", draft-ietf-i2rs- 1305 problem-statement-00 (work in progress), August 2013. 1307 [I-D.ietf-idr-ls-distribution] 1308 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 1309 Ray, "North-Bound Distribution of Link-State and TE 1310 Information using BGP", draft-ietf-idr-ls-distribution-04 1311 (work in progress), November 2013. 1313 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1314 Protocol (NETCONF) Access Control Model", RFC 6536, March 1315 2012. 1317 Authors' Addresses 1319 Alia Atlas 1320 Juniper Networks 1321 10 Technology Park Drive 1322 Westford, MA 01886 1323 USA 1325 Email: akatlas@juniper.net 1326 Joel Halpern 1327 Ericsson 1329 Email: Joel.Halpern@ericsson.com 1331 Susan Hares 1332 Hickory Hill Consulting 1334 Email: shares@ndzh.com 1336 Dave Ward 1337 Cisco Systems 1338 Tasman Drive 1339 San Jose, CA 95134 1340 USA 1342 Email: wardd@cisco.com 1344 Thomas D. Nadeau 1345 Brocade 1347 Email: tnadeau@lucidvision.com