idnits 2.17.1 draft-atlas-i2rs-architecture-02.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 431: '...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 13, 2013) is 3908 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 14, 2014 Ericsson 6 S. Hares 7 ADARA 8 D. Ward 9 Cisco Systems 10 T. Nadeau 11 Juniper Networks 12 August 13, 2013 14 An Architecture for the Interface to the Routing System 15 draft-atlas-i2rs-architecture-02 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 14, 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 . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 6.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 16 85 6.4. Identity and Security Role . . . . . . . . . . . . . . . 16 86 6.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 16 87 6.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 16 88 6.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 17 89 6.7. Information collection . . . . . . . . . . . . . . . . . 18 90 6.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 18 91 6.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 18 92 7. Manageability Considerations . . . . . . . . . . . . . . . . 19 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 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 * *********** | * Config * * * *********** | * Config* * 203 * | ********** * * | ********* * 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: This block represents that portion of the Routing Element 236 that implements part of the Internet routing system. It includes 237 not merely standardized protocols (i.e. IS-IS, OSPF, BGP, PIM, 238 RSVP-TE, LDP, etc.), but also the RIB Manager layer. 240 Local Config: A Routing Element will provide the ability to 241 configure and manage it. The Local Config may be provided via a 242 combination of CLI, NETCONF, SNMP, etc. The black box behavior 243 for interactions between the state that I2RS installs into the 244 routing element and the Local Config must be defined. 246 Dynamic System State: An I2RS agent needs access to state on a 247 routing element beyond what is contained in the routing subsystem. 248 Such state may include various counters, statistics, and local 249 events. How this information is provided to the I2RS agent is out 250 of scope, but the standardized information and data models for 251 what is exposed are part of I2RS. 253 I2RS Agent: The I2RS agent implements the I2RS protocol(s) and 254 interacts with the routing element to provide specified behavior. 256 Application: A network application that needs to manipulate the 257 network to achieve its service requirements. 259 I2RS Client: The I2RS client implements the I2RS protocol(s). It 260 interacts with other elements of the policy, provisioning, and 261 configuration system by means outside of the scope of the I2RS 262 effort. It interacts with the I2RS agents to collect information 263 from the routing and forwarding system. Based on the information 264 and the policy oriented interactions, the I2RS client may also 265 interact with the I2RS agent to modify the state of the routing 266 system the client interacts with to achieve operational goals. 268 As can be seen in Figure 1, an I2RS client can communicate with 269 multiple I2RS agents. An I2RS client may connect to one or more I2RS 270 agents based upon its needs. Similarly, an I2RS agent may 271 communicate with multiple I2RS clients - whether to respond to their 272 requests, to send notifications, etc. Timely notifications are 273 critical so that several simultaneously operating applications have 274 up-to-date information on the state of the network. 276 As can also be seen in Figure 1, an I2RS Agent may communicate with 277 multiple clients. Each client may send the agent a variety of write 278 operations. The handling of this situation has been a source of 279 discussion in the working group. In order to keep the protocol 280 simple, the current view is that two clients should not be attempting 281 to write (modify) the same piece of information. Such collisions may 282 happen, but are considered error cases that should be resolved by the 283 network applications and management systems. 285 Multiple I2RS clients may need to supply data into the same list 286 (e.g. a prefix or filter list); this is not considered an error and 287 must be correctly handled. The nuances so that writers do not 288 normally collide should be handled in the information models. 290 The architectural goal for the I2RS is that such errors should 291 produce predictable behaviors, and be reportable to interested 292 clients. The details of the associated policy is discussed in 293 Section 6.8. The same policy mechanism (simple priority per I2RS 294 client) applies to interactions between the I2RS agent and the CLI/ 295 SNMP/NETCONF as described in Section 5.3. 297 In addition it must be noted that there may be indirect interactions 298 between write operations. Detection and avoidance of such 299 interactions is outside the scope of the I2RS work and is left to 300 agent design and implementation for now. [[Editor's note: This topic 301 needs more discussion in the working group.]] 303 2. Terminology 305 The following terminology is used in this document. 307 agent or I2RS Agent: An I2RS agent provides the supported I2RS 308 services to the local system's routing sub-systems. The I2RS 309 agent understands the I2RS protocol and can be contacted by I2RS 310 clients. 312 client or I2RS Client: A client speaks the I2RS protocol to 313 communicate with I2RS Agents and uses the I2RS services to 314 accomplish a task. An I2RS client can be seen as the part of an 315 application that uses and supports I2RS and could be a software 316 library. 318 service or I2RS Service: For the purposes of I2RS, a service refers 319 to a set of related state access functions together with the 320 policies that control their usage. The expectation is that a 321 service will be represented by a data-model. For instance, 'RIB 322 service' could be an example of a service that gives access to 323 state held in a device's RIB. 325 read scope: The set of information which the I2RS client is 326 authorized to read. This access includes the permission to see 327 the existence of data and the ability to retrieve the value of 328 that data. 330 write scope: The set of field values which the I2RS client is 331 authorized to write (i.e. add, modify or delete). This access can 332 restrict what data can be modified or created, and what specific 333 value sets and ranges can be installed. 335 scope: When unspecified as either read scope or write scope, the 336 term scope applies to both the read scope and write scope. 338 resources: A resource is an I2RS-specific use of memory, storage, 339 or execution that a client may consume due to its I2RS operations. 340 The amount of each such resource that a client may consume in the 341 context of a particular agent can be constrained based upon the 342 client's security role. An example of such a resource could 343 include the number of notifications registered for. These are not 344 protocol-specific resources or network-specific resources. 346 role or security role: A security role specifies the scope, 347 resources, priorities, etc. that a client or agent has. 349 identity: A client is associated with exactly one specific 350 identity. State can be attributed to a particular identity. It 351 is possible for multiple communication channels to use the same 352 identity; in that case, the assumption is that the associated 353 client is coordinating such communication. 355 secondary identity: An I2RS Client may supply a secondary opaque 356 identity that is not interpreted by the I2RS Agent. An example 357 use is when the I2RS Client is a go-between for multiple 358 applications and it is necessary to track which application has 359 requested a particular operation. 361 3. Key Architectural Properties 363 3.1. Simplicity 365 There have been many efforts over the years to improve the access to 366 the information known to the routing and forwarding system. Making 367 such information visible and usable to network management and 368 applications has many well-understood benefits. There are two 369 related challenges in doing so. First, the span of information 370 potentially available is very large. Second, the variation both in 371 the structure of the data and in the kinds of operations required 372 tends to introduce protocol complexity. 374 Having noted that, it is also critical to the utility of I2RS that it 375 be easily deployed and robust. Complexity in the protocol hinders 376 implementation, robustness, and deployability. Also, complexity in 377 the data models frequently makes it harder to extend rather than 378 easier. 380 Thus, one of the key aims for I2RS is the keep the protocol and 381 modeling architecture simple. So for each architectural component or 382 aspect, we ask ourselves "do we need this complexity, or is the 383 behavior merely nice to have?" Protocol parsimony is clearly a goal. 385 3.2. Extensibility 387 There are several ways that the scope of the I2RS work is being 388 restricted in the interests of achieving a deliverable and deployable 389 result. We are only working on the models to be used over the single 390 identified interface. We are only looking at modeling a subset of 391 the data of interest. And we are probably only representing a subset 392 of the operations that may eventually be needed (although there is 393 some hope that we are closer on that aspect than others to what is 394 needed.) Thus, it is important to consider extensibility not only of 395 the underlying services' data models, but also of the primitives and 396 protocol operations. 398 At the same time, it is clearly desirable for the data models and 399 protocol operations we define in the I2RS to be useful the in more 400 general settings. It should be easy to integrate data models from 401 the I2RS with other data. Other work should be able to easily extend 402 it to represent additional aspects of the network elements or network 403 systems. Hence, the data model and protocol definitions need to be 404 designed to be highly extensible, preferably in a regular and simple 405 fashion. 407 3.3. Model-Driven Programmatic Interfaces 409 A critical component of I2RS is the standard information and data 410 models with their associated semantics. While many components of the 411 routing system are standardized, associated data models for them are 412 not yet available. Instead, each router uses different information, 413 different mechanisms, and different CLI which makes a standard 414 interface for use by applications extremely cumbersome to develop and 415 maintain. Well-known data modeling languages exist and may be used 416 for defining the data models for I2RS. 418 There are several key benefits for I2RS in using model-driven 419 architecture and protocol(s). First, it allows for transferring 420 data-models whose content is not explicitly implemented or 421 understood. Second, tools can automate checking and manipulating 422 data; this is particularly valuable for both extensibility and for 423 the ability to easily manipulate and check proprietary data-models. 425 The different services provided by I2RS can correspond to separate 426 data-models. An I2RS agent may indicate which data-models are 427 supported. 429 3.4. Authorization and Authentication 431 All control exchanges between the I2RS client and agent MUST be 432 authenticated and integrity protected (such that the contents cannot 433 be changed without detection). Manipulation of the system must be 434 accurately attributable. In an ideal architecture, even information 435 collection and notification should be protected; this may be subject 436 to engineering tradeoffs during the design. 438 I2RS Agents, in performing information collection and manipulation, 439 will be acting on behalf of the I2RS clients. As such, they will 440 operate based on the lower of the two permissions of the agent itself 441 and of the client. 443 I2RS clients may be operating on behalf of other applications. While 444 those applications' identities are not need for authorization, each 445 application should have a unique opaque identifier that can be 446 provided by the I2RS client to the I2RS agent for purposes of 447 tracking attribution of operations to support functionality such as 448 accounting and troubleshooting. 450 4. Network Applications and I2RS Client 452 An I2RS Client has a standardized interface that uses the I2RS 453 protocol(s) to communicate with I2RS Agents. The interface between 454 an I2RS client and the network applications is outside the scope of 455 I2RS. 457 When an I2RS Client interacts with multiple network applications, 458 that I2RS Client is behaving as a go-between and should indicate this 459 to the I2RS Agents by, for example, specifying a secondary opaque 460 identity to allow improved troubleshooting. 462 A network application that uses an I2RS client may also be considered 463 a routing element and include an I2RS agent for interactions. 464 However, where the needed information and data models for that upper 465 interface differs from that of a conventional routing element, those 466 models are, at least initially, out of scope for I2RS. 468 4.1. Example Network Application: Topology Manager 469 One example of such an application is a Topology Manager. A Topology 470 Manager includes an I2RS client that uses the I2RS data models and 471 protocol to collect information about the state of the network by 472 communicating directly with one or more I2RS agents. From these I2RS 473 agents, the Topology Manager collects routing configuration and 474 operational data. Most importantly, it collects information about 475 the routing system, including the contents of the IGP (e.g., IS-IS or 476 OSPF) and BGP data sets. 478 The Topology Manager may be embedded as a component of a larger 479 application. It would construct internal data structures and use the 480 collected data to drive functions such as path computations or 481 anomalous routing detection. Alternatively, the Topology Manager 482 could combine the I2RS-collected data with other information, 483 abstract a composite set, and provide a coherent picture of the 484 network state accessible via another interface. That interface might 485 use the same I2RS protocol and could use extensions to the I2RS data 486 models. Developing such mechanisms is outside the initial scope of 487 the I2RS work. 489 5. I2RS Agent Role and Functionality 491 The I2RS Agent is part of a routing element. As such, it has 492 relationships with that routing element as a whole, and with various 493 components of that routing element. 495 5.1. Relationship to its Routing Element 497 A Routing Element may be implemented with a wide variety of different 498 architectures: an integrated router, a split architecture, 499 distributed architecture, etc. The architecture does not need to 500 affect the general I2RS agent behavior. 502 For scalability and generality, the I2RS agent may be responsible for 503 collecting and delivering large amounts of data from various parts of 504 the routing element. Those parts may or may not actually be part of 505 a single physical device. Thus, for scalability and robustness, it 506 is important that the architecture allow for a distributed set of 507 reporting components providing collected data from the I2RS agent 508 back to the relevant I2RS clients. As currently envisioned, a given 509 I2RS agent would have only one locus per I2RS service for 510 manipulation of routing element state. 512 5.2. State Storage 514 State modification requests are sent to the I2RS agent in a network 515 element by I2RS clients. The I2RS agent is responsible for applying 516 these changes to the system. How much data must the I2RS Agent store 517 about these state-modifying operations, and with what persistence? 518 There are range of possible answers. One extreme is where it stores 519 nothing, cannot indicate why or by whom state was placed into the 520 routing element, and relies on clients reapplying things in all 521 possible cases. The other extreme is where multiple clients' 522 overlapping operations are stored and managed, as is done in the RIB 523 for routes with a preference or priority to pick between the routes. 525 In answering this question, this architecture tries to provide 526 sufficient power to keep client operations effective, while still 527 being simple to implement in the I2RS Agent, and to observe 528 meaningfully during operation. The I2RS agent stores the set of 529 operations it has applied. Simply, the I2RS agent stores who did 530 what operation to which entity. New changes replace any data about 531 old ones. If an I2RS client does an operation to remove some state, 532 that state is removed and the I2RS agent stores no more information 533 about it. This allows any interested party to determine what the 534 current effect of I2RS on the system is, and why. Meaningful logging 535 is also recommended. 537 The I2RS Agent will not attempt to retain or reapply state across 538 routing element reboot. Determination of whether state still applies 539 depends heavily on the causes of reboots, and reapplication is at 540 least as likely to cause problems as it is to provide for correct 541 operation. [[Editor's note: This topics needs more discussion in the 542 working group.]] 544 5.2.1. Starting and Ending 546 An I2RS client applies changes via the I2RS protocol based on policy 547 and other application inputs. While these changes may be of the form 548 "do this now, and leave it there forever", they are frequently driven 549 by other conditions which may have start times, stop times, or are 550 only to be used under certain conditions. The I2RS interface 551 protocol could be designed to allow an I2RS Client to provide a wide 552 range of such conditional information to the I2RS Agent for 553 application. At the other extreme, the I2RS client could provide all 554 such functionality based on its own clocking and network event 555 reporting from the relevant I2RS Agents. 557 Given that the complexity of possible conditions is very large, and 558 that some conditions may even cross network element boundaries, 559 clearly some degree of handling must be provided on the I2RS client. 561 As such, in this architecture it is assumed that all the complexity 562 associated with this should be left to the I2RS client. This 563 architectural view does mean that reliability of the communication 564 path between the I2RS client and I2RS agent is critical. [[Editor's 565 note: This requires more discussion in the working group.]] 567 5.2.2. Reversion 569 An I2RS Agent may decide that some state should no longer be applied. 570 An I2RS Client may instruct an Agent to remove state it has applied. 571 In all such cases, the state will revert to what it would have been 572 without the I2RS; that state is generally whatever was specified via 573 the CLI, NETCONF, SNMP, etc. I2RS Agents will not store multiple 574 alternative states, nor try to determine which one among such a 575 plurality it should fall back to. Thus, the model followed is not 576 like the RIB, where multiple routes are stored at different 577 preferences. 579 An I2RS Client may register for notifications when state that was 580 applied by a particular I2RS Client is modified or removed. 582 5.3. Interactions with Local Config 584 As described above, local device configuration is considered to be 585 separate from the I2RS data store. Thus, changes may originate from 586 either source. Policy (i.e. comparisons between a CLI/SNMP/NETCONF 587 priority and a I2RS agent priority) can determine whether the local 588 configuration should overwrite any state written by I2RS and 589 attributed to a particular I2RS Client or whether I2RS as attributed 590 to a particular I2RS Client can overwrite local configuration state. 592 Simply allowing the most recent state to prevail could cause race 593 conditions where the final state is not repeatably deterministic. 594 One important aspect is that if CLI/SNMP/NETCONF changes data that is 595 subject to monitoring or manipulating by I2RS, then the system must 596 be instrumented enough to provide suitable I2RS notifications of 597 these changes. 599 5.4. Routing Components and Associated I2RS Services 601 For simplicity, each logical protocol or set of functionality that be 602 compactly described in a separable information and data model is 603 considered as a separate I2RS Service. A routing element need not 604 implement all routing components described nor provide the associated 605 I2RS services. The initial services included in the I2RS 606 architecture are as follows. 608 5.4.1. Unicast and Multicast RIB and LFIB 610 Network elements concerned with routing IP maintain IP unicast RIBs. 611 Similarly, there are RIBs for IP Multicast, and a Label Information 612 Base (LIB) for MPLS. The I2RS Agent needs to be able to read and 613 write these sets of data. The I2RS data model must include models 614 for this information. 616 In particular, with regard to writing this information, the I2RS 617 Agent should use the same mechanisms that the routing element already 618 uses to handle RIB input from multiple sources, so as to compatibly 619 change the system state. 621 The multicast state added to the multicast RIB does not need to match 622 to well-known protocol installed state. The I2RS Agent can create 623 arbitrary replication state in the RIB, subject to the advertised 624 capabilities of the routing element. 626 5.4.2. IGPs, BGP and Multicast Protocols 628 In addition to interacting with the consolidated RIB, the I2RS agent 629 may need to interact with the individual routing protocols on the 630 device. This interaction includes a number of different kinds of 631 operations: 633 o reading the various internal rib(s) of the routing protocol is 634 often helpful for understanding the state of the network. 635 Directly writing these protocol-specific RIBs or databases is out 636 of scope for I2RS. 638 o reading the various pieces of policy information the particular 639 protocol instance is using to drive its operations. 641 o writing policy information such as interface attributes that are 642 specific to the routing protocol or BGP policy that may indirectly 643 manipulate attributes of routes carried in BGP. 645 o writing routes or prefixes to be advertised via the protocol. 647 o joining/removing interfaces from the multicast trees 649 For example, the interaction with OSPF might include modifying the 650 local routing element's link metrics, announcing a locally-attached 651 prefix, or reading some of the OSPF link-state database. However, 652 direct modification of of the link-state database is NOT allowed to 653 preserve network state consistency. 655 5.4.3. MPLS 657 The I2RS agent will need to interact with the protocols that create 658 transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP, 659 LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, 660 L2VPNs, etc). 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. 672 [[Editor's note: This requires more discussion in the working 673 group.]] 675 6. I2RS Client Agent Interface 677 6.1. Protocol Structure 679 One could view I2RS merely as a way to talk about the existing 680 network management interfaces to a network element. That would be 681 quite limiting and would not meet the requirements elucidated 682 elsewhere. One could also view I2RS as a collection of protocols - 683 some existing and some new - that meet the needs. While that could 684 be made to work, the complexity of such a mechanism would be quite 685 high. One would need to develop means to coordinate information 686 across a set of protocols that were not designed to work together. 687 From a deployability perspective, this would not meet the goal of 688 simplicity. As a result, this architecture views the I2RS as an 689 interface supporting a single control and data exchange protocol. 690 Whether such a protocol is built upon extending existing mechanisms 691 or requires a new mechanism requires further investigation. That 692 protocol may use several underlying transports (TCP, SCTP, DCCP), 693 with suitable authentication and integrity protection mechanisms. 694 These different transports can support different types of 695 communication (e.g. control, reading, notifications, and information 696 collection) and different sets of data. Whatever transport is used 697 for the data exchange, it must also support suitable congestion 698 control mechanisms. 700 6.2. Channel 701 The uses of a single I2RS protocol does not imply that only one 702 channel of communication is required. There may be a range of 703 reliability requirements, and to support the scaling there may need 704 to be channels originating from multiple sub-components of a routing 705 element. These will all use the date exchange protocol, and 706 establishment of additional channels for communication will be 707 coordinated between the I2RS client and the I2RS agent. 709 6.3. Negotiation 711 Protocol support capabilities will vary across I2RS Clients and 712 Routing Elements supporting I2RS Agents. As such, capability 713 negotiation (such as which transports are supported beyond the 714 minimum required to implement) will clearly be necessary. It is 715 important that such negotiations be kept simple and robust, as such 716 mechanisms are often a source of difficulty in implementation and 717 deployment. 719 Negotiation should be broken into several aspects, such as protocol 720 capablities and I2RS services and model types supported. 722 6.4. Identity and Security Role 724 Each I2RS Client will have a unique identity; it can also have 725 secondary identities to be used for troubleshooting. A secondary 726 identity is merely a unique, opaque identifier that may be helpful in 727 troubleshooting. Via authentication and authorization mechanisms, 728 the I2RS agent will have a specific scope for reading data, for 729 writing data, and limitations on the resources that can be consumed. 730 The scopes need to specify both the data and the value ranges. 732 6.4.1. Client Redundancy 734 I2RS must support client redundancy. At the simplest, this can be 735 handled by having a primary and a backup network application that 736 both use the same client identity and can successfully authenticate 737 as such. Since I2RS does not require a continuous transport 738 connection and supports multiple transport sessions, this can provide 739 some basic redundancy. However, it does not address concerns for 740 troubleshooting and accountability about knowing which network 741 application is actually active. At a minimum, basic transport 742 information about each connection and time can be logged with the 743 identity. Further discussion is necessary to determine whether 744 additional client identification information is necessary.[[Editor's 745 note: This requires more discussion in the working group.]] 747 6.5. Connectivity 748 A client may or may not maintain an active communication channel with 749 an agent. Therefore, an agent may need to open a communication 750 channel to the client to communicate previously requested 751 information. The lack of an active communication channel does not 752 imply that the associated client is non-functional. When 753 communication is required, the agent or client can open a new 754 communication channel. 756 State held by an agent that is owned by a client should not be 757 removed or cleaned up when a client is no longer communicating - even 758 if the agent cannot successfully open a new communication channel to 759 the client. 761 There are three different assumptions that can apply to handling dead 762 clients. The first is that the network applications or management 763 systems will detect a dead network application and either restart 764 that network application or clean up any state left behind. The 765 second is to allow state expiration, expressed as a policy associated 766 with the I2RS client's role. The state expiration could occur after 767 there has been no successful communication channel to or from the 768 I2RS client for the policy-specified duration. The third is that the 769 client could explicitly request state clean-up if a particular 770 transport session is terminated. 772 6.6. Notifications 774 As with any policy system interacting with the network, the I2RS 775 Agent needs to be able to receive notifications of changes in network 776 state. Notifications here refers to changes which are unanticipated, 777 represent events outside the control of the systems (such as 778 interface failures on controlled devices), or are sufficiently sparse 779 as to be anomalous in some fashion. 781 Such events may be of interest to multiple I2RS Clients controlling 782 data handled by an I2RS Agent, and to multiple other I2RS clients 783 which are collecting information without exerting control. The 784 architecture therefore requires that it be practical for I2RS Clients 785 to register for a range of notifications, and for the I2R Agents to 786 send notifications to a number of Clients. 788 As the I2RS is developed, it is likely that a management information- 789 model and data-model will be required to describe event notifications 790 for general or I2RS errors. 792 For performance and scaling by the I2RS client and general 793 information privacy, an I2RS Client needs to be able to register for 794 just the events it is interested in. It is also possible that I2RS 795 might might provide a stream of notifications via a publish/subscribe 796 mechanism that is not amenable to having the I2RS agent do the 797 filtering. 799 6.7. Information collection 801 One of the other important aspects of the I2RS is that it is intended 802 to simplify collecting information about the state of network 803 elements. This includes both getting a snapshot of a large amount of 804 data about the current state of the network element, and subscribing 805 to a feed of the ongoing changes to the set of data or a subset 806 thereof. This is considered architecturally separate from 807 notifications due to the differences in information rate and total 808 volume. 810 6.8. Multi-Headed Control 812 As was described earlier, an I2RS Agent interacts with multiple I2RS 813 Clients who are actively controlling the network element. From an 814 architecture and design perspective, the assumption is that by means 815 outside of this system the data to be manipulated within the network 816 element is appropriately partitioned so that any given piece of 817 information is only being manipulated by a single I2RS Client. 819 Nonetheless, unexpected interactions happen and two (or more) I2RS 820 clients may attempt to manipulate the same piece of data. This is 821 considered an error case. This architecture does not attempt to 822 determine what the right state of data is in such a collision Rather, 823 the architecture mandates that there be decidable means by which I2RS 824 Agents will handle the collisions. The current recommendation is to 825 have a simple priority associated with each I2RS clients, and the 826 highest priority change remains in effect. In the case of priority 827 ties, the first client whose attribution is associated with the data 828 will keep control 830 In order for this to be useful for I2RS Clients, it is important that 831 it be possible for an I2RS Client to register for changes to any I2RS 832 manipulatable data that it may care about. The I2RS client may then 833 respond to the situation as it sees fit. 835 6.9. Transactions 837 In the interest of simplicity, the I2RS architecture does not include 838 multi-message atomicity and rollback mechanisms. Rather, it includes 839 a small range of error handling for a set of operations included in a 840 single message. An I2RS Client may indicate one of the following 841 three error handling for a given message with multiple operations 842 which it sends to an I2RS Agent: 844 Perform all or none: This traditional SNMP semantic indicates that 845 other I2RS agent will keep enough state when handling a single 846 message to roll back the operations within that message. Either 847 all the operations will succeed, or none of them will be applied 848 and an error message will report the single failure which caused 849 the not to be applied. This is useful when there are, for 850 example, mutual dependencies across operations in the message. 852 Perform until error: In this case, the operations in the message 853 are applied in the specified order. When an error occurs, no 854 further operations are applied, and an error is returned 855 indicating the failure. This is useful if there are dependencies 856 among the operations and they can be topologically sorted. 858 Perform all storing errors: In this case, the I2RS Agent will 859 attempt to perform all the operations in the message, and will 860 return error indications for each one that fails. This is useful 861 when there is no dependency across the operation, or where the 862 client would prefer to sort out the effect of errors on its own. 864 In the interest of robustness and clarity of protocol state, the 865 protocol will include an explicit reply to modification operations 866 even when they fully succeed. 868 7. Manageability Considerations 870 Manageability plays a key aspect in I2RS. Some initial examples 871 include: 873 Resource Limitations: Using I2RS, applications can consume 874 resources, whether those be operations in a time-frame, entries in 875 the RIB, stored operations to be triggered, etc. The ability to 876 set resource limits based upon authorization is important. 878 Configuration Interactions: The interaction of state installed via 879 the I2RS and via a router's configuration needs to be clearly 880 defined. As described in this architecture, a simple priority 881 that is configured can be used to express the desired policy. 883 8. Security Considerations 884 This framework describes interfaces that clearly require serious 885 consideration of security. The ability to identify, authenticate and 886 authorize applications that wish to install state is necessary and 887 briefly described in Section 3.4. Security of communications from 888 the applications is also required as discussed in Section 6.1. 889 Scopes for reading and writing data specified in the context of the 890 data models and the value ranges are discussed briefly in 891 Section 6.4. 893 9. IANA Considerations 895 This document includes no request to IANA. 897 10. Acknowledgements 899 Significant portions of this draft came from draft-ward-i2rs- 900 framework-00 and draft-atlas-i2rs-policy-framework-00. 902 The authors would like to thank Nitin Bahadur, Shane Amante, Ed 903 Crabbe, Ken Gray, Carlos Pignataro, Wes George, Joe Clarke, Juergen 904 Schoenwalder, and Jamal Hadi Salim for their suggestions and review. 906 11. Informative References 908 [I-D.atlas-i2rs-problem-statement] 909 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 910 Routing System Problem Statement", draft-atlas-i2rs- 911 problem-statement-01 (work in progress), July 2013. 913 Authors' Addresses 915 Alia Atlas 916 Juniper Networks 917 10 Technology Park Drive 918 Westford, MA 01886 919 USA 921 Email: akatlas@juniper.net 923 Joel Halpern 924 Ericsson 926 Email: Joel.Halpern@ericsson.com 927 Susan Hares 928 ADARA 930 Email: shares@ndzh.com 932 Dave Ward 933 Cisco Systems 934 Tasman Drive 935 San Jose, CA 95134 936 USA 938 Email: wardd@cisco.com 940 Thomas D. Nadeau 941 Juniper Networks 943 Email: tnadeau@juniper.net