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