idnits 2.17.1 draft-ietf-i2rs-architecture-13.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 920: '... model (often in MUST and WHEN clauses...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 20, 2016) is 2987 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-10 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-09 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-rfc6020bis-11 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 7277 (Obsoleted by RFC 8344) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 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 23, 2016 Ericsson 6 S. Hares 7 Huawei 8 D. Ward 9 Cisco Systems 10 T. Nadeau 11 Brocade 12 February 20, 2016 14 An Architecture for the Interface to the Routing System 15 draft-ietf-i2rs-architecture-13 17 Abstract 19 This document describes the IETF architecture for a standard, 20 programmatic interface for state transfer in and out of the Internet 21 routing system. It describes the basic architecture, the components, 22 and their interfaces with particular focus on those to be 23 standardized as part of the Interface to Routing System (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 23, 2016. 42 Copyright Notice 44 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . 11 64 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 11 65 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 66 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 12 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 4.1. Identity and Authentication . . . . . . . . . . . . . . . 15 69 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 15 70 4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 16 71 5. Network Applications and I2RS Client . . . . . . . . . . . . 16 72 5.1. Example Network Application: Topology Manager . . . . . . 17 73 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 17 74 6.1. Relationship to its Routing Element . . . . . . . . . . . 17 75 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 18 76 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 18 77 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 19 78 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 19 79 6.3. Interactions with Local Configuration . . . . . . . . . . 20 80 6.4. Routing Components and Associated I2RS Services . . . . . 21 81 6.4.1. Routing and Label Information Bases . . . . . . . . . 22 82 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 22 83 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 23 84 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 23 85 6.4.5. Information Modeling, Device Variation, and 86 Information Relationships . . . . . . . . . . . . . . 23 87 6.4.5.1. Managing Variation: Object Classes/Types and 88 Inheritance . . . . . . . . . . . . . . . . . . . 24 89 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 24 90 6.4.5.3. Managing Variation: Templating . . . . . . . . . 25 91 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 25 92 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 25 93 6.4.5.4.2. Correlation Identification . . . . . . . . . 26 94 6.4.5.4.3. Object References . . . . . . . . . . . . . . 26 95 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 26 96 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 26 97 7.1. One Control and Data Exchange Protocol . . . . . . . . . 26 98 7.2. Communication Channels . . . . . . . . . . . . . . . . . 27 99 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 27 100 7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 28 101 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 28 102 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 29 103 7.7. Information collection . . . . . . . . . . . . . . . . . 29 104 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 30 105 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 30 106 8. Operational and Manageability Considerations . . . . . . . . 31 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 109 11. Informative References . . . . . . . . . . . . . . . . . . . 32 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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, IS-IS, and BGP to exchange 118 reachability information, topology information, protocol state, and 119 other information about the state of the network with other 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. Network-oriented applications also require easy access to an 132 interface which will allow them to program and control state related 133 to forwarding. 135 This document sets out an architecture for a common, standards-based 136 interface to this information. This Interface to the Routing System 137 (I2RS) facilitates control and observation of the routing-related 138 state (for example, a Routing Element RIB manager's state), as well 139 as enabling network-oriented applications to be built on top of 140 today's routed networks. The I2RS is a programmatic asynchronous 141 interface for transferring state into and out of the internet routing 142 system. This I2RS architecture recognizes that the routing system 143 and a router's Operating System (OS) provide useful mechanisms that 144 applications could harness to accomplish application-level goals. 146 These network-oriented applications can leverage the I2RS 147 programmatic interface to create new ways of combining retrieval of 148 internet routing data, analyzing this data, setting state within 149 routers. 151 Fundamental to the I2RS are clear data models that define the 152 semantics of the information that can be written and read. The I2RS 153 provides a way for applications to customize network behavior while 154 leveraging the existing routing system as desired. The I2RS provides 155 a framework for applications (including controller applications) to 156 register and to request the appropriate information for each 157 particular application. 159 Although the I2RS architecture is general enough to support 160 information and data models for a variety of data, and aspects of the 161 I2RS solution may be useful in domains other than routing, I2RS and 162 this document are specifically focused on an interface for routing 163 data. 165 1.1. Drivers for the I2RS Architecture 167 There are four key drivers that shape the I2RS architecture. First 168 is the need for an interface that is programmatic, asynchronous, and 169 offers fast, interactive access for atomic operations. Second is the 170 access to structured information and state that is frequently not 171 directly configurable or modeled in existing implementations or 172 configuration protocols. Third is the ability to subscribe to 173 structured, filterable event notifications from the router. Fourth, 174 the operation of I2RS is to be data-model driven to facilitate 175 extensibility and provide standard data-models to be used by network 176 applications. 178 I2RS is described as an asynchronous programmatic interface, the key 179 properties of which are described in Section 5 of 180 [I-D.ietf-i2rs-problem-statement]. 182 The I2RS architecture facilitates obtaining information from the 183 router. The I2RS architecture provides the ability to not only read 184 specific information, but also to subscribe to targeted information 185 streams, filtered events, and thresholded events. 187 Such an interface also facilitates the injection of ephemeral state 188 into the routing system. Ephemeral state on a router is the state 189 which does not survive a the reboot of a routing device or the reboot 190 of the software handling the I2RS software on a routing device. A 191 non-routing protocol or application could inject state into a routing 192 element via the state-insertion functionality of the I2RS and that 193 state could then be distributed in a routing or signaling protocol 194 and/or be used locally (e.g. to program the co-located forwarding 195 plane). I2RS will only permit modification of state that would be 196 safe, conceptually, to modify via local configuration; no direct 197 manipulation of protocol-internal dynamically determined data is 198 envisioned. 200 1.2. Architectural Overview 202 Figure 1 shows the basic architecture for I2RS between applications 203 using I2RS, their associated I2RS Clients, and I2RS Agents. 204 Applications access I2RS services through I2RS clients. A single 205 client can provide access to one or more applications. This figure 206 also shows the types of data models associated with the routing 207 system (dynamic configuration, static configuration, local 208 configuration, and routing and signaling configuration) which the 209 I2RS Agent data models may access or augment. 211 Figure 1 is similar to the figure 1 found in the 212 [I-D.ietf-i2rs-problem-statement], but this figure shows additional 213 detail on how the applications utilize I2RS clients to interact with 214 I2RS Agents. Figure 1 also shows a logical view of the data models 215 associated with the routing system rather than a functional view 216 (RIB, FIB, topology, policy, routing/signaling protocols, etc.) 218 In figure 1, Clients A and B each provide access to a single 219 application (application A and B respectively), while Client P 220 provides access to multiple applications. 222 Applications can access I2RS services through local or remote 223 clients. A local client operates on the same physical box as routing 224 system. In contrast, a remote client operates across the network. 225 In the figure, Applications A and B access I2RS services through 226 local clients, while Applications C, D and E access I2RS services 227 through a remote client. The details of how applications communicate 228 with a remote client is out of scope for I2RS. 230 An I2RS Client can access one or more I2RS agents. In the figure 1, 231 Clients B and P access I2RS Agents 1 and 2. Likewise, an I2RS Agent 232 can provide service to one or more clients. In this figure, I2RS 233 Agent 1 provides services to Clients A, B and P while Agent 2 234 provides services to only Clients B and P. 236 I2RS agents and clients communicate with one another using an 237 asynchronous protocol. Therefore, a single client can post multiple 238 simultaneous requests, either to a single agent or to multiple 239 agents. Furthermore, an agent can process multiple requests, either 240 from a single client or from multiple clients, simultaneously. 242 The I2RS agent provides read and write access to selected data on the 243 routing element that are organized into I2RS Services. Section 4 244 describes how access is mediated by authentication and access control 245 mechanisms. Figure 1 shows I2RS agents being able to write ephemeral 246 static state (e.g. RIB entries), and to read from dynamic static 247 (e.g. MPLS LSP-ID or number of active BGP peers). In addition, the 249 In addition to read and write access, the I2RS agent allows clients 250 to subscribe to different types of notifications about events 251 affecting different object instances. One example of a notification 252 of such an event (which is unrelated to an object creation, 253 modification or deletion) is when a next-hop in the RIB is resolved 254 in a way that allows it to be used by a RIB manager for installation 255 in the forwarding plane as part of a particular route. Please see 256 Section 7.6 and Section 7.7 for details. 258 The scope of I2RS is to define the interactions between the I2RS 259 agent and the I2RS client and the associated proper behavior of the 260 I2RS agent and I2RS client. 262 ****************** ***************** ***************** 263 * Application C * * Application D * * Application E * 264 ****************** ***************** ***************** 265 ^ ^ ^ 266 | | | 267 |--------------| | |--------------| 268 | | | 269 v v v 270 *************** 271 * Client P * 272 *************** 273 ^ ^ 274 | |-------------------------| 275 *********************** | *********************** | 276 * Application A * | * Application B * | 277 * * | * * | 278 * +----------------+ * | * +----------------+ * | 279 * | Client A | * | * | Client B | * | 280 * +----------------+ * | * +----------------+ * | 281 ******* ^ ************* | ***** ^ ****** ^ ****** | 282 | | | | | 283 | |-------------| | | |-----| 284 | | -----------------------| | | 285 | | | | | 286 ************ v * v * v ********* ***************** v * v ******** 287 * +---------------------+ * * +---------------------+ * 288 * | Agent 1 | * * | Agent 2 | * 289 * +---------------------+ * * +---------------------+ * 290 * ^ ^ ^ ^ * * ^ ^ ^ ^ * 291 * | | | | * * | | | | * 292 * v | | v * * v | | v * 293 * +---------+ | | +--------+ * * +---------+ | | +--------+ * 294 * | Routing | | | | Local | * * | Routing | | | | Local | * 295 * | and | | | | Config | * * | and | | | | Config | * 296 * |Signaling| | | +--------+ * * |Signaling| | | +--------+ * 297 * +---------+ | | ^ * * +---------+ | | ^ * 298 * ^ | | | * * ^ | | | * 299 * | |----| | | * * | |----| | | * 300 * v | v v * * v | v v * 301 * +----------+ +------------+ * * +----------+ +------------+ * 302 * | Dynamic | | Static | * * | Dynamic | | Static | * 303 * | System | | System | * * | System | | System | * 304 * | State | | State | * * | State | | State | * 305 * +----------+ +------------+ * * +----------+ +------------+ * 306 * * * * 307 * Routing Element 1 * * Routing Element 2 * 308 ******************************** ******************************** 310 Figure 1: Architecture of I2RS clients and agents 312 Routing Element: A Routing Element implements some subset of the 313 routing system. It does not need to have a forwarding plane 314 associated with it. Examples of Routing Elements can include: 316 * A router with a forwarding plane and RIB Manager that runs IS- 317 IS, OSPF, BGP, PIM, etc., 319 * A BGP speaker acting as a Route Reflector, 321 * An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a 322 forwarding plane and associated RIB Manager, 324 * A server that runs IS-IS, OSPF, BGP and uses ForCES to control 325 a remote forwarding plane, 327 A Routing Element may be locally managed, whether via CLI, SNMP, 328 or NETCONF. 330 Routing and Signaling: This block represents that portion of the 331 Routing Element that implements part of the internet routing 332 system. It includes not merely standardized protocols (i.e. IS- 333 IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager 334 layer. 336 Local Configuration: is the black box behavior for interactions 337 between the ephemeral state that I2RS installs into the routing 338 element; and this Local Configuration is defined by this document 339 and the behaviors specified by the I2RS protocol. 341 Dynamic System State: An I2RS agent needs access to state on a 342 routing element beyond what is contained in the routing subsystem. 343 Such state may include various counters, statistics, flow data, 344 and local events. This is the subset of operational state that is 345 needed by network applications based on I2RS that is not contained 346 in the routing and signaling information. How this information is 347 provided to the I2RS agent is out of scope, but the standardized 348 information and data models for what is exposed are part of I2RS. 350 Static System State: An I2RS agent needs access to static state on 351 a routing element beyond what is contained in the routing 352 subsystem. An example of such state is specifying queueing 353 behavior for an interface or traffic. How the I2RS agent modifies 354 or obtains this information is out of scope, but the standardized 355 information and data models for what is exposed are part of I2RS. 357 I2RS Agent: See the definition in Section 2. 359 Application: A network application that needs to observe the 360 network or manipulate the network to achieve its service 361 requirements. 363 I2RS Client: See the definition in Section 2. 365 As can be seen in Figure 1, an I2RS client can communicate with 366 multiple I2RS agents. An I2RS client may connect to one or more I2RS 367 agents based upon its needs. Similarly, an I2RS agent may 368 communicate with multiple I2RS clients - whether to respond to their 369 requests, to send notifications, etc. Timely notifications are 370 critical so that several simultaneously operating applications have 371 up-to-date information on the state of the network. 373 As can also be seen in Figure 1, an I2RS Agent may communicate with 374 multiple clients. Each client may send the agent a variety of write 375 operations. In order to keep the protocol simple, two clients should 376 not attempt to write (modify) the same piece of information on an 377 I2RS Agent. This is considered an error. However, such collisions 378 may happen and section 7.8 (multi-headed control) describes how the 379 I2RS agent resolves collision by first utilizing priority to resolve 380 collisions, and second by servicing the requests in a first in, first 381 served basis. The i2rs architecture includes this definition of 382 behavior for this case simply for predictability not because this is 383 an intended result. This predictability will simplify the error 384 handling and suppress oscillations. If additional error cases beyond 385 this simple treatment are required, these error cases should be 386 resolved by the network applications and management systems. 388 In contrast, although multiple I2RS clients may need to supply data 389 into the same list (e.g. a prefix or filter list), this is not 390 considered an error and must be correctly handled. The nuances so 391 that writers do not normally collide should be handled in the 392 information models. 394 The architectural goal for the I2RS is that such errors should 395 produce predictable behaviors, and be reportable to interested 396 clients. The details of the associated policy is discussed in 397 Section 7.8. The same policy mechanism (simple priority per I2RS 398 client) applies to interactions between the I2RS agent and the 399 CLI/SNMP/NETCONF as described in Section 6.3. 401 In addition it must be noted that there may be indirect interactions 402 between write operations. A basic example of this is when two 403 different but overlapping prefixes are written with different 404 forwarding behavior. Detection and avoidance of such interactions is 405 outside the scope of the I2RS work and is left to agent design and 406 implementation. 408 2. Terminology 410 The following terminology is used in this document. 412 agent or I2RS Agent: An I2RS agent provides the supported I2RS 413 services from the local system's routing sub-systems by 414 interacting with the routing element to provide specified 415 behavior. The I2RS agent understands the I2RS protocol and can be 416 contacted by I2RS clients. 418 client or I2RS Client: A client implements the I2RS protocol, uses 419 it to communicate with I2RS Agents, and uses the I2RS services to 420 accomplish a task. It interacts with other elements of the 421 policy, provisioning, and configuration system by means outside of 422 the scope of the I2RS effort. It interacts with the I2RS agents 423 to collect information from the routing and forwarding system. 424 Based on the information and the policy oriented interactions, the 425 I2RS client may also interact with I2RS agents to modify the state 426 of their associated routing systems to achieve operational goals. 427 An I2RS client can be seen as the part of an application that uses 428 and supports I2RS and could be a software library. 430 service or I2RS Service: For the purposes of I2RS, a service refers 431 to a set of related state access functions together with the 432 policies that control their usage. The expectation is that a 433 service will be represented by a data-model. For instance, 'RIB 434 service' could be an example of a service that gives access to 435 state held in a device's RIB. 437 read scope: The read scope of an I2RS client within an I2RS agent 438 is the set of information which the I2RS client is authorized to 439 read within the I2RS agent. The read scope specifies the access 440 restrictions to both see the existence of data and read the value 441 of that data. 443 notification scope: The set of events and associated information 444 that the I2RS Client can request be pushed by the I2RS Agent. 445 I2RS Clients have the ability to register for specific events and 446 information streams, but must be constrained by the access 447 restrictions associated with their notification scope. 449 write scope: The set of field values which the I2RS client is 450 authorized to write (i.e. add, modify or delete). This access can 451 restrict what data can be modified or created, and what specific 452 value sets and ranges can be installed. 454 scope: When unspecified as either read scope, write scope, or 455 notification scope, the term scope applies to the read scope, 456 write scope, and notification scope. 458 resources: A resource is an I2RS-specific use of memory, storage, 459 or execution that a client may consume due to its I2RS operations. 460 The amount of each such resource that a client may consume in the 461 context of a particular agent may be constrained based upon the 462 client's security role. An example of such a resource could 463 include the number of notifications registered for. These are not 464 protocol-specific resources or network-specific resources. 466 role or security role: A security role specifies the scope, 467 resources, priorities, etc. that a client or agent has. If a 468 identity has multiple roles in the security system, the identity 469 is permitted to perform any operations any of those roles permit. 470 Multiple identities may use the same security role. 472 identity: A client is associated with exactly one specific 473 identity. State can be attributed to a particular identity. It 474 is possible for multiple communication channels to use the same 475 identity; in that case, the assumption is that the associated 476 client is coordinating such communication. 478 Identity and scope: A single identity can be associated with 479 multiple roles. Each role has its own scope and an identity 480 associated with multiple roles can use the combined scope of all 481 its roles. More formally, each identity has: 483 a read-scope that is the logical OR of the read-scopes 484 associated with its roles, 486 a write-scope that is the logical OR of the write-scopes 487 associated with its roles, and 489 a notification-scope that is the logical OR of the 490 notification-scopes associated with its roles. 492 secondary identity: An I2RS Client may supply a secondary opaque 493 identity that is not interpreted by the I2RS Agent. An example 494 use is when the I2RS Client is a go-between for multiple 495 applications and it is necessary to track which application has 496 requested a particular operation. 498 Groups: NETCONF Network Access [RFC6536] uses the term group in 499 terms of an Administrative group which supports the well- 500 established distinction between a root account and other types of 501 less-privileged conceptual user accounts. Group still refers to a 502 single identity (e.g. root) which is shared by a group of users. 504 3. Key Architectural Properties 506 Several key architectural properties for the I2RS protocol are 507 elucidated below (simplicity, extensibility, and model-driven 508 programmatic interfaces). However, some architecture properties such 509 as performance and scaling are not described below because they are 510 discussed in [I-D.ietf-i2rs-problem-statement], may may vary based on 511 the particular use-cases. 513 3.1. Simplicity 515 There have been many efforts over the years to improve the access to 516 the information available to the routing and forwarding system. 517 Making such information visible and usable to network management and 518 applications has many well-understood benefits. There are two 519 related challenges in doing so. First, the quantity and diversity of 520 information potentially available is very large. Second, the 521 variation both in the structure of the data and in the kinds of 522 operations required tends to introduce protocol complexity. 524 While the types of operations contemplated here are complex in their 525 nature, it is critical that I2RS be easily deployable and robust. 526 Adding complexity beyond what is needed to satisfy well known and 527 understood requirements would hinder the ease of implementation, the 528 robustness of the protocol, and the deployability of the protocol. 529 Overly complex data models tend to ossify information sets by 530 attempting to describe and close off every possible option, 531 complicating extensibility. 533 Thus, one of the key aims for I2RS is the keep the protocol and 534 modeling architecture simple. So for each architectural component or 535 aspect, we ask ourselves "do we need this complexity, or is the 536 behavior merely nice to have?" 538 3.2. Extensibility 540 Extensibility of the protocol and data model is very important. In 541 particular, given the necessary scope limitations of the initial 542 work, it is critical that the initial design include strong support 543 for extensibility. 545 The scope of the I2RS work is being restricted in the interests of 546 achieving a deliverable and deployable result. The I2RS Working 547 Group is modeling only a subset of the data of interest. It is 548 clearly desirable for the data models defined in the I2RS to be 549 useful in more general settings. It should be easy to integrate data 550 models from the I2RS with other data. Other work should be able to 551 easily extend it to represent additional aspects of the network 552 elements or network systems. This reinforces the criticality of 553 designing the data models to be highly extensible, preferably in a 554 regular and simple fashion. 556 The I2RS Working Group is defining operations for the I2RS protocol. 557 It would be optimistic to assume that more and different ones may not 558 be needed when the scope of I2RS increases. Thus, it is important to 559 consider extensibility not only of the underlying services' data 560 models, but also of the primitives and protocol operations. 562 3.3. Model-Driven Programmatic Interfaces 564 A critical component of I2RS is the standard information and data 565 models with their associated semantics. While many components of the 566 routing system are standardized, associated data models for them are 567 not yet available. Instead, each router uses different information, 568 different mechanisms, and different CLI which makes a standard 569 interface for use by applications extremely cumbersome to develop and 570 maintain. Well-known data modeling languages exist and may be used 571 for defining the data models for I2RS. 573 There are several key benefits for I2RS in using model-driven 574 architecture and protocol(s). First, it allows for transferring 575 data-models whose content is not explicitly implemented or 576 understood. Second, tools can automate checking and manipulating 577 data; this is particularly valuable for both extensibility and for 578 the ability to easily manipulate and check proprietary data-models. 580 The different services provided by I2RS can correspond to separate 581 data-models. An I2RS agent may indicate which data-models are 582 supported. 584 The purpose of the data model is to provide an definition of the 585 information regarding the routing system that can be used in 586 operational networks. If routing information is being modeled for 587 the first time, a logical information model may be standardized prior 588 to creating the data model. 590 4. Security Considerations 592 This I2RS architecture describes interfaces that clearly require 593 serious consideration of security. As an architecture, I2RS has been 594 designed to re-utilize existing protocols that carry network 595 management information. Two of the existing protocols which the 596 which may be re-used are NETCONF [RFC6241] and RESTCONF 597 [I-D.ietf-netconf-restconf]. The I2RS protocol design process will 598 be to specify additional requirements including security for these 599 existing protocol in order to support the I2RS architecture. After 600 an existing protocol, (e.g. NETCONF or RESTCONF) has been altered to 601 fit the I2RS requirements, then it will be reviewed to determine if 602 it meets the I2RS security requirements. 604 Due to the re-use strategy of the I2RS architecture, this security 605 section describes the assumed security environment for I2RS with 606 additional details on: a) identity and authentication, b) 607 authorization, and c) client redundancy. Each protocol proposed for 608 inclusion as an I2RS protocol will need to be evaluated for the 609 security constraints of the protocol. The detailed requirements for 610 the I2RS protocol and the I2RS security environment will be defined 611 within these global security environments. 613 First, here is a brief description of the assumed security 614 environment for I2RS. The I2RS Agent associated with a Routing 615 Element is a trusted part of that Routing Element. For example, it 616 may be part of a vendor-distributed signed software image for the 617 entire Routing Element or it may be trusted signed application that 618 an operator has installed. The I2RS Agent is assumed to have a 619 separate authentication and authorization channel by which it can 620 validate both the identity and permissions associated with an I2RS 621 Client. To support numerous and speedy interactions between the I2RS 622 Agent and I2RS Client, it is assumed that the I2RS Agent can also 623 cache that particular I2RS Clients are trusted and their associated 624 authorized scope. This implies that the permission information may 625 be old either in a pull model until the I2RS Agent re-requests it, or 626 in a push model until the authentication and authorization channel 627 can notify the I2RS Agent of changes. 629 Mutual authentication between the I2RS Client and I2RS Agent is 630 required. An I2RS Client must be able to trust that the I2RS Agent 631 is attached to the relevant Routing Element so that write/modify 632 operations are correctly applied and so that information received 633 from the I2RS Agent can be trusted by the I2RS Client. 635 An I2RS Client is not automatically trustworthy. Each I2RS Client is 636 associated with identity with a set of scope limitations. 637 Applications using the I2RSS should be aware of the scope limitations 638 of that I2RS Client. If the I2RS Client is acting as a broker for 639 multiple applications, then managing the security, authentication and 640 authorization for that communication is out of scope; nothing 641 prevents the broker from using I2RS protocol and a separate 642 authentication and authorization channel from being used. Regardless 643 of mechanism, an I2RS Client that is acting as a broker is 644 responsible for determining that applications using it are trusted 645 and permitted to make the particular requests. 647 Different levels of integrity, confidentiality, and replay protection 648 are relevant for different aspects of I2RS. The primary 649 communication channel that is used for client authentication and then 650 used by the client to write data requires integrity, confidentiality 651 and replay protection. Appropriate selection of a default required 652 transport protocol is the preferred way of meeting these 653 requirements. 655 Other communications via I2RS may not require integrity, 656 confidentiality, and replay protection. For instance, if an I2RS 657 Client subscribes to an information stream of prefix announcements 658 from OSPF, those may require integrity but probably not 659 confidentiality or replay protection. Similarly, an information 660 stream of interface statistics may not even require guaranteed 661 delivery. In Section 7.2, additional login regarding multiple 662 communication channels and their use is provided. From the security 663 perspective, it is critical to realize that an I2RS Agent may open a 664 new communication channel based upon information provided by an I2RS 665 Client (as described in Section 7.2). For example, an I2RS client 666 may request notifications of certain events and the agent will open a 667 communication channel to report such events. Therefore, to avoid an 668 indirect attack, such a request must be done in the context of an 669 authenticated and authorized client whose communications cannot have 670 been altered. 672 4.1. Identity and Authentication 674 As discussed above, all control exchanges between the I2RS client and 675 agent should be authenticated and integrity protected (such that the 676 contents cannot be changed without detection). Further, manipulation 677 of the system must be accurately attributable. In an ideal 678 architecture, even information collection and notification should be 679 protected; this may be subject to engineering tradeoffs during the 680 design. 682 I2RS clients may be operating on behalf of other applications. While 683 those applications' identities are not needed for authentication or 684 authorization, each application should have a unique opaque 685 identifier that can be provided by the I2RS client to the I2RS agent 686 for purposes of tracking attribution of operations to support 687 functionality such as troubleshooting and logging of network changes. 689 4.2. Authorization 691 All operations using I2RS, both observation and manipulation, should 692 be subject to appropriate authorization controls. Such authorization 693 is based on the identity and assigned role of the I2RS client 694 performing the operations and the I2RS agent in the network element. 695 Multiple Identities may use the same role(s). As noted in the 696 definition of the identity and role above, if multiple roles are 697 associated with an identity then the identity is authorized to 698 perform any operation authorized by any of its roles. 700 I2RS Agents, in performing information collection and manipulation, 701 will be acting on behalf of the I2RS clients. As such, each 702 operation authorization will be based on the lower of the two 703 permissions of the agent itself and of the authenticated client. The 704 mechanism by which this authorization is applied within the device is 705 outside of the scope of I2RS. 707 The appropriate or necessary level of granularity for scope can 708 depend upon the particular I2RS Service and the implementation's 709 granularity. An approach to a similar access control problem is 710 defined in the NetConf Access Control Model (NACM) [RFC6536]; it 711 allows arbitrary access to be specified for a data node instance 712 identifier while defining meaningful manipulable defaults. The 713 identity within NACM [RFC6536] can be specify as either a user name 714 or a group user name (e.g. Root), and this name is linked a scope 715 policy that is contained in a set of access control rules. 716 Similarly, it is expected the I2RS identity links to one role which 717 has a scope policy specified by a set of access control rules. This 718 scope policy can be provided via Local Configuration, exposed as an 719 I2RS Service for manipulation by authorized clients, or via some 720 other method (e.g. AAA service) 722 When an I2RS client is authenticated, its identity is provided to the 723 I2RS Agent, and this identity links to a role which links to the 724 scope policy. Multiple identities may belong to the same role; for 725 example, such a role might be an Internal-Routes-Monitor that allows 726 reading of the portion of the I2RS RIB associated with IP prefixes 727 used for internal device addresses in the AS." 729 4.3. Client Redundancy 731 I2RS must support client redundancy. At the simplest, this can be 732 handled by having a primary and a backup network application that 733 both use the same client identity and can successfully authenticate 734 as such. Since I2RS does not require a continuous transport 735 connection and supports multiple transport sessions, this can provide 736 some basic redundancy. However, it does not address the need for 737 troubleshooting and logging of network changes to be informed about 738 which network application is actually active. At a minimum, basic 739 transport information about each connection and time can be logged 740 with the identity. 742 5. Network Applications and I2RS Client 744 I2RS is expected to be used by network-oriented applications in 745 different architectures. While the interface between a network- 746 oriented application and the I2RS client is outside the scope of 747 I2RS, considering the different architectures is important to 748 sufficiently specify I2RS. 750 In the simplest architecture of direct access, a network-oriented 751 application has an I2RS client as a library or driver for 752 communication with routing elements. 754 In the broker architecture, multiple network-oriented applications 755 communicate in an unspecified fashion to a broker application that 756 contains an I2RS Client. That broker application requires additional 757 functionality for authentication and authorization of the network- 758 oriented applications; such functionality is out of scope for I2RS 759 but similar considerations to those described in Section 4.2 do 760 apply. As discussed in Section 4.1, the broker I2RS Client should 761 determine distinct opaque identifiers for each network-oriented 762 application that is using it. The broker I2RS Client can pass along 763 the appropriate value as a secondary identifier which can be used for 764 tracking attribution of operations. 766 In a third architecture, a routing element or network-oriented 767 application that uses an I2RS Client to access services on a 768 different routing element may also contain an I2RS agent to provide 769 services to other network-oriented applications. However, where the 770 needed information and data models for those services differs from 771 that of a conventional routing element, those models are, at least 772 initially, out of scope for I2RS. Below is an example of such a 773 network application 775 5.1. Example Network Application: Topology Manager 777 A Topology Manager includes an I2RS client that uses the I2RS data 778 models and protocol to collect information about the state of the 779 network by communicating directly with one or more I2RS agents. From 780 these I2RS agents, the Topology Manager collects routing 781 configuration and operational data, such as interface and label- 782 switched path (LSP) information. In addition, the Topology Manager 783 may collect link-state data in several ways - either via I2RS models, 784 by peering with BGP-LS[I-D.ietf-idr-ls-distribution] or listening 785 into the IGP. 787 The set of functionality and collected information that is the 788 Topology Manager may be embedded as a component of a larger 789 application, such as a path computation application. As a stand- 790 alone application, the Topology Manager could be useful to other 791 network applications by providing a coherent picture of the network 792 state accessible via another interface. That interface might use the 793 same I2RS protocol and could provide a topology service using 794 extensions to the I2RS data models. 796 6. I2RS Agent Role and Functionality 798 The I2RS Agent is part of a routing element. As such, it has 799 relationships with that routing element as a whole, and with various 800 components of that routing element. 802 6.1. Relationship to its Routing Element 804 A Routing Element may be implemented with a wide variety of different 805 architectures: an integrated router, a split architecture, 806 distributed architecture, etc. The architecture does not need to 807 affect the general I2RS agent behavior. 809 For scalability and generality, the I2RS agent may be responsible for 810 collecting and delivering large amounts of data from various parts of 811 the routing element. Those parts may or may not actually be part of 812 a single physical device. Thus, for scalability and robustness, it 813 is important that the architecture allow for a distributed set of 814 reporting components providing collected data from the I2RS agent 815 back to the relevant I2RS clients. There may be multiple I2RS Agents 816 within the same router. In such a case, they must have non- 817 overlapping sets of information which they manipulate. 819 To facilitate operations, deployment and troubleshooting, it is 820 important that traceability of the requests received by I2RS Agent's 821 and actions taken be supported via a common data model. 823 6.2. I2RS State Storage 825 State modification requests are sent to the I2RS agent in a routing 826 element by I2RS clients. The I2RS agent is responsible for applying 827 these changes to the system, subject to the authorization discussed 828 above. The I2RS agent will retain knowledge of the changes it has 829 applied, and the client on whose behalf it applied the changes. The 830 I2RS agent will also store active subscriptions. These sets of data 831 form the I2RS data store. This data is retained by the agent until 832 the state is removed by the client, overridden by some other 833 operation such as CLI, or the device reboots. Meaningful logging of 834 the application and removal of changes is recommended. I2RS applied 835 changes to the routing element state will not be retained across 836 routing element reboot. The I2RS data store is not preserved across 837 routing element reboots; thus the I2RS agent will not attempt to 838 reapply such changes after a reboot. 840 6.2.1. I2RS Agent Failure 842 It is expected that an I2RS Agent may fail independently of the 843 associated routing element. This could happen because I2RS is 844 disabled on the routing element or because the I2RS Agent, a separate 845 process or even running on a separate processor, experiences an 846 unexpected failure. Just as routing state learned from a failed 847 source is removed, the ephemeral I2RS state will usually be removed 848 shortly after the failure is detected or as part of a graceful 849 shutdown process. To handle I2RS Agent failure, the I2RS Agent must 850 use two different notifications. 852 NOTIFICATION_I2RS_AGENT_STARTING: This notification signals to the 853 I2RS Client(s) that the associated I2RS Agent has started. It 854 includes an agent-boot-count that indicates how many times the 855 I2RS Agent has restarted since the associated routing element 856 restarted. The agent-boot-count allows an I2RS Client to 857 determine if the I2RS Agent has restarted. (Note: This 858 notification will be only transmitted to I2RS clients which are 859 know in some way after a reboot.) 861 NOTIFICATION_I2RS_AGENT_TERMINATING: This notification reports that 862 the associated I2RS Agent is shutting down gracefully, and that 863 I2RS ephemeral state will be removed. It can optionally include a 864 timestamp indicating when the I2RS Agent will shutdown. Use of 865 this timestamp assumes that time synchronization has been done and 866 the timestamp should not have granularity finer than one second 867 because better accuracy of shutdown time is not guaranteed. 869 There are two different failure types that are possible and each has 870 different behavior. 872 Unexpected failure: In this case, the I2RS Agent has unexpectedly 873 crashed and thus cannot notify its clients of anything. Since 874 I2RS does not require a persistent connection between the I2RS 875 Client and I2RS Agent, it is necessary to have a mechanism for the 876 I2RS Agent to notify I2RS Clients that had subscriptions or 877 written ephemeral state; such I2RS Clients should be cached by the 878 I2RS Agent's system in persistent storage. When the I2RS Agent 879 starts, it should send a NOTIFICATION_I2RS_AGENT_STARTING to each 880 cached I2RS Client. 882 Graceful failure: In this case, the I2RS Agent can do specific 883 limited work as part of the process of being disabled. The I2RS 884 Agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all its 885 cached I2RS Clients. 887 6.2.2. Starting and Ending 889 When an I2RS client applies changes via the I2RS protocol, those 890 changes are applied and left until removed or the routing element 891 reboots. The network application may make decisions about what to 892 request via I2RS based upon a variety of conditions that imply 893 different start times and stop times. That complexity is managed by 894 the network application and is not handled by I2RS. 896 6.2.3. Reversion 898 An I2RS Agent may decide that some state should no longer be applied. 899 An I2RS Client may instruct an Agent to remove state it has applied. 900 In all such cases, the state will revert to what it would have been 901 without the I2RS client-agent interaction; that state is generally 902 whatever was specified via the CLI, NETCONF, SNMP, etc. I2RS Agents 903 will not store multiple alternative states, nor try to determine 904 which one among such a plurality it should fall back to. Thus, the 905 model followed is not like the RIB, where multiple routes are stored 906 at different preferences. (For I2RS state in the presence of two 907 I2RS clients, please see section 1.2 and section 7.8) 908 An I2RS Client may register for notifications, subject to its 909 notification scope, regarding state modification or removal by a 910 particular I2RS Client. 912 6.3. Interactions with Local Configuration 914 Changes may originate from either Local Configuration or from I2RS. 915 The modifications and data stored by I2RS are separate from the local 916 device configuration, but conflicts between the two must be resolved 917 in a deterministic manner that respects operator-applied policy. The 918 deterministic model is the result of general I2RS rules, system 919 rules, knobs adjust by operator-applied policy, and the rules 920 associated with the yang data model (often in MUST and WHEN clauses 921 for dependencies). 923 This operator-applied policy can determine whether Local 924 Configuration overrides a particular I2RS client's request or vice 925 versa. To achieve this end, the I2RS data modules have a general 926 rule that by default the Local Configuration always wins. 927 Optionally, a routing element may permit a priority to be to be 928 configured on the device for the Local Configuration mechanism 929 interaction with the I2RS model. The policy mechanism would compare 930 the I2RS client's priority with that priority assigned to the Local 931 Configuration in order to determine whether Local Configuration or 932 I2RS wins. 934 For the case when the I2RS ephemeral state always wins for a data 935 model, if there is an I2RS ephemeral state value it is installed 936 instead of the local configuration state. The local configuration 937 information is stored so that if/when I2RS client removes I2RS 938 ephemeral state the local configuration state can be restored. 940 When the Local Configuration always wins, some communication between 941 that subsystem and the I2RS Agent is still necessary. As an I2RS 942 Agent connects to the routing sub-system, the I2RS Agent must also 943 communicate with the Local Configuration to exchange model 944 information so the I2RS agent knows the details of each specific 945 device configuration change that the I2RS Agent is permitted to 946 modify. In addition, when the system determines, that a client's 947 I2RS state is preempted, the I2RS agent must notify the affected I2RS 948 clients; how the system determines this is implementation-dependent. 950 It is critical that policy based upon the source is used because the 951 resolution cannot be time-based. Simply allowing the most recent 952 state to prevail could cause race conditions where the final state is 953 not repeatably deterministic. 955 6.4. Routing Components and Associated I2RS Services 957 For simplicity, each logical protocol or set of functionality that 958 can be compactly described in a separable information and data model 959 is considered as a separate I2RS Service. A routing element need not 960 implement all routing components described nor provide the associated 961 I2RS services. I2RS Services should include a capability model so 962 that peers can determine which parts of the service are supported. 963 Each I2RS Service requires an information model that describes at 964 least the following: data that can be read, data that can be written, 965 notifications that can be subscribed to, and the capability model 966 mentioned above. 968 The initial services included in the I2RS architecture are as 969 follows. 971 *************************** ************** ***************** 972 * I2RS Protocol * * * * Dynamic * 973 * * * Interfaces * * Data & * 974 * +--------+ +-------+ * * * * Statistics * 975 * | Client | | Agent | * ************** ***************** 976 * +--------+ +-------+ * 977 * * ************** ************* 978 *************************** * * * * 979 * Policy * * Base QoS * 980 ******************** ******** * Templates * * Templates * 981 * +--------+ * * * * * ************* 982 * BGP | BGP-LS | * * PIM * ************** 983 * +--------+ * * * 984 ******************** ******** **************************** 985 * MPLS +---------+ +-----+ * 986 ********************************** * | RSVP-TE | | LDP | * 987 * IGPs +------+ +------+ * * +---------+ +-----+ * 988 * +--------+ | OSPF | |IS-IS | * * +--------+ * 989 * | Common | +------+ +------+ * * | Common | * 990 * +--------+ * * +--------+ * 991 ********************************** **************************** 993 ************************************************************** 994 * RIB Manager * 995 * +-------------------+ +---------------+ +------------+ * 996 * | Unicast/multicast | | Policy-Based | | RIB Policy | * 997 * | RIBs & LIBs | | Routing | | Controls | * 998 * | route instances | | (ACLs, etc) | +------------+ * 999 * +-------------------+ +---------------+ * 1000 ************************************************************** 1002 Figure 2: Anticipated I2RS Services 1004 There are relationships between different I2RS Services - whether 1005 those be the need for the RIB to refer to specific interfaces, the 1006 desire to refer to common complex types (e.g. links, nodes, IP 1007 addresses), or the ability to refer to implementation-specific 1008 functionality (e.g. pre-defined templates to be applied to interfaces 1009 or for QoS behaviors that traffic is direct into). Section 6.4.5 1010 discusses information modeling constructs and the range of 1011 relationship types that are applicable. 1013 6.4.1. Routing and Label Information Bases 1015 Routing elements may maintain one or more Information Bases. 1016 Examples include Routing Information Bases such as IPv4/IPv6 Unicast 1017 or IPv4/IPv6 Multicast. Another such example includes the MPLS Label 1018 Information Bases, per-platform or per-interface or per-context. 1019 This functionality, exposed via an I2RS Service, must interact 1020 smoothly with the same mechanisms that the routing element already 1021 uses to handle RIB input from multiple sources, so as to safely 1022 change the system state. Conceptually, this can be handled by having 1023 the I2RS Agent communicate with a RIB Manager as a separate routing 1024 source. 1026 The point-to-multipoint state added to the RIB does not need to match 1027 to well-known multicast protocol installed state. The I2RS Agent can 1028 create arbitrary replication state in the RIB, subject to the 1029 advertised capabilities of the routing element. 1031 6.4.2. IGPs, BGP and Multicast Protocols 1033 A separate I2RS Service can expose each routing protocol on the 1034 device. Such I2RS services may include a number of different kinds 1035 of operations: 1037 o reading the various internal RIB(s) of the routing protocol is 1038 often helpful for understanding the state of the network. 1039 Directly writing to these protocol-specific RIBs or databases is 1040 out of scope for I2RS. 1042 o reading the various pieces of policy information the particular 1043 protocol instance is using to drive its operations. 1045 o writing policy information such as interface attributes that are 1046 specific to the routing protocol or BGP policy that may indirectly 1047 manipulate attributes of routes carried in BGP. 1049 o writing routes or prefixes to be advertised via the protocol. 1051 o joining/removing interfaces from the multicast trees 1052 o subscribing to an information stream of route changes 1054 o receiving notifications about peers coming up or going down 1056 For example, the interaction with OSPF might include modifying the 1057 local routing element's link metrics, announcing a locally-attached 1058 prefix, or reading some of the OSPF link-state database. However, 1059 direct modification of the link-state database must not be allowed in 1060 order to preserve network state consistency. 1062 6.4.3. MPLS 1064 I2RS Services will be needed to expose the protocols that create 1065 transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. 1066 BGP, LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, 1067 L2VPNs, etc). This should include all local information about LSPs 1068 originating in, transiting, or terminating in this Routing Element. 1070 6.4.4. Policy and QoS Mechanisms 1072 Many network elements have separate policy and QoS mechanisms, 1073 including knobs which affect local path computation and queue control 1074 capabilities. These capabilities vary widely across implementations, 1075 and I2RS cannot model the full range of information collection or 1076 manipulation of these attributes. A core set does need to be 1077 included in the I2RS information models and supported in the expected 1078 interfaces between the I2RS Agent and the network element, in order 1079 to provide basic capabilities and the hooks for future extensibility. 1081 By taking advantage of extensibility and sub-classing, information 1082 models can specify use of a basic model that can be replaced by a 1083 more detailed model. 1085 6.4.5. Information Modeling, Device Variation, and Information 1086 Relationships 1088 I2RS depends heavily on information models of the relevant aspects of 1089 the Routing Elements to be manipulated. These models drive the data 1090 models and protocol operations for I2RS. It is important that these 1091 information models deal well with a wide variety of actual 1092 implementations of Routing Elements, as seen between different 1093 products and different vendors. There are three ways that I2RS 1094 information models can address these variations: class or type 1095 inheritance, optional features, and templating. 1097 6.4.5.1. Managing Variation: Object Classes/Types and Inheritance 1099 Information modelled by I2RS from a Routing Element can be described 1100 in terms of classes or types or object. Different valid inheritance 1101 definitions can apply. What is appropriate for I2RS to use is not 1102 determined in this architecture; for simplicity, class and subclass 1103 will be used as the example terminology. This I2RS architecture does 1104 require the ability to address variation in Routing Elements by 1105 allowing information models to define parent or base classes and 1106 subclasses. 1108 The base or parent class defines the common aspects that all Routing 1109 Elements are expected to support. Individual subclasses can 1110 represent variations and additional capabilities. When applicable, 1111 there may be several levels of refinement. The I2RS protocol can 1112 then provide mechanisms to allow an I2RS client to determine which 1113 classes a given I2RS Agent has available. Clients which only want 1114 basic capabilities can operate purely in terms of base or parent 1115 classes, while a client needing more details or features can work 1116 with the supported sub-class(es). 1118 As part of I2RS information modeling, clear rules should be specified 1119 for how the parent class and subclass can relate; for example, what 1120 changes can a subclass make to its parent? The description of such 1121 rules should be done so that it can apply across data modeling tools 1122 until the I2RS data modeling language is selected. 1124 6.4.5.2. Managing Variation: Optionality 1126 I2RS Information Models must be clear about what aspects are 1127 optional. For instance, must an instance of a class always contain a 1128 particular data field X? If so, must the client provide a value for 1129 X when creating the object or is there a well-defined default value? 1130 From the Routing Element perspective, in the above example, each 1131 Information model should provide information that: 1133 o Is X required for the data field to be accepted and applied? 1135 o If X is optional, then how does "X" as an optional portion of data 1136 field interact with the required aspects of the data field? 1138 o Does the data field have defaults for the mandatory portion of the 1139 field and the optional portions of the field 1141 o Is X required to be within a particular set of values (e.g. range, 1142 length of strings)? 1144 The information model needs to be clear about what read or write 1145 values are set by client and what responses or actions are required 1146 by the agent. It is important to indicate what is required or 1147 optional in client values and agent responses/actions. 1149 6.4.5.3. Managing Variation: Templating 1151 A template is a collection of information to address a problem; it 1152 cuts across the notions of class and object instances. A template 1153 provides a set of defined values for a set of information fields and 1154 can specify a set of values that must be provided to complete the 1155 template. Further, a flexible template scheme may allow some of the 1156 defined values can be over-written. 1158 For instance, assigning traffic to a particular service class might 1159 be done by specifying a template Queueing with a parameter to 1160 indicate Gold, Silver, or Best Effort. The details of how that is 1161 carried out are not modeled. This does assume that the necessary 1162 templates are made available on the Routing Element via some 1163 mechanism other than I2RS. The idea is that by providing suitable 1164 templates for tasks that need to be accomplished, with templates 1165 implemented differently for different kinds of Routing Elements, the 1166 client can easily interact with the Routing Element without concern 1167 for the variations which are handled by values included in the 1168 template. 1170 If implementation variation can be exposed in other ways, templates 1171 may not be needed. However, templates themselves could be objects 1172 referenced in the protocol messages, with Routing Elements being 1173 configured with the proper templates to complete the operation. This 1174 is a topic for further discussion. 1176 6.4.5.4. Object Relationships 1178 Objects (in a Routing Element or otherwise) do not exist in 1179 isolation. They are related to each other. One of the important 1180 things a class definition does is represent the relationships between 1181 instances of different classes. These relationships can be very 1182 simple, or quite complicated. The following lists the information 1183 relationships that the information models need to support. 1185 6.4.5.4.1. Initialization 1187 The simplest relationship is that one object instance is initialized 1188 by copying another. For example, one may have an object instance 1189 that represents the default setup for a tunnel, and all new tunnels 1190 have fields copied from there if they are not set as part of 1191 establishment. This is closely related to the templates discussed 1192 above, but not identical. Since the relationship is only momentary 1193 it is often not formally represented in modeling, but only captured 1194 in the semantic description of the default object. 1196 6.4.5.4.2. Correlation Identification 1198 Often, it suffices to indicate in one object that it is related to a 1199 second object, without having a strong binding between the two. So 1200 an Identifier is used to represent the relationship. This can be 1201 used to allow for late binding, or a weak binding that does not even 1202 need to exist. A policy name in an object might indicate that if a 1203 policy by that name exists, it is to be applied under some 1204 circumstance. In modeling, this is often represented by the type of 1205 the value. 1207 6.4.5.4.3. Object References 1209 Sometimes the relationship between objects is stronger. A valid ARP 1210 entry has to point to the active interface over which it was derived. 1211 This is the classic meaning of an object reference in programming. 1212 It can be used for relationships like containment or dependence. 1213 This is usually represented by an explicit modeling link. 1215 6.4.5.4.4. Active Reference 1217 There is an even stronger form of coupling between objects if changes 1218 in one of the two objects are always to be reflected in the state of 1219 the other. For example, if a Tunnel has an MTU (maximum transmit 1220 unit), and link MTU changes need to immediately propagate to the 1221 Tunnel MTU, then the tunnel is actively coupled to the link 1222 interface. This kind of active state coupling implies some sort of 1223 internal bookkeeping to ensure consistency, often conceptualized as a 1224 subscription model across objects. 1226 7. I2RS Client Agent Interface 1228 7.1. One Control and Data Exchange Protocol 1230 This I2RS architecture assumes a data-model driven protocol where the 1231 data-models are defined in Yang 1.1 ([RFC6020]), Yang 1.1 1232 ([I-D.ietf-netmod-rfc6020bis]), and associated Yang based model 1233 drafts ([RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]). Two 1234 the protocols to be expanded to support the I2RS protocol are NETCONF 1235 [RFC6241] and RESTCONF [I-D.ietf-netconf-restconf]. This helps meet 1236 the goal of simplicity and thereby enhances deployability. The I2RS 1237 protocol may need to use several underlying transports (TCP, SCTP 1238 (stream control transport protocol), DCCP (Datagram Congestion 1239 Control Protocol)), with suitable authentication and integrity 1240 protection mechanisms. These different transports can support 1241 different types of communication (e.g. control, reading, 1242 notifications, and information collection) and different sets of 1243 data. Whatever transport is used for the data exchange, it must also 1244 support suitable congestion control mechanisms. The transports 1245 chosen should be operator and implementor friendly to ease adoption. 1247 7.2. Communication Channels 1249 Multiple communication channels and multiple types of communication 1250 channels are required. There may be a range of requirements (e.g. 1251 confidentiality, reliability), and to support the scaling there may 1252 need to be channels originating from multiple sub-components of a 1253 routing element and/or to multiple parts of an I2RS client. All such 1254 communication channels will use the same higher-layer I2RS protocol 1255 (which combines secure transport and I2RS contextual information). 1256 The use of additional channels for communication will be coordinated 1257 between the I2RS client and the I2RS agent using this protocol. 1259 I2RS protocol communication may be delivered in-band via the routing 1260 system's data plane. I2RS protocol communication might be delivered 1261 out-of-band via a management interface. Depending on what operations 1262 are requested, it is possible for the I2RS protocol communication to 1263 cause the in-band communication channels to stop working; this could 1264 cause the I2RS agent to become unreachable across that communication 1265 channel. 1267 7.3. Capability Negotiation 1269 The support for different protocol capabilities and I2RS Services 1270 will vary across I2RS Clients and Routing Elements supporting I2RS 1271 Agents. Since each I2RS Service is required to include a capability 1272 model (see Section 6.4), negotiation at the protocol level can be 1273 restricted to protocol specifics and which I2RS Services are 1274 supported. 1276 Capability negotiation (such as which transports are supported beyond 1277 the minimum required to implement) will clearly be necessary. It is 1278 important that such negotiations be kept simple and robust, as such 1279 mechanisms are often a source of difficulty in implementation and 1280 deployment. 1282 The protocol capability negotiation can be segmented into the basic 1283 version negotiation (required to ensure basic communication), and the 1284 more complex capability exchange which can take place within the base 1285 protocol mechanisms. In particular, the more complex protocol and 1286 mechanism negotiation can be addressed by defining information models 1287 for both the I2RS Agent and the I2RS Client. These information 1288 models can describe the various capability options. This can then 1289 represent and be used to communicate important information about the 1290 agent, and the capabilities thereof. 1292 7.4. Scope Policy Specifications 1294 As section 4.1 and 4.2 describe, each I2RS Client will have a unique 1295 identity and it may have a secondary identity (see section 2) to aid 1296 in troubleshooting. As section 4 indicates, all authentication and 1297 authorization mechanisms are based on the primary Identity which 1298 links to a role with scope policy for reading data, for writing data, 1299 and limitations on the resources that can be consumed. 1300 Specifications for scope policy need to specify the data and value 1301 ranges for portion of scope policy. 1303 7.5. Connectivity 1305 A client may or may not maintain an active communication channel with 1306 an agent. Therefore, an agent may need to open a communication 1307 channel to the client to communicate previously requested 1308 information. The lack of an active communication channel does not 1309 imply that the associated client is non-functional. When 1310 communication is required, the agent or client can open a new 1311 communication channel. 1313 State held by an agent that is owned by a client should not be 1314 removed or cleaned up when a client is no longer communicating - even 1315 if the agent cannot successfully open a new communication channel to 1316 the client. 1318 For many applications, it may be desirable to clean up state if a 1319 network application dies before removing the state it has created. 1320 Typically, this is dealt with in terms of network application 1321 redundancy. If stronger mechanisms are desired, mechanisms outside 1322 of I2RS may allow a supervisory network application to monitor I2RS 1323 clients, and based on policy known to the supervisor clean up state 1324 if applications die. More complex mechanism instantiated in the I2RS 1325 agent would add complications to the I2RS protocol and are thus left 1326 for future work. 1328 Some examples of such a mechanism include the following. In one 1329 option, the client could request state clean-up if a particular 1330 transport session is terminated. The second is to allow state 1331 expiration, expressed as a policy associated with the I2RS client's 1332 role. The state expiration could occur after there has been no 1333 successful communication channel to or from the I2RS client for the 1334 policy-specified duration. 1336 7.6. Notifications 1338 As with any policy system interacting with the network, the I2RS 1339 Client needs to be able to receive notifications of changes in 1340 network state. Notifications here refers to changes which are 1341 unanticipated, represent events outside the control of the systems 1342 (such as interface failures on controlled devices), or are 1343 sufficiently sparse as to be anomalous in some fashion. A 1344 notification may also be due to a regular event. 1346 Such events may be of interest to multiple I2RS Clients controlling 1347 data handled by an I2RS Agent, and to multiple other I2RS clients 1348 which are collecting information without exerting control. The 1349 architecture therefore requires that it be practical for I2RS Clients 1350 to register for a range of notifications, and for the I2RS Agents to 1351 send notifications to a number of Clients. The I2RS Client should be 1352 able to filter the specific notifications that will be received; the 1353 specific types of events and filtering operations can vary by 1354 information model and need to be specified as part of the information 1355 model. 1357 The I2RS information model needs to include representation of these 1358 events. As discussed earlier, the capability information in the 1359 model will allow I2RS clients to understand which events a given I2RS 1360 Agent is capable of generating. 1362 For performance and scaling by the I2RS client and general 1363 information confidentiality, an I2RS Client needs to be able to 1364 register for just the events it is interested in. It is also 1365 possible that I2RS might provide a stream of notifications via a 1366 publish/subscribe mechanism that is not amenable to having the I2RS 1367 agent do the filtering. 1369 7.7. Information collection 1371 One of the other important aspects of the I2RS is that it is intended 1372 to simplify collecting information about the state of network 1373 elements. This includes both getting a snapshot of a large amount of 1374 data about the current state of the network element, and subscribing 1375 to a feed of the ongoing changes to the set of data or a subset 1376 thereof. This is considered architecturally separate from 1377 notifications due to the differences in information rate and total 1378 volume. 1380 7.8. Multi-Headed Control 1382 As was described earlier, an I2RS Agent interacts with multiple I2RS 1383 Clients who are actively controlling the network element. From an 1384 architecture and design perspective, the assumption is that by means 1385 outside of this system the data to be manipulated within the network 1386 element is appropriately partitioned so that any given piece of 1387 information is only being manipulated by a single I2RS Client. 1389 Nonetheless, unexpected interactions happen and two (or more) I2RS 1390 clients may attempt to manipulate the same piece of data. This is 1391 considered an error case. This architecture does not attempt to 1392 determine what the right state of data should be when such a 1393 collision happens. Rather, the architecture mandates that there be 1394 decidable means by which I2RS Agents handle the collisions. The 1395 mechanism for ensuring predictability is to have a simple priority 1396 associated with each I2RS clients, and the highest priority change 1397 remains in effect. In the case of priority ties, the first client 1398 whose attribution is associated with the data will keep control. 1400 In order for this approach to multi-headed control to be useful for 1401 I2RS Clients, it is important that it is possible for an I2RS Client 1402 to register for changes to any changes made by I2RS to data that it 1403 may care about. This is included in the I2RS event mechanisms. This 1404 also needs to apply to changes made by CLI/NETCONF/SNMP within the 1405 write-scope of the I2RS Agent, as the same priority mechanism (even 1406 if it is "CLI always wins") applies there. The I2RS client may then 1407 respond to the situation as it sees fit. 1409 7.9. Transactions 1411 In the interest of simplicity, the I2RS architecture does not include 1412 multi-message atomicity and rollback mechanisms. Rather, it includes 1413 a small range of error handling for a set of operations included in a 1414 single message. An I2RS Client may indicate one of the following 1415 three error handling for a given message with multiple operations 1416 which it sends to an I2RS Agent: 1418 Perform all or none: This traditional SNMP semantic indicates that 1419 other I2RS agent will keep enough state when handling a single 1420 message to roll back the operations within that message. Either 1421 all the operations will succeed, or none of them will be applied 1422 and an error message will report the single failure which caused 1423 them not to be applied. This is useful when there are, for 1424 example, mutual dependencies across operations in the message. 1426 Perform until error: In this case, the operations in the message 1427 are applied in the specified order. When an error occurs, no 1428 further operations are applied, and an error is returned 1429 indicating the failure. This is useful if there are dependencies 1430 among the operations and they can be topologically sorted. 1432 Perform all storing errors: In this case, the I2RS Agent will 1433 attempt to perform all the operations in the message, and will 1434 return error indications for each one that fails. This is useful 1435 when there is no dependency across the operation, or where the 1436 client would prefer to sort out the effect of errors on its own. 1438 In the interest of robustness and clarity of protocol state, the 1439 protocol will include an explicit reply to modification or write 1440 operations even when they fully succeed. 1442 8. Operational and Manageability Considerations 1444 In order to facilitate troubleshooting of routing elements 1445 implementing I2RS agents, the routing elements should provide for a 1446 mechanism to show actively provisioned I2RS state and other I2RS 1447 Agent internal information. Note that this information may contain 1448 highly sensitive material subject to the Security Considerations of 1449 any data models implemented by that Agent and thus must be protected 1450 according to those considerations. Preferably, this mechanism should 1451 use a different privileged means other than simply connecting as an 1452 I2RS client to learn the data. Using a different mechanism should 1453 improve traceability and failure management. 1455 Manageability plays a key aspect in I2RS. Some initial examples 1456 include: 1458 Resource Limitations: Using I2RS, applications can consume 1459 resources, whether those be operations in a time-frame, entries in 1460 the RIB, stored operations to be triggered, etc. The ability to 1461 set resource limits based upon authorization is important. 1463 Configuration Interactions: The interaction of state installed via 1464 the I2RS and via a router's configuration needs to be clearly 1465 defined. As described in this architecture, a simple priority 1466 that is configured is used to provide sufficient policy 1467 flexibility. 1469 Traceability of Interactions: The ability to trace the interactions 1470 of the requests received by the I2RS Agent's and actions taken by 1471 the I2RS agents is needed so that operations can monitor I2RS 1472 Agents during deployment, and troubleshoot software or network 1473 problems. 1475 Notification Subscription Service: The ability for an I2RS Client to 1476 subscribe to a notification stream pushed from the I2RS Agent 1477 (rather than having I2RS client poll the I2RS agent) provides a 1478 more scalable notification handling for the I2RS Agent-Client 1479 interactions. 1481 9. IANA Considerations 1483 This document includes no request to IANA. 1485 10. Acknowledgements 1487 Significant portions of this draft came from draft-ward-i2rs- 1488 framework-00 and draft-atlas-i2rs-policy-framework-00. 1490 The authors would like to thank Nitin Bahadur, Shane Amante, Ed 1491 Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe 1492 Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott 1493 Brim, Thomas Narten, Dean Bogdanovic, Tom Petch, Robert Raszuk, 1494 Sriganesh Kini, John Mattsson, Nancy Cam-Winget, DaCheng Zhang, Qin 1495 Wu, Ahmed Abro, Salman Asadullah, Eric Yu, and Deborah Brungard for 1496 their suggestions and review. 1498 11. Informative References 1500 [I-D.ietf-i2rs-problem-statement] 1501 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 1502 Routing System Problem Statement", draft-ietf-i2rs- 1503 problem-statement-10 (work in progress), February 2016. 1505 [I-D.ietf-idr-ls-distribution] 1506 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 1507 Ray, "North-Bound Distribution of Link-State and TE 1508 Information using BGP", draft-ietf-idr-ls-distribution-13 1509 (work in progress), October 2015. 1511 [I-D.ietf-netconf-restconf] 1512 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1513 Protocol", draft-ietf-netconf-restconf-09 (work in 1514 progress), December 2015. 1516 [I-D.ietf-netmod-rfc6020bis] 1517 Bjorklund, M., "The YANG 1.1 Data Modeling Language", 1518 draft-ietf-netmod-rfc6020bis-11 (work in progress), 1519 February 2016. 1521 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1522 the Network Configuration Protocol (NETCONF)", RFC 6020, 1523 DOI 10.17487/RFC6020, October 2010, 1524 . 1526 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1527 and A. Bierman, Ed., "Network Configuration Protocol 1528 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1529 . 1531 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1532 Protocol (NETCONF) Access Control Model", RFC 6536, 1533 DOI 10.17487/RFC6536, March 2012, 1534 . 1536 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1537 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1538 . 1540 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1541 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1542 . 1544 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1545 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1546 . 1548 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 1549 RFC 7277, DOI 10.17487/RFC7277, June 2014, 1550 . 1552 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1553 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1554 2014, . 1556 Authors' Addresses 1558 Alia Atlas 1559 Juniper Networks 1560 10 Technology Park Drive 1561 Westford, MA 01886 1562 USA 1564 Email: akatlas@juniper.net 1565 Joel Halpern 1566 Ericsson 1568 Email: Joel.Halpern@ericsson.com 1570 Susan Hares 1571 Huawei 1573 Email: shares@ndzh.com 1575 Dave Ward 1576 Cisco Systems 1577 Tasman Drive 1578 San Jose, CA 95134 1579 USA 1581 Email: wardd@cisco.com 1583 Thomas D. Nadeau 1584 Brocade 1586 Email: tnadeau@lucidvision.com