idnits 2.17.1 draft-atlas-i2rs-architecture-00.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 432: '...ween the I2RS client and agent MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2013) is 3947 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-atlas-i2rs-problem-statement-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 30, 2013 Ericsson 6 S. Hares 7 ADARA 8 D. Ward 9 Cisco Systems 10 June 28, 2013 12 An Architecture for the Interface to the Routing System 13 draft-atlas-i2rs-architecture-00 15 Abstract 17 This document describes an architecture for a standard, programmatic 18 interface for state transfer in and out of the Internet's routing 19 system. It describes the basic architecture, the components, and 20 their interfaces with particular focus on those to be standardized as 21 part of I2RS. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 30, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Functional Overview . . . . . . . . . . . . . . . . . . . 3 59 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3. Key Architectural Properties . . . . . . . . . . . . . . . . 9 62 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 64 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 10 65 3.4. Authorization and Authentication . . . . . . . . . . . . 10 66 4. Network Applications and I2RS Client . . . . . . . . . . . . 10 67 4.1. Example Network Application: Topology Manager . . . . . . 11 68 5. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 11 69 5.1. Relationship to its Routing Element . . . . . . . . . . . 11 70 5.2. State Storage . . . . . . . . . . . . . . . . . . . . . . 12 71 5.2.1. Starting and Ending . . . . . . . . . . . . . . . . . 12 72 5.2.2. Reversion . . . . . . . . . . . . . . . . . . . . . . 13 73 5.3. Interactions with Local Config . . . . . . . . . . . . . 13 74 5.4. Routing Components and Associated I2RS Services . . . . . 13 75 5.4.1. Unicast and Multicast RIB and LFIB . . . . . . . . . 14 76 5.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 14 77 5.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 15 78 5.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 15 79 6. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 15 80 6.1. Protocol Structure . . . . . . . . . . . . . . . . . . . 15 81 6.2. Channel . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 6.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 16 83 6.4. Identity and Security Role . . . . . . . . . . . . . . . 16 84 6.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 16 85 6.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 17 86 6.7. Information collection . . . . . . . . . . . . . . . . . 17 87 6.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 18 88 6.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 18 89 7. Manageability Considerations . . . . . . . . . . . . . . . . 19 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 93 11. Informative References . . . . . . . . . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 96 1. Introduction 98 Routers that form the Internet's routing infrastructure maintain 99 state at various layers of detail and function. For example, a 100 typical router maintains a Routing Information Base (RIB), and 101 implements routing protocols such as OSPF, ISIS, BGP to exchange 102 protocol state and other information about the state of the network 103 with other routers. 105 A router also has information that may be required for applications 106 to understand the network, verify that programmed state is installed 107 in the forwarding plane, measure the behavior of various flows, 108 routes or forwarding entries, as well as understand the configured 109 and active states of the router. Furthermore, routers are typically 110 configured with procedural or policy-based instructions that tell 111 them how to convert all of this information into the forwarding 112 operations that are installed in the forwarding plane. It is also 113 the active state information that describes the expected and observed 114 operational behavior of the router. 116 This document sets out an architecture for a common, standards-based 117 interface to this information. This Interface to the Routing System 118 (I2RS) facilitates control and diagnosis of the RIB manager's state, 119 as well as enabling network applications to be built on top of 120 today's routed networks. The I2RS is a programmatic asynchronous 121 interface for transferring state into and out of the Internet's 122 routing system, and recognizes that the routing system and a router's 123 OS provide useful mechanisms that applications could harness to 124 accomplish application-level goals. 126 Fundamental to the I2RS are clear data models that define the 127 semantics of the information that can be written and read. The I2RS 128 provides a framework for registering for and requesting the 129 appropriate information for each particular application. The I2RS 130 provides a way for applications to customize network behavior while 131 leveraging the existing routing system. 133 The I2RS, and therefore this document, is specifically focused on an 134 interface for routing and forwarding data. 136 1.1. Functional Overview 138 There are four key aspects to the I2RS. First, the interface is a 139 programmatic interface meaning that it is asynchronous and offers 140 fast, interactive access. Second, the I2RS gives access to 141 information and state that is not usually configurable or modeled in 142 existing implementations or configuration protocols. Third, the I2RS 143 gives applications the ability to learn additional, structured, 144 filterable information and events from the router. Fourth, the I2RS 145 will be data-model driven to facilitate extensibility and provide 146 standard data-models to be used by network applications. 148 I2RS is described as an asynchronous programmatic interface; the key 149 properties of which are described in Section 5 of 150 [I-D.atlas-i2rs-problem-statement]. 152 Such an interface facilitates the specification of implicitly non- 153 permanent state into the routing system, that can optionally be made 154 permanent. In addition, the extraction of that information and 155 additional dynamic information from the routing system is a critical 156 component of the interface. A non-routing protocol or application 157 could inject state into a network element's OS via the state- 158 insertion aspects of the interface and that state could then be 159 distributed in a routing or signaling protocol. 161 There are several types of information that the I2RS will facilitate 162 an I2RS Client obtaining. These range from dynamic event 163 notifications (e.g. changes to a particular next-hop, interface up/ 164 down, etc.)to information collection streams (statistics, topology, 165 route changes, etc) to simply read operations. The I2RS provides the 166 ability for an I2RS client to request filtered and thresholded 167 information as well as events. 169 The existing mechanisms, such as SNMP and NetConf, that allow state 170 to be written and read do not meet all of the key properties given in 171 [I-D.atlas-i2rs-problem-statement] for I2RS. The overhead of 172 infrastructure is also quite high and many MIBs do not, in definition 173 or practice, allow writing of state. There is also very limited 174 capability to add new application-specific state to be distributed 175 via the routing system. 177 ForCES is another data-model-driven method for writing state into a 178 router, but its focus is on the forwarding plane. By focusing on the 179 forwarding plane, it requires that the forwarding plane be modeled 180 and programmable and ignores the existence and intelligence of the 181 router OS and routing system. ForCES provides a lower-level 182 interface than I2RS is intended to address. 184 1.2. Architectural Overview 185 The figure in Figure 1 shows the basic architecture for I2RS. Inside 186 a Routing Element, the I2RS agent interacts with both the routing 187 subsystem and with local configuration. A network application uses 188 an I2RS client to communicate with one or more I2RS agents on their 189 routing elements. The scope of I2RS is to define the interactions 190 between the I2RS agent and the I2RS client and the associated proper 191 behavior of the I2RS agent and I2RS client. 193 *********************** *********************** 194 * Application A * * Application B * 195 * * * * 196 * +----------------+ * * +----------------+ * 197 * | Client A | * * | Client B | * 198 * +----------------+ * * +----------------+ * 199 ******* ^ ************* ***** ^ ****** ^ ****** 200 | | | 201 | -----------------------| | 202 | | | 203 ******* v ***** v ************ ************** v ********** 204 * +----------------+ * * +----------------+ * 205 * | Agent 1 | * * | Agent 2 | * 206 * +----------------+ * * +----------------+ * 207 * ^ ^ ^ * * ^ ^ ^ * 208 * | | | * * | | | * 209 * v | v * * v | v * 210 * *********** | ********** * * *********** | ********* * 211 * * Routing * | * Local * * * * Routing * | * Local * * 212 * *********** | * Config * * * *********** | * Config* * 213 * | ********** * * | ********* * 214 * v * * v * 215 * ************ * * *********** * 216 * * Dynamic * * * * Dynamic * * 217 * * System * * * * System * * 218 * * State * * * * State * * 219 * ************ * * *********** * 220 * * * * 221 * Routing Element 1 * * Routing Element 2 * 222 ****************************** *************************** 224 Figure 1: Architecture of I2RS clients and agents 226 Routing Element: A Routing Element implements at least some portion 227 of the routing system. It does not need to have a forwarding 228 plane associated with it. Examples of Routing Elements can 229 include: 231 A router with a forwarding plane and RIB Manager that runs 232 ISIS, OSPF, BGP, PIM, etc. 234 A server that runs BGP as a Route Reflector 236 An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a 237 forwarding plane and associated RIB Manager. 239 A server that runs ISIS, OSPF, BGP and uses ForCES to control a 240 remote forwarding plane. 242 A Routing Element may be locally managed, whether via CLI, SNMP, 243 or NetConf. 245 Routing: This block represents that portion of the Routing Element 246 that implements part of the Internet routing system. It includes 247 not merely standardized protocols (i.e. IS-IS, OSPF, BGP, PIM, 248 RSVP-TE, LDP, etc.), but also the RIB Manager layer. 250 Local Config: A Routing Element will provide the ability to 251 configure and manage it. The Local Config may be provided via a 252 combination of CLI, NetConf, SNMP, etc. The black box behavior 253 for interactions between the state that I2RS installs into the 254 routing element and the Local Config must be defined. 256 Dynamic System State: An I2RS agent needs access to state on a 257 routing element beyond what is contained in the routing subsystem. 258 Such state may include various counters, statistics, and local 259 events. How this information is provided to the I2RS agent is out 260 of scope, but the standardized information and data models for 261 what is exposed are part of I2RS. 263 I2RS Agent: The I2RS agent implements the I2RS protocol(s) and 264 interacts with the routing element to provide specified behavior. 266 Application: A network application that needs to manipulate the 267 network to achieve its service requirements. 269 I2RS Client: The I2RS client implements the I2RS protocol(s). It 270 interacts with other elements of the policy, provisioning, and 271 configuration system by means outside of the scope of the I2RS 272 effort. It interacts with the I2RS clients to collect information 273 from the routing and forwarding system. Based on the information 274 and the policy oriented interactions, the I2RS client may also 275 interact with the I2RS agent to modify the state of the routing 276 system the client interacts with to achieve operational goals. 278 As can be seen in Figure 1, an I2RS client can communicate with 279 multiple I2RS agents. The application associated with an I2RS client 280 may connect to one or more I2RS agents based upon its needs. 281 Similarly, an I2RS agent may communicate with multiple I2RS clients - 282 whether to respond to their requests, to send notifications, etc. 283 Timely notifications are critical so that several simultaneously 284 operating applications have up-to-date information on the state of 285 the network. 287 As can also be seen in Figure 1, an I2RS Agent may communicate with 288 multiple clients. Each client may send the agent a variety of write 289 operations. The handling of this situation has been a source of 290 discussion in the working group. In order to keep the protocol 291 simple, the current view is that two clients should not be attempting 292 to write (modify) the same piece of information. Such collisions may 293 happen, but are considered error cases that should be resolved by the 294 network application layer. 296 Multiple I2RS clients may need to supply data into the same list 297 (e.g. a prefix or filter list); this is not considered an error and 298 must be correctly handled. 300 The architectural goal for the I2RS is that such errors should 301 produce predictable behaviors, and be reportable to interested 302 clients. The details of the associated policy is discussed in 303 Section 6.8. The same policy mechanism (simple priority per I2RS 304 client) applies to interactions between the I2RS agent and the CLI/ 305 SNMP/NetConf as described in Section 5.3. 307 In addition it can be noted that there may be indirect interactions 308 between write operations. Detection and avoidance of such 309 interactions is outside the scope of the I2RS work and is left to 310 agent design and implementation for now. [[Editor's note: This topic 311 needs more discussion in the working group.]] 313 2. Terminology 315 The following terminology is used in this document. 317 agent or I2RS Agent: An I2RS agent provides the supported I2RS 318 services to the local system's routing sub-systems. The I2RS 319 agent understands the I2RS protocol and can be contacted by I2RS 320 clients. 322 client or I2RS Client: A client speaks the I2RS protocol to 323 communicate with I2RS Agents and uses the I2RS services to 324 accomplish a task as instructed by the client's local application. 325 An I2RS client can be seen as the part of an application that 326 supports I2RS and could be a software library. 328 service or I2RS Service: For the purposes of I2RS, a service refers 329 to a set of related state access functions together with the 330 policies that control its usage. The expectation is that a 331 service will be represented by a data-model. For instance, 'RIB 332 service' could be an example of a service that gives access to 333 state held in a device's RIB. 335 read scope: The set of information which the I2RS client is 336 authorized to read. This access includes the permission to see 337 the existence of data and the ability to retrieve the value of 338 that data. 340 write scope: The set of field values which the I2RS client is 341 authorized to write (i.e. add, modify or delete). This access can 342 restrict what fields can be modified or created, and what specific 343 value sets and ranges can be installed. 345 scope: When unspecified as either read scope or write scope, the 346 term scope applies to both the read scope and write scope. 348 resources: A resource is an I2RS-specific use of memory, storage, 349 or execution that a client may consume due to its I2RS operations. 350 The amount of each such resource that a client may consume in the 351 context of a particular agent can be constrained. An example of 352 such a resource could include the number of notifications 353 registered for. These are not protocol-specific resources or 354 network-specific resources. 356 role or security role: A security role specifies the scope, 357 resources, priorities, etc. that a client or agent has. 359 identity: A client is associated with exactly one specific 360 identity. State can be attributed to a particular identity. It 361 is possible for multiple communication channels to use the same 362 identity; in that case, the assumption is that the associated 363 client is coordinating such communication. 365 3. Key Architectural Properties 367 3.1. Simplicity 369 There have been many efforts over the years to improve the access to 370 the information known to the routing and forwarding system. Making 371 such information visible and usable to network management and 372 applications has many well-understood benefits. There are two 373 related challenges in doing so. The span of information potentially 374 available is very large. And the variation in the structure and 375 kinds of operations tends to introduce protocol complexity. 377 Having noted that, it is also critical to the utility of I2RS that it 378 be easily deployed and robust. Complexity in the protocol hinders 379 implementation, robustness, and deployability. Also, complexity in 380 the data models tends to actually make it harder to extend rather 381 than easier. 383 Thus, one of the key aims for I2RS is the keep the protocol and 384 modeling architecture simple. So for each architectural component or 385 aspect, we ask ourselves "do we need this complexity, or is the 386 behavior merely nice to have?" 388 3.2. Extensibility 390 There are several ways that the scope of the I2RS work is being 391 restricted in the interests of achieving a deliverable and deployable 392 result. We are only looking at the models to be used over the single 393 identified interface. We are only looking at modeling a subset of 394 the data of interest. And we are probably only representing a subset 395 of the operations that may eventually be needed (although there is 396 some hope that we are closer on that aspect than others to what is 397 needed.) 399 At the same time, it is clearly desirable for the data models and 400 protocol operations we define in the I2RS to be useful the in more 401 general settings. It should be easy to integrate data models from 402 the I2RS with other data. Other work should be able to easily extend 403 it to represent additional aspects of the network elements or network 404 systems. Hence, the data model and protocol definitions need to be 405 designed to be highly extensible, preferably in a regular and simple 406 fashion. 408 3.3. Model-Driven Programmatic Interfaces 410 A critical component of I2RS is the standard information and data 411 models with their associated semantics. While many routing protocols 412 are standardized, associated data models for them are not yet 413 available. Instead, each router uses different information, 414 mechanisms, and CLI which makes a standard interface for use by 415 applications extremely cumbersome to develop and maintain. Well- 416 known data modeling languages exist and may be used for defining the 417 necessary data models for I2RS. 419 There are several key benefits for I2RS in using model-driven 420 architecture and protocol(s). First, it allows for transferring 421 data-models whose content is not explicitly implemented or 422 understood. Second, tools can automate checking and manipulating 423 data; this is particularly valuable for both extensibility and for 424 the ability to easily manipulate and check proprietary data-models. 426 The different services provided by I2RS can correspond to separate 427 data-models. An I2RS agent can indicate which data-models are 428 supported. 430 3.4. Authorization and Authentication 432 All control exchanges between the I2RS client and agent MUST be 433 authenticated and integrity protected (so that the contents cannot be 434 changed without detection). Manipulation of the system has to be 435 accurately attributable. Architecturally, even information 436 collection and notification should be protected, although this is 437 subject to engineering tradeoffs during the design. 439 I2RS Agents, in performing information collection and manipulation, 440 will be acting on behalf of the I2RS clients. As such, they will 441 operate based on the lower of the two permissions of the agent itself 442 and of the client. 444 I2RS clients may be operating on behalf of other entities, in any one 445 of a range of broker models. While those identities are not need for 446 authorization, they should still be provided by the I2RS client to 447 the I2RS agent for purposes of tracking attribution of operations. 449 4. Network Applications and I2RS Client 451 An I2RS Client has a standardized interface that uses the I2RS 452 protocol(s) to communicate with I2RS Agents. The interface between 453 an I2RS client and the network applications is outside the scope of 454 I2RS. 456 When an I2RS Client interacts with multiple network applications, 457 that I2RS Client is behaving as a broker and may indicate this to the 458 I2RS Agents by, for example, specifying a secondary identity to allow 459 improved troubleshooting. 461 A network application that uses an I2RS client may also be considered 462 a routing element and include an I2RS agent for interactions. 463 However, where the needed information and data models for that upper 464 interface differs from that of a conventional routing element, those 465 models are, at least initially, out of scope for I2RS. 467 4.1. Example Network Application: Topology Manager 469 One example of such an application is a Topology Manager. Such an 470 application includes an I2RS client which uses the I2RS protocol to 471 collect information about the state of the network. The Topology 472 Manager would collect device and interface state from devices it 473 interacts with directly. It also collects routing configuration and 474 operation data from those devices. Most importantly, it collects 475 information about the routing system, including the contents of the 476 IGP (e.g. IS-IS or OSPF) and BGP data sets. This information is 477 provided to the I2RS client using the I2RS data models and protocols. 479 The Topology Manager may be an integral part of an application. It 480 would build internal data structures, and use the collected data to 481 drive applications like path computations or anomalous routing 482 detection. Alternatively, the Topology manager could combine the 483 I2RS collected data with other information, abstract the result, and 484 provide a coherent picture of the network state over another 485 interface. That interface might use the same I2RS protocols, and 486 could use extensions of the I2RS data models. Developing such 487 mechanisms is outside the initial scope of the I2RS work. 489 5. I2RS Agent Role and Functionality 491 The I2RS Agent is part of a routing element. As such, it has 492 relationships with that routing element as a whole, and with various 493 components of that routing element. 495 5.1. Relationship to its Routing Element 497 A Routing Element may be implemented with a wide variety of different 498 architectures: an integrated router, a split architecture, 499 distributed architecture, etc. The architecture does not need to 500 affect the general I2RS agent behavior. 502 For scalability and generality, the I2RS agent may be responsible for 503 collecting and delivering large amounts of data from various parts of 504 the routing element. Those parts may or may not actually be part of 505 a single physical device. Thus, for scalability and robustness, it 506 is important that the architecture allow for a distributed set of 507 reporting components providing collected data from the I2RS agent 508 back to the relevant I2RS clients. As currently envisioned, a given 509 I2RS agent would have only one locus per I2RS service for 510 manipulation of routing element state; distributing the manipulations 511 would inducing complications and fragility instead of scalability and 512 robustness. 514 5.2. State Storage 516 State modification requests are sent to the I2RS agent in a network 517 element by I2RS clients. The I2RS agent is responsible for applying 518 these changes to the system. One dimension of the storage for I2RS 519 Clients requests is how much data must the I2RS Agent store about 520 this configuration, and with what persistence. There are range of 521 possible answers. One extreme is where it stores nothing, cannot 522 indicate why or by whom state was placed into the routing element, 523 and relies on clients reapplying things in all possible cases. The 524 other extreme is where multiple possibilities are stored and managed, 525 as is done in the RIB for routes with a preference or priority to 526 pick between the routes. This architecture tries to provide 527 sufficient power to keep client operations effective, while still 528 being simple to implement in the I2RS Agent, and to observe 529 meaningfully during operation. 531 The I2RS agent stores the set of operations it has applied. Simply, 532 the I2RS agent stores who did what operation to which entity. New 533 changes replace any data about old ones. If an I2RS client does an 534 operation to remove some state, that state is removed and the I2RS 535 agent stores no more information about it. This allows any 536 interested party to determine what the current effect of I2RS on the 537 system is, and why. Meaningful logging is also recommended. 539 The I2RS Agent will not attempt to retain or reapply state across 540 routing element reboot. Determination of whether state still applies 541 depends heavily on the causes of reboots, and reapplication is at 542 least as likely to cause problems as it is to provide for correct 543 operation. [[Editor's note: This topics needs more discussion in the 544 working group.]] 546 5.2.1. Starting and Ending 548 An I2RS client applies changes via the I2RS interface based on policy 549 and other application inputs. While these changes may be of the form 550 "do this now, and leave it there forever", they are frequently driven 551 by other conditions which may have start times, stop times, or are 552 only to be used under certain conditions. The I2RS interface 553 protocol could be designed to allow an I2RS Client to provide a wide 554 range of such conditional information to the I2RS Agent for 555 application. At the other extreme, the I2RS client could provide all 556 such functionality based on its own clocking and network event 557 reporting from the relevant I2RS Agents. 559 Given that the complexity of possible conditions is very large, and 560 that some conditions may even cross network element boundaries, 561 clearly some degree of handling must be provided on the I2RS client. 562 As such, this architecture takes the view that all the complexity 563 associated with this should be left to the I2RS client. This 564 architectural view does mean that reliability of the communication 565 path between the I2RS client and I2RS agent is critical. [[Editor's 566 note: This requires more discussion in the working group.]] 568 5.2.2. Reversion 570 An I2RS Agent may decide that some state should no longer be applied. 571 An I2RS Client may instruct an Agent to remove state it has applied. 572 In all such cases, the state will revert to what it would have been 573 without the I2RS; that state is generally whatever was specified via 574 the CLI, NetConf, SNMP, etc. I2RS Agents will not store multiple 575 alternative states, nor try to determine which one among such a 576 plurality it should fall back to. Thus, the model followed is not 577 like the RIB, where multiple routes are stored at different 578 preferences. 580 5.3. Interactions with Local Config 582 As described above, local device configuration is considered to be 583 separate from the I2RS data store. Thus, changes may originate from 584 either source. Policy (i.e. comparisons between a CLI/SNMP/NetConf 585 priority and a I2RS agent priority) can determine whether the local 586 configuration should overwrite any state written by I2RS and 587 attributed to a particular I2RS Client or whether I2RS as attributed 588 to a particular I2RS Client can overwrite local configuration state. 590 Simply allowing the most recent state to prevail could cause race 591 conditions where the final state is not repeatably deterministic. 592 One important aspect is that if CLI/SNMP/NetConf changes data that is 593 subject to monitoring or manipulating by I2RS, then the system has to 594 be instrumented enough to provide suitable I2RS notifications of 595 these changes. 597 5.4. Routing Components and Associated I2RS Services 598 For simplicity, each logical protocol or set of functionality that be 599 compactly described in a separable information and data model is 600 considered as a separate I2RS Service. A routing element need not 601 implement all routing components described nor provide the associated 602 I2RS services. The initial services included in the I2RS 603 architecture are as follows. 605 5.4.1. Unicast and Multicast RIB and LFIB 607 Network elements concerned with routing IP maintain IP unicast RIBs. 608 Similarly, there are RIBs for IP Multicast, and a Label Information 609 Base (LIB) for MPLS. The I2RS Agent needs to be able to read and 610 write these sets of data. The I2RS data model has to include models 611 for this information. 613 In particular, with regard to writing this information, the I2RS 614 Agent should use the same mechanisms that the routing element already 615 uses to handle RIB input from multiple sources, so as to compatibly 616 change the system state. 618 The multicast state added to the multicast RIB does not need to match 619 to well-known protocol installed state. The I2RS Agent can create 620 arbitrary replication state in the RIB, subject to the advertised 621 capabilities of the routing element. 623 5.4.2. IGPs, BGP and Multicast Protocols 625 In addition to interacting with the consolidated RIB, the I2RS agent 626 needs to interact with the individual routing protocols on the 627 device. This interaction includes a number of different kinds of 628 operations: 630 o reading the various internal rib(s) of the routing protocol is 631 often helpful for understanding the state of the network. 632 Directly writing these protocol-specific RIBs or databases is NOT 633 part of the system. 635 o reading the various pieces of policy information the particular 636 protocol instance is using to drive its operations. 638 o writing policy information such as interface attributes that are 639 specific to the routing protocol or BGP policy that may indirectly 640 manipulate attributes of routes carried in BGP. 642 o writing routes or prefixes to be advertised via the protocol. 644 o joining/removing interfaces from the multicast trees 645 For example, the interaction with OSPF might include modifying the 646 local routing element's link metrics, announcing a locally-attached 647 prefix, or reading some of the OSPF link-state database. However, 648 modifying the link-state database itself would clearly not be 649 permitted; that could lead to inconsistency. 651 5.4.3. MPLS 653 The I2RS Agent will need to interact with the knobs that policy 654 attributes that control LDP operation as well as RSVP-TE based LSPs. 655 To avoid duplication, the I2RS interface will not duplicate the path 656 computation and active path setup components of the PCE protocols. 658 5.4.4. Policy and QoS Mechanisms 660 Many network elements have separate policy and QoS mechanisms, 661 including knobs which affect local path computation and queue control 662 capabilities. These capabilities vary widely across implementations, 663 and I2RS cannot model the full range of information collection or 664 manipulation of these attributes. A core set does need to be 665 included in the I2RS data models and in the expected interfaces 666 between the I2RS Agent and the network element, in order to provide 667 basic capabilities and the hooks for extensibility. 669 6. I2RS Client Agent Interface 671 6.1. Protocol Structure 673 One could view I2RS merely as a way to talk about the existing 674 network management interfaces to a network element. That would be 675 quite limiting, and would have trouble meeting the requirements 676 elucidated elsewhere. One could also view it as a collection of 677 protocols, some existing and some new, that meet the needs. While 678 that could be made to work, the complexity of such a mechanism would 679 be quite high. One would need to develop means to coordinate 680 information across a set of protocols that were not designed to work 681 together. As a result, this architecture views the I2RS interface as 682 an interface supporting a single control and data exchange protocol. 683 That protocol may use several underlying transports (TCP, SCTP, 684 DCCP), with suitable authentication and integrity protection 685 mechanisms. Whatever transport is used for the data exchange, it 686 must also support suitable congestion control mechanisms. 688 6.2. Channel 690 The uses of a single I2RS protocol does not imply that only one 691 channel of communication is needed. There may be a range of 692 reliability needs, and to support the scaling there may need to be 693 channels from multiple parts of a routing element. These will all 694 use the date exchange protocol, and establishment of additional 695 channels for communication will be coordinated between the I2RS 696 client and the I2RS agent. 698 6.3. Negotiation 700 Protocol support capabilities will vary across I2RS Clients and 701 Routing Elements supporting I2RS Agents. As such, it is likely that 702 capability negotiation (such as which transports are supported beyond 703 the minimum required to implement) will be necessary. It is 704 important that such negotiations be kept simple and robust, as such 705 mechanisms are often a source of difficulty in implementation and 706 deployment. 708 6.4. Identity and Security Role 710 Each I2RS Client will have an identity; it can also have secondary 711 identities to be used for troubleshooting. Via authentication and 712 authorization mechanisms, the I2RS agent will have a specific scope 713 for reading data, for writing data, and limitations on the resources 714 that can be consumed. The scopes need to specify both the data and 715 the value ranges. 717 6.5. Connectivity 719 A client does not need to maintain an active communication channel 720 with an agent. Therefore, an agent may need to open a communication 721 channel to the client to communicate previously requested 722 information. The lack of an active communication channel does not 723 imply that the associated client is non-functional. When 724 communication is required, the agent or client can open a new 725 communication channel. 727 State held by an agent that is owned by a client should not be 728 removed or cleaned up when a client is no longer communicating - even 729 if the agent cannot successfully open a new communication channel to 730 the client. 732 There are two different assumptions that can apply to handling dead 733 clients. The first is that the network application layer will detect 734 a dead network application and either restart that network 735 application or clean up any state left behind. The second is to 736 allow state expiration, expressed as a policy associated with the 737 I2RS client's role. The state expiration could occur after there has 738 been no successful communication channel to or from the I2RS client 739 for the policy-specified duration. 741 6.6. Notifications 743 As with any policy system interacting with the network, the I2RS 744 Agent needs to be able to receive notifications of changes in network 745 state. Notifications here refers to changes which are unanticipated, 746 represent events outside the control of the systems (such as 747 interface failures on controlled devices), or are sufficiently sparse 748 as to be anomalous in some fashion. 750 Such events may be of interest to multiple I2RS Clients controlling 751 data handled by an I2RS Agent, and to multiple other I2RS clients 752 which are collecting information without exerting control. The 753 architecture therefore requires that it be practical for I2RS Clients 754 to register for a range of notifications, and for the I2R Agents to 755 send notifications to a number of Clients. 757 As the I2RS is developed, it is likely that a management information- 758 model and data-model will be required to describe event notifications 759 for general or I2RS errors. 761 For performance and scaling by the I2RS client and general 762 information privacy, an I2RS Client needs to be able to register for 763 just the events it is interested in. It is also possible that I2RS 764 might might provide a stream of notifications via a publish/subscribe 765 mechanism that is not amenable to having the I2RS agent do the 766 filtering. 768 6.7. Information collection 770 One of the other important aspects of the I2RS is that it is intended 771 to simplify collecting information about the state of network 772 elements. This includes both getting a snapshot of a large amount of 773 data about the current state of the network element, and subscribing 774 to a feed of the ongoing changes to the set of data or a subset 775 thereof. This is considered architecturally separate from 776 notifications due to the differences in information rate and total 777 volume. 779 6.8. Multi-Headed Control 781 As was described earlier, an I2RS Agent interacts with multiple I2RS 782 Clients who are actively controlling the network element. From an 783 architecture and design perspective, the assumption is that by means 784 outside of this system the data to be manipulated within the network 785 element is appropriately partitioned so that any given piece of 786 information is only being manipulated by a single I2RS Client. 788 Nonetheless, unexpected interactions happen and two (or more) I2RS 789 clients may attempt to manipulate the same piece of data. This is 790 considered an error case. This architecture does not attempt to 791 determine what the right state of data is in such a collision Rather, 792 the architecture mandates that there be decidable means by which I2RS 793 Agents will handle the collisions. The current recommendation is to 794 have a simple priority associated with each I2RS clients, and the 795 highest priority change remains in effect. In the case of priority 796 ties, the first client whose attribution is associated with the data 797 will keep control 799 In order for this to be useful for I2RS Clients, it is important that 800 it be possible for an I2RS Client to register for changes to any I2RS 801 manipulatable data that it may care about. The I2RS client may then 802 respond to the situation as it sees fit. 804 6.9. Transactions 806 In the interest of simplicity, the I2RS architecture does not include 807 multi-message atomicity and rollback mechanisms. Rather, it includes 808 a small range of error handling for a set of operations included in a 809 single message. An I2RS Client may indicate one of the following 810 three error handling for a given message with multiple operations 811 which it sends to an I2RS Agent: 813 Perform all or none: This traditional SNMP semantic indicates that 814 other I2RS agent will keep enough state when handling a single 815 message to roll back the operations within that message. Either 816 all the operations will succeed, or none of them will be applied 817 and an error message will report the single failure which caused 818 the not to be applied. This is useful when there are, for 819 example, mutual dependencies across operations in the message. 821 Perform until error: In this case, the operations in the message 822 are applied in order. When an error occurs, no further operations 823 are applied, and an error is returned indicating the failure. 824 This is useful if there are dependencies among the operations and 825 they can be topologically sorted. 827 Perform all: In this case, the I2RS Agent will attempt to perform 828 all the operations in the message, and will return error 829 indications for each one that fails. This is useful when there is 830 no dependency across the operation, or where the client would 831 prefer to sort out the effect of errors on its own. 833 In the interest of robustness and clarity of protocol state, the 834 protocol will include an explicit reply to modification operations 835 even when they fully succeed. 837 7. Manageability Considerations 839 Manageability plays a key aspect in I2RS. Some initial examples 840 include: 842 Resource Limitations: Using I2RS, applications can consume 843 resources, whether those be operations in a time-frame, entries in 844 the RIB, stored operations to be triggered, etc. The ability to 845 set resource limits based upon authorization is important. 847 Configuration Interactions: The interaction of state installed via 848 the I2RS and via a router's configuration needs to be clearly 849 defined. As described in this architecture, a simple priority 850 that is configured can be used to express the desired policy. 852 8. Security Considerations 854 This framework describes interfaces that clearly require serious 855 consideration of security. The ability to identify, authenticate and 856 authorize applications that wish to install state is necessary and 857 briefly described in Section 3.4. Security of communications from 858 the applications is also required as discussed in Section 6.1. 859 Scopes for reading and writing data specified in the context of the 860 data models and the value ranges are discussed briefly in 861 Section 6.4. 863 9. IANA Considerations 865 This document includes no request to IANA. 867 10. Acknowledgements 869 Significant portions of this draft came from draft-ward-i2rs- 870 framework-00 and draft-atlas-i2rs-policy-framework-00. The authors 871 would like to acknowledge Tom Nadeau, who was a co-author on draft- 872 ward-i2rs-framework-00. 874 The authors would like to thank Nitin Bahadur, Shane Amante, and Ken 875 Gray for their suggestions and review. 877 11. Informative References 879 [I-D.atlas-i2rs-problem-statement] 880 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 881 Routing System Problem Statement", draft-atlas-i2rs- 882 problem-statement-00 (work in progress), February 2013. 884 Authors' Addresses 886 Alia Atlas 887 Juniper Networks 888 10 Technology Park Drive 889 Westford, MA 01886 890 USA 892 Email: akatlas@juniper.net 894 Joel Halpern 895 Ericsson 897 Email: Joel.Halpern@ericsson.com 899 Susan Hares 900 ADARA 902 Email: shares@ndzh.com 904 Dave Ward 905 Cisco Systems 906 Tasman Drive 907 San Jose, CA 95134 908 USA 910 Email: wardd@cisco.com