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