idnits 2.17.1 draft-ietf-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 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 (August 16, 2013) is 3904 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: February 17, 2014 Ericsson 6 S. Hares 7 ADARA 8 D. Ward 9 Cisco Systems 10 T. Nadeau 11 Juniper Networks 12 August 16, 2013 14 An Architecture for the Interface to the Routing System 15 draft-ietf-i2rs-architecture-00 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 February 17, 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 . . . . . . . . . . . . . . . . 8 64 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 6.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 16 85 6.4. Identity and Security Role . . . . . . . . . . . . . . . 16 86 6.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 16 87 6.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 17 88 6.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 17 89 6.7. Information collection . . . . . . . . . . . . . . . . . 18 90 6.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 18 91 6.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 19 92 7. Manageability Considerations . . . . . . . . . . . . . . . . 19 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 96 11. Informative References . . . . . . . . . . . . . . . . . . . 20 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction 101 Routers that form the Internet's routing infrastructure maintain 102 state at various layers of detail and function. For example, a 103 typical router maintains a Routing Information Base (RIB), and 104 implements routing protocols such as OSPF, ISIS, BGP to exchange 105 protocol state and other information about the state of the network 106 with other routers. 108 A router also has information that may be required for applications 109 to understand the network, verify that programmed state is installed 110 in the forwarding plane, measure the behavior of various flows, 111 routes or forwarding entries, as well as understand the configured 112 and active states of the router. Furthermore, routers are typically 113 configured with procedural or policy-based instructions that tell 114 them how to convert all of this information into the forwarding 115 operations that are installed in the forwarding plane. It is also 116 the active state information that describes the expected and observed 117 operational behavior of the router. 119 This document sets out an architecture for a common, standards-based 120 interface to this information. This Interface to the Routing System 121 (I2RS) facilitates control and diagnosis of the RIB manager's state, 122 as well as enabling network applications to be built on top of 123 today's routed networks. The I2RS is a programmatic asynchronous 124 interface for transferring state into and out of the Internet's 125 routing system, and recognizes that the routing system and a router's 126 OS provide useful mechanisms that applications could harness to 127 accomplish application-level goals. 129 Fundamental to the I2RS are clear data models that define the 130 semantics of the information that can be written and read. The I2RS 131 provides a framework for registering for and requesting the 132 appropriate information for each particular application. The I2RS 133 provides a way for applications to customize network behavior while 134 leveraging the existing routing system as much as desired. 136 The I2RS, and therefore this document, are specifically focused on an 137 interface for routing data. 139 1.1. Functional Overview 141 There are four key aspects to the I2RS. First, the interface is a 142 programmatic interface which needs to be asynchronous and offers 143 fast, interactive access. Second, the I2RS gives access to 144 information and state that is not usually configurable or modeled in 145 existing implementations or configuration protocols. Third, the I2RS 146 gives applications the ability to learn additional, structured, 147 filterable information and events from the router. Fourth, the I2RS 148 will be data-model driven to facilitate extensibility and provide 149 standard data-models to be used by network applications. 151 I2RS is described as an asynchronous programmatic interface; the key 152 properties of which are described in Section 5 of 153 [I-D.atlas-i2rs-problem-statement]. 155 Such an interface facilitates the specification of implicitly non- 156 permanent state into the routing system, that can optionally be made 157 permanent. In addition, the extraction of that information and 158 additional dynamic information from the routing system is a critical 159 component of the interface. A non-routing protocol or application 160 could inject state into a routing element via the state-insertion 161 aspects of the I2RS and that state could then be distributed in a 162 routing or signaling protocol and/or be used locally (e.g. to program 163 the co-located forwarding plane). 165 There are several types of information that the I2RS will facilitate 166 an I2RS Client obtaining. These range from dynamic event 167 notifications (e.g. changes to a particular next-hop, interface up/ 168 down, etc.)to information collection streams (statistics, topology, 169 route changes, etc) to simply read operations. The I2RS provides the 170 ability for an I2RS client to request filtered and thresholded 171 information as well as events. 173 1.2. Architectural Overview 175 The figure in Figure 1 shows the basic architecture for I2RS. Inside 176 a Routing Element, the I2RS agent interacts with both the routing 177 subsystem and with local configuration. A network application uses 178 an I2RS client to communicate with one or more I2RS agents on their 179 routing elements. The scope of I2RS is to define the interactions 180 between the I2RS agent and the I2RS client and the associated proper 181 behavior of the I2RS agent and I2RS client. 183 *********************** *********************** 184 * Application A * * Application B * 185 * * * * 186 * +----------------+ * * +----------------+ * 187 * | Client A | * * | Client B | * 188 * +----------------+ * * +----------------+ * 189 ******* ^ ************* ***** ^ ****** ^ ****** 190 | | | 191 | -----------------------| | 192 | | | 193 ******* v ***** v ************ ************** v ********** 194 * +----------------+ * * +----------------+ * 195 * | Agent 1 | * * | Agent 2 | * 196 * +----------------+ * * +----------------+ * 197 * ^ ^ ^ * * ^ ^ ^ * 198 * | | | * * | | | * 199 * v | v * * v | v * 200 * *********** | ********** * * *********** | ********* * 201 * * Routing * | * Local * * * * Routing * | * Local * * 202 * * and * | * Config * * * * and * | * Config* * 203 * *Signaling* | ********** * * *Signaling* | ********* * 204 * ********** v * * *********** v * 205 * ************ * * *********** * 206 * * Dynamic * * * * Dynamic * * 207 * * System * * * * System * * 208 * * State * * * * State * * 209 * ************ * * *********** * 210 * * * * 211 * Routing Element 1 * * Routing Element 2 * 212 ****************************** *************************** 214 Figure 1: Architecture of I2RS clients and agents 216 Routing Element: A Routing Element implements at least some portion 217 of the routing system. It does not need to have a forwarding 218 plane associated with it. Examples of Routing Elements can 219 include: 221 A router with a forwarding plane and RIB Manager that runs 222 ISIS, OSPF, BGP, PIM, etc. 224 A server that runs BGP as a Route Reflector 226 An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a 227 forwarding plane and associated RIB Manager. 229 A server that runs ISIS, OSPF, BGP and uses ForCES to control a 230 remote forwarding plane. 232 A Routing Element may be locally managed, whether via CLI, SNMP, 233 or NETCONF. 235 Routing and Signaling: This block represents that portion of the 236 Routing Element that implements part of the Internet routing 237 system. It includes not merely standardized protocols (i.e. IS- 238 IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager 239 layer. 241 Local Config: A Routing Element will provide the ability to 242 configure and manage it. The Local Config may be provided via a 243 combination of CLI, NETCONF, SNMP, etc. The black box behavior 244 for interactions between the state that I2RS installs into the 245 routing element and the Local Config must be defined. 247 Dynamic System State: An I2RS agent needs access to state on a 248 routing element beyond what is contained in the routing subsystem. 249 Such state may include various counters, statistics, and local 250 events. How this information is provided to the I2RS agent is out 251 of scope, but the standardized information and data models for 252 what is exposed are part of I2RS. 254 I2RS Agent: The I2RS agent implements the I2RS protocol(s) and 255 interacts with the routing element to provide specified behavior. 257 Application: A network application that needs to manipulate the 258 network to achieve its service requirements. 260 I2RS Client: The I2RS client implements the I2RS protocol(s). It 261 interacts with other elements of the policy, provisioning, and 262 configuration system by means outside of the scope of the I2RS 263 effort. It interacts with the I2RS agents to collect information 264 from the routing and forwarding system. Based on the information 265 and the policy oriented interactions, the I2RS client may also 266 interact with the I2RS agent to modify the state of the routing 267 system the client interacts with to achieve operational goals. 269 As can be seen in Figure 1, an I2RS client can communicate with 270 multiple I2RS agents. An I2RS client may connect to one or more I2RS 271 agents based upon its needs. Similarly, an I2RS agent may 272 communicate with multiple I2RS clients - whether to respond to their 273 requests, to send notifications, etc. Timely notifications are 274 critical so that several simultaneously operating applications have 275 up-to-date information on the state of the network. 277 As can also be seen in Figure 1, an I2RS Agent may communicate with 278 multiple clients. Each client may send the agent a variety of write 279 operations. The handling of this situation has been a source of 280 discussion in the working group. In order to keep the protocol 281 simple, the current view is that two clients should not be attempting 282 to write (modify) the same piece of information. Such collisions may 283 happen, but are considered error cases that should be resolved by the 284 network applications and management systems. 286 Multiple I2RS clients may need to supply data into the same list 287 (e.g. a prefix or filter list); this is not considered an error and 288 must be correctly handled. The nuances so that writers do not 289 normally collide should be handled in the information models. 291 The architectural goal for the I2RS is that such errors should 292 produce predictable behaviors, and be reportable to interested 293 clients. The details of the associated policy is discussed in 294 Section 6.8. The same policy mechanism (simple priority per I2RS 295 client) applies to interactions between the I2RS agent and the CLI/ 296 SNMP/NETCONF as described in Section 5.3. 298 In addition it must be noted that there may be indirect interactions 299 between write operations. Detection and avoidance of such 300 interactions is outside the scope of the I2RS work and is left to 301 agent design and implementation for now. [[Editor's note: This topic 302 needs more discussion in the working group.]] 304 2. Terminology 306 The following terminology is used in this document. 308 agent or I2RS Agent: An I2RS agent provides the supported I2RS 309 services to the local system's routing sub-systems. The I2RS 310 agent understands the I2RS protocol and can be contacted by I2RS 311 clients. 313 client or I2RS Client: A client speaks the I2RS protocol to 314 communicate with I2RS Agents and uses the I2RS services to 315 accomplish a task. An I2RS client can be seen as the part of an 316 application that uses and supports I2RS and could be a software 317 library. 319 service or I2RS Service: For the purposes of I2RS, a service refers 320 to a set of related state access functions together with the 321 policies that control their usage. The expectation is that a 322 service will be represented by a data-model. For instance, 'RIB 323 service' could be an example of a service that gives access to 324 state held in a device's RIB. 326 read scope: The set of information which the I2RS client is 327 authorized to read. This access includes the permission to see 328 the existence of data and the ability to retrieve the value of 329 that data. 331 notification scope: The set of events and associated information 332 that the I2RS Client can request be pushed by the I2RS Agent. 333 I2RS Clients have the ability to register for specific events and 334 information streams, but must do so given the access restrictions 335 of their notification scope. 337 write scope: The set of field values which the I2RS client is 338 authorized to write (i.e. add, modify or delete). This access can 339 restrict what data can be modified or created, and what specific 340 value sets and ranges can be installed. 342 scope: When unspecified as either read scope or write scope, the 343 term scope applies to both the read scope and write scope. 345 resources: A resource is an I2RS-specific use of memory, storage, 346 or execution that a client may consume due to its I2RS operations. 347 The amount of each such resource that a client may consume in the 348 context of a particular agent can be constrained based upon the 349 client's security role. An example of such a resource could 350 include the number of notifications registered for. These are not 351 protocol-specific resources or network-specific resources. 353 role or security role: A security role specifies the scope, 354 resources, priorities, etc. that a client or agent has. 356 identity: A client is associated with exactly one specific 357 identity. State can be attributed to a particular identity. It 358 is possible for multiple communication channels to use the same 359 identity; in that case, the assumption is that the associated 360 client is coordinating such communication. 362 secondary identity: An I2RS Client may supply a secondary opaque 363 identity that is not interpreted by the I2RS Agent. An example 364 use is when the I2RS Client is a go-between for multiple 365 applications and it is necessary to track which application has 366 requested a particular operation. 368 3. Key Architectural Properties 370 3.1. Simplicity 371 There have been many efforts over the years to improve the access to 372 the information known to the routing and forwarding system. Making 373 such information visible and usable to network management and 374 applications has many well-understood benefits. There are two 375 related challenges in doing so. First, the span of information 376 potentially available is very large. Second, the variation both in 377 the structure of the data and in the kinds of operations required 378 tends to introduce protocol complexity. 380 Having noted that, it is also critical to the utility of I2RS that it 381 be easily deployed and robust. Complexity in the protocol hinders 382 implementation, robustness, and deployability. Also, complexity in 383 the data models frequently makes it harder to extend rather than 384 easier. 386 Thus, one of the key aims for I2RS is the keep the protocol and 387 modeling architecture simple. So for each architectural component or 388 aspect, we ask ourselves "do we need this complexity, or is the 389 behavior merely nice to have?" Protocol parsimony is clearly a goal. 391 3.2. Extensibility 393 There are several ways that the scope of the I2RS work is being 394 restricted in the interests of achieving a deliverable and deployable 395 result. We are only working on the models to be used over the single 396 identified interface. We are only looking at modeling a subset of 397 the data of interest. And we are probably only representing a subset 398 of the operations that may eventually be needed (although there is 399 some hope that we are closer on that aspect than others to what is 400 needed.) Thus, it is important to consider extensibility not only of 401 the underlying services' data models, but also of the primitives and 402 protocol operations. 404 At the same time, it is clearly desirable for the data models and 405 protocol operations we define in the I2RS to be useful the in more 406 general settings. It should be easy to integrate data models from 407 the I2RS with other data. Other work should be able to easily extend 408 it to represent additional aspects of the network elements or network 409 systems. Hence, the data model and protocol definitions need to be 410 designed to be highly extensible, preferably in a regular and simple 411 fashion. 413 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 to support functionality such as 454 accounting and troubleshooting. 456 4. Network Applications and I2RS Client 458 An I2RS Client has a standardized interface that uses the I2RS 459 protocol(s) to communicate with I2RS Agents. The interface between 460 an I2RS client and the network applications is outside the scope of 461 I2RS. 463 When an I2RS Client interacts with multiple network applications, 464 that I2RS Client is behaving as a go-between and should indicate this 465 to the I2RS Agents by, for example, specifying a secondary opaque 466 identity to allow improved troubleshooting. 468 A network application that uses an I2RS client may also be considered 469 a routing element and include an I2RS agent for interactions. 470 However, where the needed information and data models for that upper 471 interface differs from that of a conventional routing element, those 472 models are, at least initially, out of scope for I2RS. 474 4.1. Example Network Application: Topology Manager 476 One example of such an application is a Topology Manager. A Topology 477 Manager includes an I2RS client that uses the I2RS data models and 478 protocol to collect information about the state of the network by 479 communicating directly with one or more I2RS agents. From these I2RS 480 agents, the Topology Manager collects routing configuration and 481 operational data. Most importantly, it collects information about 482 the routing system, including the contents of the IGP (e.g., IS-IS or 483 OSPF) and BGP data sets. 485 The Topology Manager may be embedded as a component of a larger 486 application. It would construct internal data structures and use the 487 collected data to drive functions such as path computations or 488 anomalous routing detection. Alternatively, the Topology Manager 489 could combine the I2RS-collected data with other information, 490 abstract a composite set, and provide a coherent picture of the 491 network state accessible via another interface. That interface might 492 use the same I2RS protocol and could use extensions to the I2RS data 493 models. Developing such mechanisms is outside the initial scope of 494 the I2RS work. 496 5. I2RS Agent Role and Functionality 498 The I2RS Agent is part of a routing element. As such, it has 499 relationships with that routing element as a whole, and with various 500 components of that routing element. 502 5.1. Relationship to its Routing Element 504 A Routing Element may be implemented with a wide variety of different 505 architectures: an integrated router, a split architecture, 506 distributed architecture, etc. The architecture does not need to 507 affect the general I2RS agent behavior. 509 For scalability and generality, the I2RS agent may be responsible for 510 collecting and delivering large amounts of data from various parts of 511 the routing element. Those parts may or may not actually be part of 512 a single physical device. Thus, for scalability and robustness, it 513 is important that the architecture allow for a distributed set of 514 reporting components providing collected data from the I2RS agent 515 back to the relevant I2RS clients. As currently envisioned, a given 516 I2RS agent would have only one locus per I2RS service for 517 manipulation of routing element state. 519 5.2. State Storage 521 State modification requests are sent to the I2RS agent in a network 522 element by I2RS clients. The I2RS agent is responsible for applying 523 these changes to the system. How much data must the I2RS Agent store 524 about these state-modifying operations, and with what persistence? 525 There are range of possible answers. One extreme is where it stores 526 nothing, cannot indicate why or by whom state was placed into the 527 routing element, and relies on clients reapplying things in all 528 possible cases. The other extreme is where multiple clients' 529 overlapping operations are stored and managed, as is done in the RIB 530 for routes with a preference or priority to pick between the routes. 532 In answering this question, this architecture tries to provide 533 sufficient power to keep client operations effective, while still 534 being simple to implement in the I2RS Agent, and to observe 535 meaningfully during operation. The I2RS agent stores the set of 536 operations it has applied. Simply, the I2RS agent stores who did 537 what operation to which entity. New changes replace any data about 538 old ones. If an I2RS client does an operation to remove some state, 539 that state is removed and the I2RS agent stores no more information 540 about it. This allows any interested party to determine what the 541 current effect of I2RS on the system is, and why. Meaningful logging 542 is also recommended. 544 The I2RS Agent will not attempt to retain or reapply state across 545 routing element reboot. Determination of whether state still applies 546 depends heavily on the causes of reboots, and reapplication is at 547 least as likely to cause problems as it is to provide for correct 548 operation. [[Editor's note: This topics needs more discussion in the 549 working group.]] 551 5.2.1. Starting and Ending 553 An I2RS client applies changes via the I2RS protocol based on policy 554 and other application inputs. While these changes may be of the form 555 "do this now, and leave it there forever", they are frequently driven 556 by other conditions which may have start times, stop times, or are 557 only to be used under certain conditions. The I2RS interface 558 protocol could be designed to allow an I2RS Client to provide a wide 559 range of such conditional information to the I2RS Agent for 560 application. At the other extreme, the I2RS client could provide all 561 such functionality based on its own clocking and network event 562 reporting from the relevant I2RS Agents. 564 Given that the complexity of possible conditions is very large, and 565 that some conditions may even cross network element boundaries, 566 clearly some degree of handling must be provided on the I2RS client. 567 As such, in this architecture it is assumed that all the complexity 568 associated with this should be left to the I2RS client. This 569 architectural view does mean that reliability of the communication 570 path between the I2RS client and I2RS agent is critical. [[Editor's 571 note: This requires more discussion in the working group.]] 573 5.2.2. Reversion 575 An I2RS Agent may decide that some state should no longer be applied. 576 An I2RS Client may instruct an Agent to remove state it has applied. 577 In all such cases, the state will revert to what it would have been 578 without the I2RS; that state is generally whatever was specified via 579 the CLI, NETCONF, SNMP, etc. I2RS Agents will not store multiple 580 alternative states, nor try to determine which one among such a 581 plurality it should fall back to. Thus, the model followed is not 582 like the RIB, where multiple routes are stored at different 583 preferences. 585 An I2RS Client may register for notifications when state that was 586 applied by a particular I2RS Client is modified or removed. 588 5.3. Interactions with Local Config 590 As described above, local device configuration is considered to be 591 separate from the I2RS data store. Thus, changes may originate from 592 either source. Policy (i.e. comparisons between a CLI/SNMP/NETCONF 593 priority and a I2RS agent priority) can determine whether the local 594 configuration should overwrite any state written by I2RS and 595 attributed to a particular I2RS Client or whether I2RS as attributed 596 to a particular I2RS Client can overwrite local configuration state. 598 Simply allowing the most recent state to prevail could cause race 599 conditions where the final state is not repeatably deterministic. 600 One important aspect is that if CLI/SNMP/NETCONF changes data that is 601 subject to monitoring or manipulating by I2RS, then the system must 602 be instrumented enough to provide suitable I2RS notifications of 603 these changes. 605 5.4. Routing Components and Associated I2RS Services 606 For simplicity, each logical protocol or set of functionality that be 607 compactly described in a separable information and data model is 608 considered as a separate I2RS Service. A routing element need not 609 implement all routing components described nor provide the associated 610 I2RS services. The initial services included in the I2RS 611 architecture are as follows. 613 5.4.1. Unicast and Multicast RIB and LFIB 615 Network elements concerned with routing IP maintain IP unicast RIBs. 616 Similarly, there are RIBs for IP Multicast, and a Label Information 617 Base (LIB) for MPLS. The I2RS Agent needs to be able to read and 618 write these sets of data. The I2RS data model must include models 619 for this information. 621 In particular, with regard to writing this information, the I2RS 622 Agent should use the same mechanisms that the routing element already 623 uses to handle RIB input from multiple sources, so as to compatibly 624 change the system state. 626 The multicast state added to the multicast RIB does not need to match 627 to well-known protocol installed state. The I2RS Agent can create 628 arbitrary replication state in the RIB, subject to the advertised 629 capabilities of the routing element. 631 5.4.2. IGPs, BGP and Multicast Protocols 633 In addition to interacting with the consolidated RIB, the I2RS agent 634 may need to interact with the individual routing protocols on the 635 device. This interaction includes a number of different kinds of 636 operations: 638 o reading the various internal rib(s) of the routing protocol is 639 often helpful for understanding the state of the network. 640 Directly writing these protocol-specific RIBs or databases is out 641 of scope for I2RS. 643 o reading the various pieces of policy information the particular 644 protocol instance is using to drive its operations. 646 o writing policy information such as interface attributes that are 647 specific to the routing protocol or BGP policy that may indirectly 648 manipulate attributes of routes carried in BGP. 650 o writing routes or prefixes to be advertised via the protocol. 652 o joining/removing interfaces from the multicast trees 653 o subscribing to an information stream of route changes 655 o receiving notifications about peers coming up or going down 657 For example, the interaction with OSPF might include modifying the 658 local routing element's link metrics, announcing a locally-attached 659 prefix, or reading some of the OSPF link-state database. However, 660 direct modification of of the link-state database is NOT allowed to 661 preserve network state consistency. 663 5.4.3. MPLS 665 The I2RS agent will need to interact with the protocols that create 666 transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP, 667 LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, 668 L2VPNs, etc). 670 5.4.4. Policy and QoS Mechanisms 672 Many network elements have separate policy and QoS mechanisms, 673 including knobs which affect local path computation and queue control 674 capabilities. These capabilities vary widely across implementations, 675 and I2RS cannot model the full range of information collection or 676 manipulation of these attributes. A core set does need to be 677 included in the I2RS data models and in the expected interfaces 678 between the I2RS Agent and the network element, in order to provide 679 basic capabilities and the hooks for future extensibility. 680 [[Editor's note: This requires more discussion in the working 681 group.]] 683 6. I2RS Client Agent Interface 685 6.1. Protocol Structure 687 One could view I2RS merely as a way to talk about the existing 688 network management interfaces to a network element. That would be 689 quite limiting and would not meet the requirements elucidated 690 elsewhere. One could also view I2RS as a collection of protocols - 691 some existing and some new - that meet the needs. While that could 692 be made to work, the complexity of such a mechanism would be quite 693 high. One would need to develop means to coordinate information 694 across a set of protocols that were not designed to work together. 695 From a deployability perspective, this would not meet the goal of 696 simplicity. As a result, this architecture views the I2RS as an 697 interface supporting a single control and data exchange protocol. 698 Whether such a protocol is built upon extending existing mechanisms 699 or requires a new mechanism requires further investigation. That 700 protocol may use several underlying transports (TCP, SCTP, DCCP), 701 with suitable authentication and integrity protection mechanisms. 702 These different transports can support different types of 703 communication (e.g. control, reading, notifications, and information 704 collection) and different sets of data. Whatever transport is used 705 for the data exchange, it must also support suitable congestion 706 control mechanisms. 708 6.2. Channel 710 The uses of a single I2RS protocol does not imply that only one 711 channel of communication is required. There may be a range of 712 reliability requirements, and to support the scaling there may need 713 to be channels originating from multiple sub-components of a routing 714 element. These will all use the date exchange protocol, and 715 establishment of additional channels for communication will be 716 coordinated between the I2RS client and the I2RS agent. 718 6.3. Negotiation 720 Protocol support capabilities will vary across I2RS Clients and 721 Routing Elements supporting I2RS Agents. As such, capability 722 negotiation (such as which transports are supported beyond the 723 minimum required to implement) will clearly be necessary. It is 724 important that such negotiations be kept simple and robust, as such 725 mechanisms are often a source of difficulty in implementation and 726 deployment. 728 Negotiation should be broken into several aspects, such as protocol 729 capablities and I2RS services and model types supported. 731 6.4. Identity and Security Role 733 Each I2RS Client will have a unique identity; it can also have 734 secondary identities to be used for troubleshooting. A secondary 735 identity is merely a unique, opaque identifier that may be helpful in 736 troubleshooting. Via authentication and authorization mechanisms, 737 the I2RS agent will have a specific scope for reading data, for 738 writing data, and limitations on the resources that can be consumed. 739 The scopes need to specify both the data and the value ranges. 741 6.4.1. Client Redundancy 743 I2RS must support client redundancy. At the simplest, this can be 744 handled by having a primary and a backup network application that 745 both use the same client identity and can successfully authenticate 746 as such. Since I2RS does not require a continuous transport 747 connection and supports multiple transport sessions, this can provide 748 some basic redundancy. However, it does not address concerns for 749 troubleshooting and accountability about knowing which network 750 application is actually active. At a minimum, basic transport 751 information about each connection and time can be logged with the 752 identity. Further discussion is necessary to determine whether 753 additional client identification information is necessary.[[Editor's 754 note: This requires more discussion in the working group.]] 756 6.5. Connectivity 758 A client may or may not maintain an active communication channel with 759 an agent. Therefore, an agent may need to open a communication 760 channel to the client to communicate previously requested 761 information. The lack of an active communication channel does not 762 imply that the associated client is non-functional. When 763 communication is required, the agent or client can open a new 764 communication channel. 766 State held by an agent that is owned by a client should not be 767 removed or cleaned up when a client is no longer communicating - even 768 if the agent cannot successfully open a new communication channel to 769 the client. 771 There are three different assumptions that can apply to handling dead 772 clients. The first is that the network applications or management 773 systems will detect a dead network application and either restart 774 that network application or clean up any state left behind. The 775 second is to allow state expiration, expressed as a policy associated 776 with the I2RS client's role. The state expiration could occur after 777 there has been no successful communication channel to or from the 778 I2RS client for the policy-specified duration. The third is that the 779 client could explicitly request state clean-up if a particular 780 transport session is terminated. 782 6.6. Notifications 784 As with any policy system interacting with the network, the I2RS 785 Agent needs to be able to receive notifications of changes in network 786 state. Notifications here refers to changes which are unanticipated, 787 represent events outside the control of the systems (such as 788 interface failures on controlled devices), or are sufficiently sparse 789 as to be anomalous in some fashion. 791 Such events may be of interest to multiple I2RS Clients controlling 792 data handled by an I2RS Agent, and to multiple other I2RS clients 793 which are collecting information without exerting control. The 794 architecture therefore requires that it be practical for I2RS Clients 795 to register for a range of notifications, and for the I2R Agents to 796 send notifications to a number of Clients. 798 As the I2RS is developed, it is likely that a management information- 799 model and data-model will be required to describe event notifications 800 for general or I2RS errors. 802 For performance and scaling by the I2RS client and general 803 information privacy, an I2RS Client needs to be able to register for 804 just the events it is interested in. It is also possible that I2RS 805 might might provide a stream of notifications via a publish/subscribe 806 mechanism that is not amenable to having the I2RS agent do the 807 filtering. 809 6.7. Information collection 811 One of the other important aspects of the I2RS is that it is intended 812 to simplify collecting information about the state of network 813 elements. This includes both getting a snapshot of a large amount of 814 data about the current state of the network element, and subscribing 815 to a feed of the ongoing changes to the set of data or a subset 816 thereof. This is considered architecturally separate from 817 notifications due to the differences in information rate and total 818 volume. 820 6.8. Multi-Headed Control 822 As was described earlier, an I2RS Agent interacts with multiple I2RS 823 Clients who are actively controlling the network element. From an 824 architecture and design perspective, the assumption is that by means 825 outside of this system the data to be manipulated within the network 826 element is appropriately partitioned so that any given piece of 827 information is only being manipulated by a single I2RS Client. 829 Nonetheless, unexpected interactions happen and two (or more) I2RS 830 clients may attempt to manipulate the same piece of data. This is 831 considered an error case. This architecture does not attempt to 832 determine what the right state of data is in such a collision Rather, 833 the architecture mandates that there be decidable means by which I2RS 834 Agents will handle the collisions. The current recommendation is to 835 have a simple priority associated with each I2RS clients, and the 836 highest priority change remains in effect. In the case of priority 837 ties, the first client whose attribution is associated with the data 838 will keep control 840 In order for this to be useful for I2RS Clients, it is important that 841 it be possible for an I2RS Client to register for changes to any I2RS 842 manipulatable data that it may care about. The I2RS client may then 843 respond to the situation as it sees fit. 845 6.9. Transactions 847 In the interest of simplicity, the I2RS architecture does not include 848 multi-message atomicity and rollback mechanisms. Rather, it includes 849 a small range of error handling for a set of operations included in a 850 single message. An I2RS Client may indicate one of the following 851 three error handling for a given message with multiple operations 852 which it sends to an I2RS Agent: 854 Perform all or none: This traditional SNMP semantic indicates that 855 other I2RS agent will keep enough state when handling a single 856 message to roll back the operations within that message. Either 857 all the operations will succeed, or none of them will be applied 858 and an error message will report the single failure which caused 859 the not to be applied. This is useful when there are, for 860 example, mutual dependencies across operations in the message. 862 Perform until error: In this case, the operations in the message 863 are applied in the specified order. When an error occurs, no 864 further operations are applied, and an error is returned 865 indicating the failure. This is useful if there are dependencies 866 among the operations and they can be topologically sorted. 868 Perform all storing errors: In this case, the I2RS Agent will 869 attempt to perform all the operations in the message, and will 870 return error indications for each one that fails. This is useful 871 when there is no dependency across the operation, or where the 872 client would prefer to sort out the effect of errors on its own. 874 In the interest of robustness and clarity of protocol state, the 875 protocol will include an explicit reply to modification operations 876 even when they fully succeed. 878 7. Manageability Considerations 880 Manageability plays a key aspect in I2RS. Some initial examples 881 include: 883 Resource Limitations: Using I2RS, applications can consume 884 resources, whether those be operations in a time-frame, entries in 885 the RIB, stored operations to be triggered, etc. The ability to 886 set resource limits based upon authorization is important. 888 Configuration Interactions: The interaction of state installed via 889 the I2RS and via a router's configuration needs to be clearly 890 defined. As described in this architecture, a simple priority 891 that is configured can be used to express the desired policy. 893 8. Security Considerations 895 This framework describes interfaces that clearly require serious 896 consideration of security. The ability to identify, authenticate and 897 authorize applications that wish to install state is necessary and 898 briefly described in Section 3.4. Security of communications from 899 the applications is also required as discussed in Section 6.1. 900 Scopes for reading and writing data specified in the context of the 901 data models and the value ranges are discussed briefly in 902 Section 6.4. 904 9. IANA Considerations 906 This document includes no request to IANA. 908 10. Acknowledgements 910 Significant portions of this draft came from draft-ward-i2rs- 911 framework-00 and draft-atlas-i2rs-policy-framework-00. 913 The authors would like to thank Nitin Bahadur, Shane Amante, Ed 914 Crabbe, Ken Gray, Carlos Pignataro, Wes George, Joe Clarke, Juergen 915 Schoenwalder, and Jamal Hadi Salim for their suggestions and review. 917 11. Informative References 919 [I-D.atlas-i2rs-problem-statement] 920 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 921 Routing System Problem Statement", draft-atlas-i2rs- 922 problem-statement-01 (work in progress), July 2013. 924 Authors' Addresses 926 Alia Atlas 927 Juniper Networks 928 10 Technology Park Drive 929 Westford, MA 01886 930 USA 932 Email: akatlas@juniper.net 934 Joel Halpern 935 Ericsson 937 Email: Joel.Halpern@ericsson.com 938 Susan Hares 939 ADARA 941 Email: shares@ndzh.com 943 Dave Ward 944 Cisco Systems 945 Tasman Drive 946 San Jose, CA 95134 947 USA 949 Email: wardd@cisco.com 951 Thomas D. Nadeau 952 Juniper Networks 954 Email: tnadeau@juniper.net