idnits 2.17.1 draft-atlas-i2rs-policy-framework-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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-atlas-i2rs-policy-framework-01', but the file name used is 'draft-atlas-i2rs-policy-framework-00' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4078 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 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 S. Hares 5 Expires: August 29, 2013 Hickory Hill Consulting 6 J. Halpern 7 Ericsson 8 February 25, 2013 10 A Policy Framework for the Interface to the Routing System 11 draft-atlas-i2rs-policy-framework-01 13 Abstract 15 A key aspect of the Interface to the Routing System (I2RS) is what 16 mechanisms it includes to carry policy information and to enable 17 policy control. This applies both in the protocol itself and in the 18 services associated with the different components of the routing 19 system. Similarly, the data-models associated with the services must 20 be capable of expressing the appropriate granularity for access and 21 authorization-related policy. This document describes the policy 22 framework for I2RS. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 29, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. General I2RS Policy . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Use-Case of Overlapping Interactions . . . . . . . . . . . 6 62 3.2. Policy between client and agent . . . . . . . . . . . . . 6 63 3.2.1. Identity . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.2. Security Role . . . . . . . . . . . . . . . . . . . . 7 65 3.2.3. Security Model . . . . . . . . . . . . . . . . . . . . 8 66 3.2.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.2.5. Resources . . . . . . . . . . . . . . . . . . . . . . 9 68 3.2.6. Connectivity . . . . . . . . . . . . . . . . . . . . . 10 69 3.2.7. Priority . . . . . . . . . . . . . . . . . . . . . . . 10 70 3.2.8. Precedence . . . . . . . . . . . . . . . . . . . . . . 11 71 3.3. Policy between Agent and Local System . . . . . . . . . . 14 72 3.3.1. Local Configuration . . . . . . . . . . . . . . . . . 15 73 3.3.2. Removal of I2RS-installed State . . . . . . . . . . . 16 74 3.3.3. On Reboot . . . . . . . . . . . . . . . . . . . . . . 16 75 4. Policy in an I2RS Service . . . . . . . . . . . . . . . . . . 17 76 4.1. Resource Reservation and Three-Phase Commit . . . . . . . 17 77 4.2. Defining I2RS Behavior Based on Implicit and Explicit 78 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 4.2.1. Example of Implicit Policy . . . . . . . . . . . . . . 18 80 4.2.2. Passing Explicit Policy . . . . . . . . . . . . . . . 19 81 4.2.2.1. Explicit policy on Data Forwarding, Resources, 82 and Policy passing . . . . . . . . . . . . . . . . 19 83 4.2.2.2. Example of Explicit Policy . . . . . . . . . . . . 19 84 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 8. Informative References . . . . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 The Interface to the Routing System (I2RS) provides read and write 93 access to the information and state that enable the routing 94 components of routing elements. The I2RS is introduced and described 95 in [I-D.atlas-irs-problem-statement] and [I-D.ward-irs-framework]. 97 Policy helps provide filters and control on the access to information 98 and state that is enabled by individual protocol interactions. A 99 clear view of the policy features desirable at the I2RS is important 100 to shape the architecture and requirements for the protocols and 101 services of the I2RS. Policy can be explicitly defined or implicitly 102 assumed in a system, and can be enforced by that system's rules and 103 behavior. Since I2RS provides services to routing sub-systems that 104 already have policy defined (implicitly or explicitly), it is 105 important to consider the existing policy mechanisms and how an I2RS 106 services should interact with them. 108 I2RS policy has four different aspects that need to be considered. 110 1. Policy related to the I2RS protocol interactions between 111 different systems. 113 2. Policy related to the interaction between the I2RS Agent and the 114 local system to which the I2RS Agent is providing an interface. 116 3. Service policy to support scope and influence restrictions and to 117 preserve necessary policy associated with the related routing 118 sub-system. 120 4. Policy that can be installed or read via a service's data-model 121 that is associated with the related routing sub-system. 123 2. Terminology 125 The following terminology is used in this document. 127 agent or I2RS Agent: An I2RS agent provides the supported I2RS 128 services to the local system's routing sub-systems. The I2RS 129 agent understands the I2RS protocol and can be contacted by I2RS 130 clients. 132 client or I2RS Client: A client speaks the I2RS protocol to 133 communicate with I2RS Agents and uses the I2RS services to 134 accomplish a task as instructed by the client's local application. 135 An I2RS client can be seen as the part of an application that 136 supports I2RS and could be a software library. 138 service or I2RS Service: For the purposes of I2RS, a service refers 139 to a set of related state access functions together with the 140 policies that control its usage. For instance, 'RIB service' 141 could be an example of a service that gives access to state held 142 in a device's RIB. 144 read scope: The set of information which the particular I2RS entity 145 (agent or client) is authorized to read. This access includes the 146 permission to see the existence of data and the ability to 147 retrieve the value of that data. In the context of an interaction 148 between a client and an agent, the effective read scope is 149 restricted to the intersection of the read scopes of the two 150 entities. 152 write scope: The set of field values which the particular I2RS 153 entity (agent or client) is authorized to write (i.e. add, modify 154 or delete). This access can restrict what fields can be modified 155 or created, and what specific value sets and ranges can be 156 installed. In the context of an interaction between a client and 157 an agent, the effective write scope is restricted to the 158 intersection of the write scopes of the two entities. 160 scope: When unspecified as either read scope or write scope, the 161 term scope applies to both the read scope and write scope. 163 resources: A resource is an I2RS-specific use of memory, storage, 164 or execution that a client may consume due to its I2RS operations. 165 The amount of each such resource that a client may consume in the 166 context of a particular agent can be constrained. Examples of 167 such resources could include: the number of installed operations, 168 number of operations that haven't reached their start-time, etc. 169 These are not protocol-specific resources or network-specific 170 resources. 172 role or security role: A security role specifies the scope, 173 resources, precedences, etc. that a client or agent has. 175 identity: A client is associated with exactly one specific 176 identity. State installed by a particular identity is owned by 177 that identity; state ownership can not be transferred. It is 178 possible for multiple communication channels to use the same 179 identity; in that case, the assumption is that the associated 180 client is coordinating such communication. Similarly, an agent is 181 associated with a specific identity. 183 3. General I2RS Policy 185 I2RS needs its own implicit and explicit policy. This section 186 articulates some of the those key concepts and policy decisions. The 187 I2RS policy applies to interactions between the agent and clients and 188 between the agent and the local system. 190 The agent's externally perceivable behavior and associated policy is 191 a key aspect of I2RS that must be described. The client's behavior 192 and functionality is specifically out-of-scope except where it needs 193 to be described with respect to the agent's behavior and the I2RS 194 protocol. 196 *********************** *********************** 197 * Application A * * Application B * 198 * * * * 199 * +----------------+ * * +----------------+ * 200 * | Client A | * * | Client B | * 201 * +----------------+ * * +----------------+ * 202 ******* ^ ************* ***** ^ ****** ^ ****** 203 | | | 204 | -----------------------| | 205 | | | 206 ******* v ***** v ********* ************** v ******** 207 * +----------------+ * * +----------------+ * 208 * | Agent 1 | * * | Agent 2 | * 209 * +----------------+ * * +----------------+ * 210 * ^ ^ * * ^ ^ * 211 * | | * * | | * 212 * v v * * v v * 213 * *********** ********** * * *********** ********* * 214 * * Routing * * Local * * * * Routing * * Local * * 215 * *********** * Config * * * *********** * Config* * 216 * ********** * * ********* * 217 * * * * 218 * Routing Element 1 * * Routing Element 2 * 219 *************************** ************************* 221 Figure 1: Architecture of clients and agents 223 As can be seen in Figure 1, a client can communicate with multiple 224 agents. The application associated with a client may have multiple 225 tasks it is accomplishing (separate functions, short-term versus 226 longer-term, etc) and each such task may involve a set of agents 227 which may or may not differ. 229 As can also be seen in Figure 1, an I2RS Agent may communicate with 230 multiple clients. Each client may send the agent a variety of write 231 operations. The set of write operations received by an agent may 232 overlap and conflict. No simple protocol or policy mechanisms by an 233 agent can completely avoid indirect interactions between different 234 install operations. The functional partitioning between the 235 different clients must be done to avoid undesirable indirect 236 interactions. 238 3.1. Use-Case of Overlapping Interactions 240 An I2RS Agent can receive overlapping operations from multiple 241 clients. An example is when there are two applications: 243 Client A: Special Flow Router: Client A is part of an application 244 that explicitly routes particular special flows using policy-based 245 routing (aka ACLs). 247 Client B: DDoS Detection and Mitigation: Client B is part of an 248 application that looks for flows that appear to be part of a DDoS 249 attack and explicitly routes them to mitigate the attack. Client 250 B also uses policy-based routing (aka ACLs). 252 If Client B is told to explicitly route prefix X, because it looks 253 suspicious, and Client A is also explicitly routing prefix X, then 254 the I2RS Agent must determine what to do based upon policy. Even 255 though intelligent functional partitioning has been done, this is an 256 example where the I2RS agent must still make an arbitration decision. 257 This document defines precedence as the policy mechanism by which the 258 I2RS agent can be instructed what to do in such cases. 260 3.2. Policy between client and agent 262 Multiple clients can communicate with the same agent. The agent must 263 have policies to manage the resulting complexity. Implicit policy 264 includes the assumptions about communication between the client and 265 agent. Explicit policy includes mechanisms to arbitrate between 266 different clients, between operations of the same client, and to 267 manage state owned by an client inside the agent. 269 Any easy way to look at the i2rs policies is that the policies answer 270 who, what, and how. 272 Who: The first type of policies concern identity, secure roles, and 273 security model for connecting. The same is true of any secured 274 connect between two hosts where each host has an identity, a secured 275 role in the communication and security model on who can connect. 277 What: The second set of policies look at secure model on what data 278 can be examined, the scope of the read or writes, and the amount of 279 resources an active i2rs agent can consume. A security model defines 280 the barriers for the i2rs activity. 282 How: The third set of policies involve how the i2rs agent and i2rs 283 client communication, and how they mitigate the natural contention of 284 allowing an i2rs client to talk to multiple i2rs agents or an i2rs 285 agent to communicate with multiple clients. For example, a single 286 i2rs client connected to several i2rs agents (i2rs agent J and i2rs 287 agent K) may learn of an interface overload (on i2rs agent J), and 288 then want to reprioritize activities on i2rs agent K to find another 289 data path. This is priority policy. In the same way, the two i2rs 290 Clients (A and B) may try to install a RIB route on i2rs agent K. If 291 there are overlapping actions, policy needs to determine who wins. 293 3.2.1. Identity 295 By definition, a client is associated with exactly one identity. An 296 agent will store data that is owned by a particular client, based 297 upon that client's identity. Since a client can communicate via 298 multiple transport channels and no channel needs to be active for the 299 agent to have associated state, the client's identity is used to 300 identify the ownership of the data stored by the agent. 302 Similarly, by definition, an agent is associated with exactly one 303 identity. A client may also store local state associated with a 304 particular agent. The agent's identity can be used to identify 305 ownership of the data stored by the client. 307 The details of what constitutes an identity can be dependent upon the 308 specifics of the I2RS protocol and selected security mechanisms. 309 However, there are some critical considerations for identity that do 310 impose constraints. 312 An identity is not tied to a single communication channel. A client 313 may use multiple IP addresses; an identity should not be tied to a 314 specific IP address. If the client or agent is associated with a 315 system that may be mobile, that should be considered in its 316 identification. Finally, the syntax and semantics for identifiers 317 used for a client and for an agent may be different. 319 3.2.2. Security Role 321 In the context of an agent, each client will have a security role. 322 The client's identity and associated security role will have to be 323 verified via an acceptable security mechanism. A variety of such 324 mechanisms are anticipated to meet different security and operational 325 objectives. Example mechanisms might include a role assertion from 326 the client to the agent that the agent can cryptographically verify 327 or having the agent to use an already trusted protocol to verify the 328 client's security role and identity. 330 An agent must know the scope and resources associated with each 331 particular security role. This information may vary across different 332 agents even in the same network or it may be consistent across 333 different agents in the same network. The latter can be enforced by 334 having a client that is authorized to influence the meta-data model 335 of security roles on the relevant set of agents. 337 A security role also defines what precedences (See Section 3.2.8) a 338 commissioner can use. 340 3.2.3. Security Model 342 As described above, roles identify the scope and resources allowed to 343 an I2RS Client. The policy model therefore needs to include these 344 roles. The question of the bindings of identities to roles, and the 345 selection of identities are protocol specific matters outside the 346 scope of this document. 348 The policy model for roles needs to address these two dimensions. It 349 needs to create the roles themselves. This should allow for use of 350 techniques like inheritance, presumably with some rules on how role 351 definitions can augment or restrict the inherited definitions. 353 The security model also needs to define, by reference to the policy 354 model itself, the scope of the role. The question of defining the 355 resources of a role is for further study. The role definition needs 356 to indicate what types and instances of data can be observed and what 357 information about those instances entities with that role can 358 observe. The security model also needs to define which data items 359 can be modified, and what modifications (ranges, specified values, or 360 other assertions that must be met) are permitted. 362 3.2.4. Scope 364 Scope is specified as part of a security role. A security role may 365 be defined and managed in an external repository, centralized within 366 an administration. The security role definitions must be accessible 367 to an agent. 369 In the context of an interaction between a client and an agent, the 370 effective scope is restricted to the intersection of the scopes of 371 the two entities. 373 What information a particular client is authorized to read is known 374 as the clien's read scope. A read scope includes the ability to see 375 that particular data exists and to read the same data. The read 376 scope can have its constraints specified in terms of specific 377 portions of data models. 379 Similarly, what information a client can write (add/modify/delete) 380 may be contrained. This is known as its write scope. The write 381 scope is specific in both the parts of the data models and in the set 382 and range of data that can be written. For example, a client might 383 be able to write static routes in the RIB data-model for prefixes in 384 10.0/16. 386 While the client's behavior and functionality is specifically out-of- 387 scope, it is useful to describe the same scope concepts for an agent 388 operating in the context of a client. 390 An agent's read scope is the set of data that the agent can read or 391 have access to. An agent would generally learn such data because the 392 client has sent that data to the agent in an operation. 394 An agent's write scope is the set and range of data that the agent is 395 allowed to provide to the client and that will be accepted by the 396 client. For instance, client B may accept next-hop change 397 notifications for prefix 10.0/16 from agent 1 but not from agent 2. 399 3.2.5. Resources 401 When a client sends operations to an agent, those operations can 402 consume resources. Therefore, it is important that the agent have 403 policy to limit the resources available to a particular client. This 404 is based on the client's identity and security role. Such resource 405 policy specifications need to be provided in a data-model that can be 406 modified by appropriately authorized clients or local configuration. 408 Examples of such resource constraints include: 410 Number of installed operations owned, 412 Number of operations that haven't reached their start-time, and 414 Number of event notifications registered for. 416 As discussed in Section 3.2.7, a client can specify priorities for 417 the operations it sends. 419 If compute resources are considered, it is not the intent to try and 420 determine the computation associated with particular operations. 422 Instead, the constraint could be on percentage of the I2RS agent's 423 compute-time given to a client every pre-defined period. This could 424 provide a mechanism for fair sharing of compute resources between 425 clients. 427 3.2.6. Connectivity 429 A client does not need to maintain an active communication channel 430 with an agent. Therefore, an agent may need to open a communication 431 channel to the client to communicate previously requested 432 information. The lack of an active communication channel does not 433 imply that the associated client is non-functional. When 434 communication is required, the agent or client can open a new 435 communication channel. 437 State held by an agent that is owned by a client should not be 438 removed or cleaned up when a client is no longer communicating - even 439 if the agent cannot successfully open a new communication channel to 440 the client. 442 3.2.7. Priority 444 The motivating example for priority is when a single client is 445 sending operations to accomplish multiple tasks. For example, one 446 task might be long-term and another task might deal with unexpected 447 requests that are more important. In this case, the client may wish 448 to provide a hint to the relevant agents as to which operations 449 should be done first. 451 Communication from a client can come across multiple channels, so 452 simply specifying that operations be done in order is not sufficient. 453 Additionally, all operations may not be immediately carried out, due 454 to varying start-times or other constraints. With these factors and 455 this motivating example, it is useful to introduce the concept of 456 prioritization for operations sent from the same client. 458 By introducing the concept of priority for operations, a client can 459 accomplish multiple uncorrelated tasks that affect the same agent 460 with the specified prioritization. 462 A default priority can be specified for each particular communication 463 channel. In addition, an I2RS operation can specify a priority to 464 use instead. Priorities between operations from different clients 465 need not be compared. 467 The priority can be used by an agent to determine which operation 468 from a client to execute next. 470 3.2.8. Precedence 472 A mechanism is needed for the agent to determine what state to 473 install when there are overlapping install operations. An install 474 operation may overlap with locally-installed configuration state or 475 with a previous install operation that was requested by a client. 476 The mechanism to resolve this is termed "precedence". No simple 477 mechanism can fully handle indirect interactions; considering such 478 interactions is out-of-scope. Indirect interactions must be 479 considered when different clients are given their tasks. 481 Precedence is a TLV; there is a precedence type and a precedence 482 value that can vary based upon the precedence type. The different 483 precedence types are ordered with regard to another so that, for 484 instance, a precedence type of "Simple Integer" is preferred to 485 precedence type of "mouse-type". If more than one operation has the 486 same precedence type, then the precedence values are compared based 487 upon the rules for the associated type. If multiple clients have 488 equivalent precedence (based both on type and compared values), then 489 preference is given to the newer operation that is being written. 490 This tie-breaking policy is equivalent to that used by CLI or 491 NetConf, where the new command or RPC gets to do its add/modify/ 492 delete operation. The different precedence types are ordered with 493 regard to each other; the lowest precedence type will be preferred. 494 If there is a tie for precedence type, then the precedence values 495 will be compared and the preferred will be selected based on the 496 precedence type's policy. 498 Option A: Type 100 ("Simple Integer") Value 10. 500 Option B: Type 200 (mouse-type) Value "cheese" 502 Option C: Type 100 ("Simple Integer") Value 10 504 Option D: Type 100 ("Simple Integer") Value 8 506 If Operation A arrived first and installed state, then when the I2RS 507 agent decides whether to install Operation B, Operation B would be 508 rejected or stored because A's type 100 is better than B's type 200. 509 If Operation C were to arrive, however, then Operation C would be 510 installed and Operation A preempted because A and C have the same 511 type and value, so tie-breaking is done to prefer the new arrival. 512 If Operation D were to arrive with A installed, then D would be 513 rejected or stored because A and D share the same type but D's value 514 of 8 is less than A's value of 10. 516 Given that clients are dynamically sending write operations and the 517 associated arrival times can vary based on anything from program 518 state to network conditions, predictability is much better provided 519 by using precedence instead of operation arrival time or start time 520 many operations may be immediate start). 522 Each write operation has a precedence associated with it. This 523 precedence may come from the default associated with the clientw, 524 with the specific communication channel, or with the specific 525 operation. The range of possible precedences that can be used is 526 known based on the client's security role. The determination of the 527 precedence associated with any operation is a policy decision at the 528 agent, but may utilize any or all of the information described above. 530 When a write operation is executed, the agent first determines if 531 there is overlapping existing I2RS-installed state. If not, the 532 agent must determine if it overlaps existing local-configuration 533 state. Local-configuration state will also have a precedence 534 associated with it so that the agent can make an appropriate 535 decision. 537 A client can specify whether a write operation should be store-if- 538 not-best. This allows a client to determine what happens when a 539 write operation doesn't win the precedence comparison. If store-if- 540 not-best is specified, then the write operation succeeds and the 541 associated installed state is stored but not actively installed by 542 the agent. If store-if-not-best is not specified, then the install 543 operation will fail. 545 The store-if-not-best flag is stored with the installed operation's 546 precedence. If the agent determines that an installed operation must 547 be preempted, then the agent consults the store-if-not-best flag. If 548 store-if-not-best is specified, then the agent stores the preempted 549 operation and does not notify the associated client. If store-if- 550 not-best is not specified, then the agent notifies the associated 551 client of the preemption and removes the previously installed state. 553 /----------\ NO |------------| 554 / Overlap? \________\| Install as | 555 \ / /| I2RS state | 556 \----------/ |------------| 557 | 558 | YES 559 V 560 /-----------------\ YES /------------\ YES |----------------| 561 / New Precedence \_______\/ Old store-if \_____\| Store old I2RS | 562 \ better than Old? / /\ -not-best? / /|----------------| 563 \-----------------/ \------------/ | 564 | | | 565 | | NO | 566 | V V 567 | |------------------| |-------------| 568 | | Send Preempt |___\| Install new | 569 | NO | Notification to | /| I2RS state | 570 | | Old Client | |-------------| 571 | |------------------| 572 V 573 /-------------\ YES /----------\ NO /-----------\ NO 574 / New precedence\____\ / same \___\ / new store- \___ 575 \ equal to old / / \ Client / / \ if-best on? / | 576 \-------------/ \----------/ \-----------/ | 577 | NO |YES YES | V 578 | | | |---------------| 579 | | | | Send a reject | 580 | V | | to new Client | 581 | |-------------------| | |---------------| 582 | | Install new State | | 583 | |-------------------| V 584 | |----------------| 585 V | Save new State | 586 /-------------\ NO |------------------| |----------------| 587 / New store-if \____\| Send Preempt | 588 \ -not-best? / /| Notification to | 589 \-------------/ | New Client and | 590 | | forget new I2RS | 591 | | state | 592 | Yes |------------------| 593 V 594 |----------------------| 595 | store new I2RS state | 596 |----------------------| 598 Figure 2: Precedence Decision-Making 600 If the overlapping new operation has a precedence that is better than 601 the existing state, then the agent should preempt the existing state 602 and act according to the existing state's store-if-not-best flag. If 603 that store-if-not-best flag is set, the agent will store the old 604 state and install the new state. If the store-if-not-best flag is 605 clear, the agent will send a preemption notification to the old 606 client, install the new I2RS state, and forget the old. 608 If the overlapping existing state has the same precedence and the 609 same client associated, then the agent completes the write operation; 610 otherwise, the agent must reject or store the write operation, based 611 on the store-if-not-best flag. 613 If the new overlapping operation has a precedence that is worse than 614 the existing state, then the agent must reject or store the write 615 operation, based on the state of the new store-if-not-best flag. If 616 the store-if-not-best flag is set, then then the agent will store the 617 new I2RS state. If the store-if-not-best flag is clear, then the the 618 I2RS agent will send a preempt notification to the new client and 619 forget the new I2RS state. 621 This decision process is illustrated in Figure 2. 623 When a delete operation is done, the stored state with the next best 624 precedence should be selected and installed. 626 A consequence of the precedence policy mechanism is that a client 627 must be able to handle its installed operations being preempted at 628 any time, either explicitly or simply by having the active state 629 changed. Such preemption can be minimized by appropriate separation 630 of tasks, with their associated write operations, between the local 631 systems of the clients and by knowledgeable local system 632 configuration. 634 3.3. Policy between Agent and Local System 636 It is critical to understand and clearly specify how I2RS interacts 637 with local configuration. The key questions are: 639 1. What happens when Local Configuration overlaps with I2RS 640 installed state? 642 2. What happens when I2RS installed state is removed? 644 3. How is state recreated when a local system reboots? 646 A consequence of using I2RS is that the local system's state may not 647 be synchronized with the local configuration. Since this is a change 648 in understood behavior, any discrepancies should be clearly visible 649 to the operator with an associated explanation. 651 Logically, the local configuration is essentially modeled as a local 652 client, with its own precedence, identity, and security role and 653 immediate permanent write operations. The key differences are both 654 that all relevant local configuration state need not be cached by the 655 agent and that reboot imposes the need to process local configuration 656 state before any other I2RS-installed state. 658 3.3.1. Local Configuration 660 The local system's local configuration may have overlapping write 661 scope with that of one or more clients using an agent. Therefore, 662 explicit and implicit policy interactions must be specified. The 663 mechanism that I2RS provides for deciding between overlapping install 664 operations is "precedence". This same mechanism can be used to 665 decide between local configuration and an I2RS operation. Local 666 configuration can specify the precedence to be used for the local 667 system. 669 A precedence that causes the desired behavior can be specified as 670 follows. (MAX is the highest precedence given to a client. MIN is 671 the lowest precedence given to a client.) 673 MAX+1 Precedence: If the local configuration has a precedence 674 higher than that given to any client, then state from the local 675 configuration will always be installed. If any I2RS-installed 676 state is therefore preempted, the agent will notify the associated 677 client. 679 MIN-1 Precedence: If the local configuration has a precedence 680 lower than that given to any client, then I2RS-installed state 681 will always override local configuration. That this preemption 682 has occurred should be reflected in how the local system displays 683 its state. 685 Other Precedence: The local configuration can have higher 686 precedence than that given to some clients, lower precedence than 687 that given to other clients, and equal precedence to that given to 688 other clients. Then some local configuration state may be 689 preempted by I2RS-installed state while some I2RS-installed state 690 can be preempted by local configuration. 692 Local-configuration wins all precedence ties. 694 Just as an agent must check to determine if a write operation 695 overlaps with existing installed state, the process of committing 696 local configuration must check to see if there is overlapping I2RS- 697 installed state. 699 What the process of committing local configuration is can vary by 700 local system. Well known examples are when a return is sent to the 701 CLI and when an explicit commit command is specified. How the proper 702 checks for interaction between the agent and local configuration are 703 done is a local system matter. 705 Similarly, when an agent checks to see if an write operation overlaps 706 with existing installed state, the agent must determine if it 707 overlaps with existing local configuration. 709 If the precedence associated with local configuration is changed, 710 then it is retroactive. All local configuration state stored by the 711 agent must be updated with the new precedence and installation 712 decisions made for overlapping data. This change could be very 713 disruptive. 715 3.3.2. Removal of I2RS-installed State 717 When a piece of local configuration is removed, the local system goes 718 back to the appropriate system default. However, when an operation 719 deletes some I2RS-installed state, the correct behavior is not to 720 just go back to the system default. Instead, any stored state must 721 be considered - whether that comes from local configuration or stored 722 I2RS write operations that didn't have the highest precedence. If 723 there is any stored state, then the highest precedence of the options 724 is selected and installed. That existing overlapping state might 725 come from the local-configuration. 727 If I2RS's implicit policy were to just go to the system default, then 728 the local configuration and the local system state would not be 729 synchronized and there would be no remaining I2RS-state to explain 730 the discrepency. Since I2RS state can also be stored and not 731 installed, the same mechanism can be used for stored I2RS install 732 operations and for local configuration. 734 3.3.3. On Reboot 736 When the local system reboots, only persistent I2RS-installed state 737 is preserved by the agent. The implicit policy for I2RS is that the 738 local configuration is read and installed first. After the local 739 system has its local configuration installed, the persistent I2RS 740 write operations are executed to bring the system to the persistent 741 state. 743 4. Policy in an I2RS Service 745 It is critical to consider how policy influences a service when 746 defining the service and its associated data-model(s). There are 747 several different aspects to consider. 749 How are scope and influence policy specified in the data model? 750 What granularity levels are necessary for the particular service? 752 How does the implicit policy in the associated routing sub-system 753 effect what I2RS can be allowed to influence? 755 Are the implicit policies of the associated routing sub-system 756 captured in the semantic content of the information model, data 757 model, and description? 759 What explicit policy communicated in the associated routing sub- 760 system needs to be included in the data-model? What indirection 761 and abstractions are needed? 763 4.1. Resource Reservation and Three-Phase Commit 765 Some agents and services may offer the ability to reserve resources 766 required by operations before the operation start time. There are 767 two aspects to how to support this. 769 First, if the agent can do time-aware resource reservation, then a 770 write operation can specify "reserve-only" to prompt an 771 acknowledgement or failure as to the ability of the agent to confirm 772 the reservation. Then the client can either send an operation to 773 commit the reservation, which causes the associated write operation, 774 or to remove the reservation. A "reserve-only" operation will have 775 its reservation expire at the end of its associated life-time. 777 Second, part of a service's data-model may be to request a 778 reservation with a known start-time and duration. An example might 779 be reserving a specific bandwidth on a path for an LSP between two 780 devices. It is important to consider whether a particular service 781 should offer a time-based reservation service as part of its data- 782 model. 784 4.2. Defining I2RS Behavior Based on Implicit and Explicit Policy 786 The semantics in a data-model must respect and describe the implicit 787 policy of the associated routing sub-system. This doesn't imply that 788 the data-model components should instantiate it or allow reading or 789 writing. 791 Policy Routing systems must deal with the verification, reading and 792 installing of routes from sources such as EGP, IGP, and static 793 routes. Policy routing may also control forwarding and the 794 monitoring of data forwarding; and data resources. The explicit 795 policy examples are given for the routing framework. It is assumed 796 the reader can extend this framework to the data forwarding and data 797 resource arena. 799 4.2.1. Example of Implicit Policy 801 The ISIS protocol specification uses implicit policy to set 802 constraints on level 1 peers. Due to this fact, many ISIS 803 implementations only let one level 1 ISIS peer associate with one 804 Level 2 peer domain. 806 This policy is not encoded in any local configuration directly, but 807 is rather included as an implicit policy. When local configuration 808 policy is checked (prior to a configuration commit), this local 809 policy is checked. If the configuration input from a CLI is in 810 error, the input will be rejected, and the CLI will warn the user. 811 Similarily programmic interfaces for the local configuration cause 812 the implicit policy to be checked. 814 I2RS data models guide the client in an interoperable interaction 815 with the reading and installation of data at a particular agent. The 816 I2RS data models must contain both the implicit policy and the 817 explicit policy. Although an agent may not report the I2RS implicit 818 policy in the protocol, the client must know of the existence of the 819 implicit policy. 821 This knowledge allows the client to know the implicit policy 822 interactions on different systems in a heterogeneous network. For 823 example, assume a situation where a client is talking to two agents - 824 one on system A and one on system B. The routing process on system A 825 has has different implicit rules for the ISIS Level 1 peer to Level 2 826 peer connection than the routing process on system B. Routing process 827 A is built to allow one level 1 ISIS peer associated with 2 ISIS 828 Level 2 peers. Routing process B upholds the standard implicit 829 policy that 1 level ISIS peer can only be associated with 1 ISIS 830 Level 2 peer. The client setting up the ISIS peering in a network 831 containing system A and system B must know that System A will allow a 832 level 1 peer to connect to 2 ISIS Level 2 peers. When the client's 833 scope allows it to read data from system A and system B, it should 834 not flag the difference in ISIS level 1 peer connections as a 835 problem. Instead the client will need to determine if the use of the 836 different configurations can cause a network problem. 838 4.2.2. Passing Explicit Policy 840 Routing systems' explicit policy controls protocols, associates/ 841 deassociates interfaces, route verification policy, route forwarding 842 policy, route aggregation policy, and route deaggregation policy. 843 All of this policy can be found in the detailed configuration 844 specification of a routing process. However, even via CLI, it is 845 rarely possible to configure all the possible options. Other 846 configuration mechanisms do not have public models for all the 847 private router configuration. The developers of a routing system 848 often have a complete policy model either in formal modeling 849 languages or informal language. 851 Explicit policy contained in an I2RS data model is the detailed 852 configuration model at the deepest level that an agent can access. 853 This detailed configuration model may come from IETF Standards and/or 854 the vendor specific configurations. The public data models must 855 specify a vendor specific tree where the individual configuration is 856 plugged into. 858 4.2.2.1. Explicit policy on Data Forwarding, Resources, and Policy 859 passing 861 Forwarding policy has to do with the data flow may also be controlled 862 by an agent. If so, the explicit policy must be placed in a data 863 model along with the implicit policy. 865 Lastly, protocols have begun to pass explicit policy about passing 866 policy. Examples of this type of policy are BGP ORFs, BGP Flowspecs, 867 and ISIS policy passing. Clients must know the implicit policy and 868 explicit policy this policy impacts, and the precedence between these 869 policy. Due to the extensive use of BGP ORFs and the growing use in 870 BGP Flowspecs policy, early data models for BGP should describe the 871 implicit policy, explicit policy, policy precedence for the BGP ORFS 872 and BGP FlowSpecs, and how they interacts with other BGP, route 873 policy and preferences. This information should be placed inside an 874 I2RS data model for an agent supporting these features. 876 These explicit models for BGP policy are not trivial, but these 877 models exist today. Frequently, I2RS data models may be simply a 878 casting of existing implicit policy and explicit policy into a common 879 standard form so that programmic interfaces may interact with a 880 routing element. 882 4.2.2.2. Example of Explicit Policy 884 There are two clear explicit policy pieces for ISIS. First is the 885 peer level. Second is the policy of the external routes to be 886 redistributed into and out of ISIS. 888 5. Acknowledgements 890 The authors would like to thank Ross Callon, Adrian Farrel, David 891 Meyer, David Ward, Rex Fernando, Russ White, Bruno Risjman, and 892 Thomas Nadeau for their suggestions and review. 894 6. IANA Considerations 896 This document includes no request to IANA. 898 7. Security Considerations 900 This is empty boilerplate for now. 902 8. Informative References 904 [I-D.atlas-irs-problem-statement] 905 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 906 Routing System Problem Statement", 907 draft-atlas-irs-problem-statement-00 (work in progress), 908 July 2012. 910 [I-D.ward-irs-framework] 911 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 912 Routing System Framework", draft-ward-irs-framework-00 913 (work in progress), July 2012. 915 Authors' Addresses 917 Alia Atlas 918 Juniper Networks 919 10 Technology Park Drive 920 Westford, MA 01886 921 USA 923 Email: akatlas@juniper.net 924 Susan Hares 925 Hickory Hill Consulting 927 Email: shares@ndzh.com 929 Joel Halpern 930 Ericsson 932 Email: Joel.Halpern@ericsson.com