idnits 2.17.1 draft-hares-i2rs-info-model-policy-03.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 : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1032 has weird spacing: '...s allow local...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o If a router doesn't support policy based routing, a router MUST use rib and MUST not use PIB. -- The document date (July 2, 2014) is 3576 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TCP' is mentioned on line 1030, but not defined == Missing Reference: 'SCTP' is mentioned on line 1030, but not defined == Missing Reference: 'SSL' is mentioned on line 1030, but not defined == Unused Reference: 'I-D.atlas-i2rs-policy-framework' is defined on line 1145, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1183, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 1194, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-hares-i2rs-bgp-im-00 == Outdated reference: A later version (-03) exists of draft-hares-i2rs-info-model-service-topo-00 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-04 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-03 == Outdated reference: A later version (-06) exists of draft-white-i2rs-use-case-05 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group S. Hares 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: January 3, 2015 July 2, 2014 7 An Information Model for Basic Network Policy 8 draft-hares-i2rs-info-model-policy-03 10 Abstract 12 This document contains three information Models: Basic Network Policy 13 (BNP IM), Policy-Based Routing (PBR), I2RS Local-Config (I2RS-LC IM). 14 The I2RRS-LC IM provides both an I2RS store of Policies plus a store 15 of Policy Templates. The BNP IM has the following levels of Policy 16 Hierarchy: Policy Set, Policy Group, Policy Rule, and conditional 17 actions within the policy rule (conditional match and Action). The 18 PBR IM, I2RS LC IM, BGP Information Model (BGP IM), Service Topology 19 Information Model (SF-Topo IM), and the Service Forwarding Chaining 20 IM (SFC IM) utilize and extend the BNP IM. This draft lists the 21 extensions to the BNP IM that support these information models (PBR 22 IM, I2RS LC IM, BGP IM, SSF-Topo IM and SFC-Policy IM). 24 The BNP IM is based on the concept of an extensible information model 25 for representing policies. This concept is also found in the Policy 26 Core Information Model (PCIM) (RFC3060) and the Quality of Service 27 (QoS) Policy Information Model (QPIM)(RFC3644) and policy based 28 routing. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 3, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5 66 3. Basic Network Policy Information Model (BNP IM) . . . . . . . 5 67 3.1. BNP IM Overview . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. The Policy Set . . . . . . . . . . . . . . . . . . . . . 7 69 3.2.1. Policy Set Overview . . . . . . . . . . . . . . . . . 7 70 3.2.2. Policy-Set RBNF . . . . . . . . . . . . . . . . . . . 8 71 3.3. The Policy Group . . . . . . . . . . . . . . . . . . . . 8 72 3.3.1. Policy Group Overview . . . . . . . . . . . . . . . . 8 73 3.3.2. Policy-Group RBNF . . . . . . . . . . . . . . . . . . 10 74 3.4. The Policy Rule . . . . . . . . . . . . . . . . . . . . . 11 75 3.4.1. Policy-Rule Overview . . . . . . . . . . . . . . . . 11 76 3.4.2. Policy-Rule RBNF . . . . . . . . . . . . . . . . . . 12 77 3.5. BNP IM Grammar . . . . . . . . . . . . . . . . . . . . . 16 78 4. The Policy Based Routing Information Model . . . . . . . . . 17 79 4.1. Policy Based Routing Overview . . . . . . . . . . . . . . 17 80 4.2. PBR-RIB definition . . . . . . . . . . . . . . . . . . . 17 81 4.3. PBR Rule Component . . . . . . . . . . . . . . . . . . . 18 82 4.4. PBR QOS RBNF . . . . . . . . . . . . . . . . . . . . . . 19 83 4.5. Relationship between PBR Rule Model and RIB Information 84 Model . . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 4.6. PBR RBNF . . . . . . . . . . . . . . . . . . . . . . . . 21 86 4.7. Remaining PRB Issues . . . . . . . . . . . . . . . . . . 22 87 5. The I2RS Local Policy Information Model . . . . . . . . . . . 23 88 5.1. I2RS Local Policy IM Overview . . . . . . . . . . . . . . 23 89 5.2. I2RS Local Policy IM RBNF . . . . . . . . . . . . . . . . 23 90 6. Extensions to the Policy IM . . . . . . . . . . . . . . . . . 25 91 6.1. Extension to the RIB IM . . . . . . . . . . . . . . . . . 25 92 6.2. Extension from the BGP IM . . . . . . . . . . . . . . . . 25 93 6.3. Extension from SFC Topology IM . . . . . . . . . . . . . 26 94 6.4. Extension from the SFC Traffic Filters . . . . . . . . . 26 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 98 9. Informative References . . . . . . . . . . . . . . . . . . . 26 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 101 1. Introduction 103 The Interface to the Routing System (I2RS) provides read and write 104 access to the information and state within the routing process within 105 routing elements. The I2RS client interacts with one or more I2RS 106 agents to collect information from network routing systems. 108 Processing of collected information at the I2RS agent may require the 109 I2RS Agent to filter certain information or group pieces of 110 information in order to reduce the data flow through the network to 111 the I2RS client. Some applications that that utilize the services of 112 I2RS client may also wish to require specific data in response to 113 network events or conditions based on pre-established rules. This 114 functionality is necessary to meet the requirements of i2rs enabled 115 services which include service-layer routing improvements, and 116 control of traffic flows and exit points. 118 This document introduces a Basic Network Policy information model 119 (BNP IM) to handle policies related to the network. This basic 120 policy model can be easily extended beyond the basic functions. The 121 [I-D.ietf-i2rs-architecture] suggests that associated with the i2RS 122 RIB model there will be "Policy-based Routing (ACLs)" and RIB "policy 123 controls". These basic policy functions can operate as part of this 124 functional blocks providing the basic model for policy operators. 125 This model can also be considered as the substance of the policy 126 templates. 128 The BNP IM is extensible allowing other extensions to make the BNP IM 129 policy adaptable to specific I2RS protocol features. This policy 130 model can be linked with other information models such as the 131 following: 133 o Policy Base Routing Information model (PBR-IM) (Model in section 134 4), 136 o I2RS RIB Informational Model (RIB IM) (see section 6) 137 ([I-D.ietf-i2rs-rib-info-model]) 139 o BGP Informational Model (BGP IM) (see section 6) 140 ([I-D.hares-i2rs-bgp-im]) 142 o Service Topology (see section 6) 143 ([I-D.hares-i2rs-info-model-service-topo]) 145 o Service Forwarding Chaining Filters Information Mode (SFC IM) (see 146 section 6) (ietf-hares-dunbar-i2rs-sfc-policy-im-00.txt) 148 The BNP IM model is a product of the industry approach to I2RS that 149 standardizes on a few basic functions network functions to obtain 150 quick deployment of initial I2RS RIB modules, and build on this 151 success to create network functions. Additional I2RS modules add 152 I2RS interfaces to policy-based routing, BGP, Service topology 153 creation, Service Chaining functions, and policy templates. 155 This information model leverages previous work done on extensible 156 information model for representing policies, for example, the Policy 157 Core Information Model (PCIM) [RFC3060] [RFC3060], and an extension 158 to this model to address the need for QoS management, called the 159 Quality of Service (QoS) Policy Information Model (QPIM) [RFC3644] 160 [RFC3644]. 162 Most policy within routing and forwarding systems has become 163 hierarchical with individual specific policies being grouped as a set 164 policy. The hierarchical policy rule definition enhances policy 165 readability and reusability. Groups of network policies have labels 166 to aid operational use. Named groups of policy are easily identified 167 and reused as blocks. 169 The Basic Network Policy information model contains the following 170 three components: 172 Policy Group 174 Policy is described by a set of policy rules that may be grouped 175 into subsets. A Policy group is used to provide a hierarchical 176 policy definition that provides the model context or scope for 177 sub-rule actions. The model context includes identity, scope, 178 role, precedence, priority and security model. In a policy group 179 policy rules and policy groups can be nested within other policy 180 rules. 182 Policy Set 184 is a set of Policy Groups identified by a Policy Set Name. 186 Policy Rule 188 Policy Rule is represented by semantics "If Condition then 189 Action", therefore condition and action comprise Policy Rule 190 model. 192 This draft contains the following Informational Models 193 Basic Network-Policy Information Model (BNP IM) 195 is generic network policy model. It can be thought of as a 196 coherent set of rules to administer, manage, and control access to 197 network resources and defines a network policy at its most general 198 level of abstraction. It models aspects such as actions and 199 conditions that constitute a policy element relationship, as well 200 as operators contained in the both condition and action that can 201 either be used to overwrite an old value of the variable or imply 202 match relationship. 204 Policy Based Routing Information Model (PBR IM) 206 defines information that allows the network administer to forward 207 the packet based on other criteria than the destination address in 208 the packet. 210 I2RS Local Config Information Model (I2RS-LC IM) 212 defines I2RS Local Configuration database kept in the I2RS Agent 213 that can be leveraged to quickly set-up policies via the I2RS 214 Agent. This local configuration store contains basic network 215 policies and network templates, and provides quick local access to 216 polies rather than transfer the policies down from the I2RS Client 217 prior to enacting a policy via I2RS interface. 219 2. Definitions and Acronyms 221 IGP: Interior Gateway Protocol 223 Information Model: An abstract model of a conceptual domain, 224 independent of a specific implementations or data representation 226 CLI: Command Line Interface 228 SNMP: The Simple Network Management Protocol 230 NETCONF: The Network Configuration Protocol 232 RBNF: Routing Backus-Naur Form 234 3. Basic Network Policy Information Model (BNP IM) 236 3.1. BNP IM Overview 238 I2RS needs its own implicit and explicit policy. This section 239 provides an overview of the network policy model. The network policy 240 model is defined by the following components, whose relationship is 241 roughly depicted in the figure below. 243 +-----------------------+ 244 | Network-Policy | 245 +-----------+-----------+ 246 ^ 247 /|\ 248 | "extends" 249 +-----------^-------------+ 250 | Policy Set | 251 +--+-------------------+--+ 252 ^ ^ +---------------+ 253 /|\ /|\ ---|PBR Policy-Rule| 254 | | | | Additions | 255 | | | +---------------+ 256 | "extends" | "extends" | +---------------+ 257 +--------^-------+ +-------^-------+ |--|LP Policy-Rule | 258 | Policy Group | | Policy Rule |<---| |Additions | 259 +----------------+ +---------------+ | +---------------+ 260 : : | . . . 261 : : | +---------------+ 262 ......: :..... ---|RIB Policy-Rule| 263 : : | Additions | 264 : : +---------------+ 265 : : 266 +---------V---------+ +-V-------------+ 267 | Policy Condition | | Policy Action | 268 +-------------------+ +---------------+ 269 : : : : : : 270 .....: . :..... .....: . :..... 271 : : : : : : 272 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+ 273 | Match | |Policy | |Policy| | Set || Policy ||Policy| 274 |Operator| |Variable| |Value | |Operator||Variable|| Value| 275 +--------+ +--------+ +------+ +--------++--------++------+ 277 Figure 1: Overall model BNP IM structure 279 Network_policy - contains sets of policies. 281 Policy-Set - is introduced to provide an abstraction for a set of 282 rules. it is inserted into the inheritance hierarchy above both 283 Policy-Group and Policy-Rule. 285 Policy-Group -defines the basic network policy Group model which 286 combines the a list of Policy-Rules. 288 Policy Rule is represented by semantics "If Condition then Action", 289 therefore condition and action comprise Policy Rule model. 291 o Condition models the elementary match operation " match 292 ". 294 o Action models the elementary set operation. "SET TO 295 ". 297 In Condition model, the 'Match' operator is usually implied while in 298 the action model, the 'Set operator is explicitly used. 300 Policy-Sets, Policy-Groups, and Policy-Rules have basic functionality 301 (Policy-Basic IM) plus extensions defined by specific Information 302 Models such as: 304 the PBR Information Model (PBR IM) (contained in this document), 306 the I2RS_Local_Policy Model (LP IM) (contained in this document), 308 the RIB Information Model (RIB IM) 309 ([I-D.ietf-i2rs-rib-info-model]), 311 the BGP Information Model (BGP-IM) ([I-D.hares-i2rs-bgp-im]), 313 the Traffic Steering Information Model 314 ([I-D.hares-i2rs-info-model-service-topo]), 316 the SFC Information Model (SFC IM) (ietf-hares-dunbar-i2rs-sfc- 317 policy-im-00.txt) 319 the MPLS LDP Information Model (MPLS LDP IM) as templates for 320 policy. 322 I2RS Client-Agents Information Models MAY support only the Policy- 323 Basic IM, or MAY support any additional specific information models. 325 Each level of the Policy hierarchy (Policy-Set, Policy-Group, and 326 Policy-Rules have both a read and write scope 328 3.2. The Policy Set 330 3.2.1. Policy Set Overview 332 The PolicySet structure has the following elements: 334 o Policy-Set_Name - Unique Name for Policy Set 335 o Policy-Group is introduced to provide an abstraction for a set of 336 rules. It is derived from Policy, and it is inserted into the 337 inheritance hierarchy above both PolicyGroup and PolicyRule. This 338 reflects the additional structural flexibility and semantic 339 capability of both subclasses. 341 3.2.2. Policy-Set RBNF 343 Figure 2 - Policy Set RBNF 345 ::= ( ...) 346 ::= 348 ::= 349 ( ...) 350 ( ...) 351 () 352 () 354 3.3. The Policy Group 356 3.3.1. Policy Group Overview 358 In order to provide hierarchical policy definition and associate 359 policy rule with other constraint, the basic policy group model needs 360 to be defined. The corresponding extensions are introduced in a 361 component, whose structure is informally depicted in the following 362 diagram. 364 Figure 3 - Policy Group 365 +------------------------------------+ (optional) 366 | Policy Group |.... 367 +------------------------------------+ : 368 * * * * * ^ : 369 | | | | | :....: 370 | | | | | 371 | | | | | 372 | | | | | 373 +--------+ +--------+ +--------+| +-----------+ 374 |Identity| | Role | |Priority|| |Policy Rule| 375 +--------+ +--------+ +--------+| +-----------+ 376 * * | * * * 377 | | | | | | 378 +--- | | +---+---+ | ++----+ 379 | | | |Enabled| | |Usage| 380 | | | +-------+ | +-----+ 381 +-----+----+ +------+ | | 382 | Resource | |Scope | | | 383 +----------+ +------+ | | 384 * * | +--+------+ 385 | | +----+------+ |Mandatory| 386 | | | Precedence| +---------+ 387 | | +-----------+ 388 | | 389 +-----++-----+ 390 | Read||Write| 391 |Scope||Scope| 392 +-----++-----+ 394 The basic information model works as follows: Within the policy group 395 information model, hierarchy is used to model context or scope for 396 the sub-rule actions. A policy group contains Identity, scope, 397 priority,precedence, and policy rule. Optionally, the policy group 398 can contain a list of policy groups. 400 The elements of the Policy Group information model are as follows: 402 o Each policy group is captured in its own list, distinguished via a 403 identity, role, priority, precedence. 405 o A policy group has a certain role, such as resource or scope. A 406 policy group can even have multiple roles simultaneously. The 407 role, are captured in the list of "role" component. 409 o A policy role has a certain Scope, such as read scope or write 410 scope. A policy group can even have multiple scope 411 simultaneously. The scope, or scopes, are captured in the list of 412 "scope" components. 414 o A policy has a certain priority, such as priority 0-255. A policy 415 can only have one priority. The priority is captured in the list 416 of "priority" component. 418 o A policy rule can inherit properties (e.g., identity, role, 419 priority, precedence) from policy group. A policy rule also can 420 have its own properties, e.g., enabled, mandatory, usage. 422 o The policy, policy group elements can be extended with policy- 423 specific components (policy-extensions, policy-group-extension 424 respectively). 426 3.3.2. Policy-Group RBNF 428 A more formal depiction in RBNF format follows below 430 Figure 4 - Policy-Group RBNF 432 ::= 433 434 435 436 () 437 [] 438 [] 440 ::= 441 [] 442 ::= INTEGER (0..255); 443 ::= INTEGER (0..250); 444 ::= (( ) ...) 446 ::= 447 [] 448 [] 450 ::== 452 ::= ( ...) 453 ::= | 454 ::= [] 456 ::= ( ) 457 | ( ) 459 ::= 460 [] 461 [] 463 ::= 464 | 466 ::= 467 [] 468 [] 470 ::= 471 | 473 ::= ( 474 ...) 476 ::= ... /* Vendor Specific Policy */ 478 3.4. The Policy Rule 480 3.4.1. Policy-Rule Overview 482 The following diagram contains an informal graphical depiction of the 483 main elements of the information model: 485 Figure 5 - Policy Rule 487 +----------------+ 488 | Policy Rule |<... 489 +----------------+ : 490 * * : : 491 | | :...: 492 | | 493 +---------+ +--------+ 494 ...>|Condition|<.......| Action |<... 495 : +---------+<.......+--------+ : 496 : : * * : : 497 :..... | : :... : 498 | : 499 +--------+...........: 500 |Operator| 501 +--------+ 503 Roughly speaking, the basic information model works as follows: A 504 policy rule contains conditions and actions. Each condition or each 505 action in turn contains operator. A operator connects variable and 506 value in the action or condition. Condition can map onto and be 507 supported by other condition, while action can map onto and be 508 supported by other actions. Policy rule can map onto other, policy 509 rules. 511 The elements of the Policy Rule information model are as follows: 513 o A policy can in turn be part of a hierarchy of policies, building 514 on top of other policies. Each policy is captured in its own 515 level, distinguished via a policy-identity. 517 o Policy rule inherit scope from policy group. A policy role has a 518 certain Scope, such as read scope or write scope. A policy rule 519 can even have multiple scope simultaneously. The scope, or 520 scopes, are captured in the list of "scope" components. 522 o Furthermore, a policy rule contains conditions and actions, each 523 captured in their own list. 525 o A condition contains a variable and a value and use a match 526 operator, to connect variable with value. An examples of an 527 operator might be a" IP ADDRESS AS RESOLVED BYDNS" or "Set to a 528 member". Also, a condition can in turn map onto other condition 529 in an underlay policy. This is captured in list"supporting- 530 condition". 532 o An action contains a variable and a value. An action uses Set 533 operator to connect variable with value. Analogous to a node, an 534 action can in turn map onto other actions in an underlay policy. 535 This is captured in list "supporting-action". 537 o The policy, condition, action and operator elements can be 538 extended with policy-specific components (policy-extensions, 539 condition-extension, action-extension and operator-extension 540 respectively). 542 3.4.2. Policy-Rule RBNF 544 The information model for the Network-policy component is more 545 formally shown in RBNF below: 547 Figure 6 Policy Rule RBNF 549 ::= 550 551 552 553 ( 554 ...) 555 556 [] 558 ::= 559 [] 560 ::= INTEGER (0..250); 561 :;= INTEGER (0..250); 563 ::= ( ...); 564 ::= | 565 567 ::= [] 568 ::= ( 569 ) 570 | ( 571 ) 573 ::= (( 574 ) ...) 575 | [] 577 ::= (( 578 )...) 579 [] 581 ::= 582 ( ...) 583 [] 584 [] 585 [] 587 ::= [] 588 | [ ::= [] 591 | [ ::= PERMIT | DENY ; 594 ::= 595 [] 596 | [ ::= 599 600 601 [ ] 603 ::= 604 |] 606 ::= 607 609 ::= 610 611 612 [ ] 614 ::= 615 ( ...) 616 [] 617 [] 619 ::= [] 620 | [] 622 ::= [] 623 | [] 625 ::= [] 626 | [] 628 ::= 629 [] 630 | [] 632 ::= 633 | 634 | 635 | 637 ::= 638 639 [] 641 /* these scopes besides RIB IM are defined in each IM */ 643 ::= 644 646 ::= 647 649 ::= [ ...] 650 ::= [ ...] 651 ::= 652 653 654 656 /* extensions to other IM */ 658 /* External Read and Write Scope */ 659 ::= 660 [] 661 [] 662 [] 663 [] 664 [] 665 [] 667 ::= 668 [] 669 [] 670 [] 671 [] 672 [] 673 [] 675 /* External Rule Conditionals */ 676 ::= 677 [] 678 | [] 679 | [] 680 | [] 681 | [] 682 | [] 684 ::= 685 [] 686 | [] 687 | [] 688 | [] 689 | [] 690 | [] 692 ::= 693 [] 695 | [] 696 | [] 697 | [] 698 | [] 699 | [] 701 ::= 702 [] 703 | [] 704 | [] 705 | [] 706 | [] 707 | [] 709 :== 710 [] 711 | [] 712 | [] 713 | [] 714 | [] 715 | [] 716 | [] 718 ::= 719 [] 720 | [] 721 | [] 722 | [] 723 | [] 724 | [] 725 | [] 726 | []/* other I2RS IM */ 728 3.5. BNP IM Grammar 730 This section specifies the network policy information model in 731 Routing Backus-Naur Form (RBNF, [RFC5511]). It also provides 732 diagrams of the main entities of which the information model is 733 comprised. 735 ::= ( ...) 736 ::= ( ...) 737 ::= (...) 739 4. The Policy Based Routing Information Model 741 4.1. Policy Based Routing Overview 743 Policy based Routing is a technique used to make routing decisions 744 based on policies set by the network administrator. PBR enables 745 network administrator to forward the packet based on other criteria 746 than the destination address in the packet, which is used to lookup 747 an entry in the routing table. 749 The policy based routing problem can be viewed as a resource 750 allocation problem that incorporates business decision with routing. 751 Policy based routing provides many benefits, including cost saving, 752 load balancing and basic QoS. 754 Routing decisions in policy based routing are based on several 755 criteria beyond destination address, such as packet size, 756 application, protocol used, and identity of the end system. Policy 757 constraints are applied before applying QoS constraints since policy 758 constraint overrides QoS constraint. Policy constraints may be 759 exchanged by routing protocols while updating routing information. 761 The I2RS use cases which benefit from PBR are: 762 [I-D.white-i2rs-use-case] and 763 [I-D.krishnan-i2rs-large-flow-use-case], 765 PBR-Rules extends from Policy Basic Rule with a set of condition, 766 action and attributes. Routing decisions in policy based routing are 767 based on several criteria beyond destination address, such as packet 768 size, application, protocol used, and identity of the end system. 770 4.2. PBR-RIB definition 772 One routing instance (named by an INSTANCE_NAME) can contain multiple 773 PBR RIBs, and is associated with a set of interfaces, and a ROUTER- 774 ID. The entries associated with each routing instance relating to 775 the PBR are: 777 o INSTANCE NAME 779 o interface_list 781 o PRB RIB list - with each entry having an order set of routes 783 o PRB Default RIB - default forwarding FIB. 785 o ROUTER-ID 786 Each PBR RIB has the following: 788 o PRB RIB NAME 790 o PBR Route-entry 792 The Route entry in a PRB has the following information: 794 o match field - as in the RIB IM route 796 o order_list PBR route list with each entry having: a) next-hops, b) 797 PBR route attributes, and c) vendor-attributes 799 The PRB route attributes include QOS Attributes as show in the policy 800 list below. 802 4.3. PBR Rule Component 804 A PBR rule is constructed using condition, action and attributes that 805 are inherited from Policy Group Component. 807 Figure 7 - PBR Policy Rule 809 +-----------------------+ 810 | Policy Rule | 811 +-----------+-----------+ 812 ^ 813 /|\ "extends" 814 +-----------^-----------+ 815 | PBR Rule | 816 +--+-----------------+--+ 817 : : 818 : : ....... 819 : : : : 820 +--------V-------+ +-------V-------+ : 821 | PBR Condition | | PBR Action |<... 822 +----------------+ +-+----------+--+ 823 /|\ /|\ 824 "extends"| | "extends" 825 +---+ +--------+ 826 | | 827 +-------^-------+ +-----^---------+ 828 | QoS Action | |Forward Action | 829 +---------------+ +---------------+ 830 : : : : : : 831 ....: : :..... .....: : :..... 832 : : : : : : 833 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V-----+ 834 |Set | |QoS | |QoS | |Forward ||Next Hop||Next Hop| 835 |Operator| |Variable| |Value | |Operator||Variable||Value | 836 +--------+ +--------+ +------+ +--------++--+-----++--------+ 837 /|\ 838 | "extends" 839 +---^----+ 840 |Next Hop| 841 |Type | 842 +--------+ 843 Figure 3: Policy based routing IM structure 845 4.4. PBR QOS RBNF 847 The PBR QOS RBNF is below 849 Figure 8 - PRB QOS RBNF 851 /* policy rules */ 852 ::= 853 | 855 ::= 856 | 858 = 859 = 860 = 861 = 863 ::= [] 864 [] 865 [] 866 [] 867 [] 868 [] 870 ::= [] 871 [] 872 [] 873 [] 874 [] 876 ::= [] 877 | [] 878 | [( )] 879 | [( )] 880 | [( )] 882 ::= 883 ::= 884 ::= 885 ::= 887 ::= [] 888 [] 890 ::= 891 | 893 ::= 894 | 895 | ( ) 896 | () 898 ::= [] 899 | [ ::= 943 [] 944 [] 945 [] 947 ::= 948 949 ( ...) 951 ::= 952 | 954 ::= 955 956 958 959 960 961 962 964 ::= 965 966 967 968 969 971 4.7. Remaining PRB Issues 973 Policy based routing MUST tackle the following difficult questions: 975 o How is policy management strategy selected? Centralized or 976 distributed. 978 o At which point in a network domain are policy constraints checked 979 and enforced? i.e., policy coverage, here policy constraint can be 980 exchanged by routing protocol? 982 o How are policy constraints exchanged within a domain? 984 o How is policy data stored, refreshed and retrieved from policy 985 repository? 987 o How are policy rule conflicts avoided? 989 5. The I2RS Local Policy Information Model 991 5.1. I2RS Local Policy IM Overview 993 The Local Policy Information Model (LB IM) stores I2RS policy and 994 policy templates that are used across many I2RS modules. The LB IM 995 stores a set of policy and a set of policy templates. This section 996 defines the LB IM extensions needed to the Basic Policy set at the 997 Policy-set, Policy-Group, and Policy-Rule level. It also defines the 998 optional extensions to this LP policy model as: 1000 o PBR IM, 1002 o RIB IM, 1004 o BGP IM, 1006 o Traffic Steering (TS IM) 1008 o SFC Filter (SFC-F IM), 1010 o Basic Route Templates IM 1012 The key benefit of the I2RS Local Configure Information Model (Local- 1013 is that it provides a place to store I2RS policy, and I2RS templates. 1014 The LB IM MAY allow for: a) re-use of these policy templates across 1015 multiple I2RS client-I2RS agent sessions, b) storing of some policy 1016 into permanent configuration store 1018 5.2. I2RS Local Policy IM RBNF 1019 Figure 10 - Local I2RS Policy Story extensions 1021 ::= 1022 1023 1025 :== [] 1026 [] 1027 [] 1029 :== (< i2rs_transport > ...) 1030 ::= [] 1036 [] 1037 ... 1039 The model extends the original network-policy model as follows: 1041 o A local policy rule can in turn be part of a hierarchy of 1042 policies, building on top of other policies. Each local 1043 configuration policy is captured in its own level, distinguished 1044 via a policy identity. 1046 o A local policy rule inherit scope from policy group. A local 1047 policy rule has a certain Scope, such as read scope or write 1048 scope. A local policy rule can even have multiple scope 1049 simultaneously. The scope, or scopes, are captured in the list of 1050 "scope" components. 1052 o Furthermore, a local policy contains conditions and actions, each 1053 captured in their own list. 1055 o A condition contains a variable and a value and use a match 1056 operator, to connect variable with value. An examples of an 1057 operator might be a" IP ADDRESS AS RESOLVED BYDNS" or "Set to a 1058 member". Also, a condition can in turn map onto other condition 1059 in an underlay policy. This is captured in list in "supporting- 1060 condition". 1062 o An action contains a variable and a value. An action uses Set 1063 operator to connect variable with value. Analogous to a node, an 1064 action can in turn map onto other actions in an underlay policy. 1065 This is captured in list "supporting-action". 1067 o The local policy, condition, action and operator elements can be 1068 extended with policy-specific components (condition-extension, 1069 action-extension and operator-extension respectively). 1071 6. Extensions to the Policy IM 1073 6.1. Extension to the RIB IM 1075 Figure 11 - RIB Information Model Extensions 1077 ::= [ ::= [ ::= 1080 1081 1082 ::= [ ::= [ ::= 1089 ::= ( ...) 1091 ::= 1093 ::= ( ...) 1094 ::= 1095 1096 1097 1098 1100 ::= ( ...) 1101 ::= ( ...) 1102 ::= (...) 1104 6.2. Extension from the BGP IM 1106 Figure 12 - BGP Information Model Extensions 1108 ::= [ ::= [ ::= 1111 ::= ( ...) 1113 6.3. Extension from SFC Topology IM 1115 Figure 13 - SFC Topology Information Model Extensions 1117 /* what part of the STopo Model can access */ 1119 ::= [ ::= [ ::= 1122 ::= ( ...) 1124 6.4. Extension from the SFC Traffic Filters 1126 Figure 14 - Traffic Steering Information Model Extensions 1128 /* what part of the STopo Model can access */ 1130 ::= [ ::= [ ::= 1133 ::= 1135 7. IANA Considerations 1137 This draft includes no request to IANA. 1139 8. Security Considerations 1141 TBD. 1143 9. Informative References 1145 [I-D.atlas-i2rs-policy-framework] 1146 Atlas, A., Hares, S., and J. Halpern, "A Policy Framework 1147 for the Interface to the Routing System", draft-atlas- 1148 i2rs-policy-framework-00 (work in progress), February 1149 2013. 1151 [I-D.hares-i2rs-bgp-im] 1152 Hares, S., Wang, L., and S. Zhuang, "An I2RS BGP 1153 Information Model", draft-hares-i2rs-bgp-im-00 (work in 1154 progress), July 2014. 1156 [I-D.hares-i2rs-info-model-service-topo] 1157 Hares, S., Wu, W., and X. Guan, "An Information model for 1158 service topology", draft-hares-i2rs-info-model-service- 1159 topo-00 (work in progress), February 2014. 1161 [I-D.ietf-i2rs-architecture] 1162 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1163 Nadeau, "An Architecture for the Interface to the Routing 1164 System", draft-ietf-i2rs-architecture-04 (work in 1165 progress), June 2014. 1167 [I-D.ietf-i2rs-rib-info-model] 1168 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 1169 Information Base Info Model", draft-ietf-i2rs-rib-info- 1170 model-03 (work in progress), May 2014. 1172 [I-D.krishnan-i2rs-large-flow-use-case] 1173 ramki, r., Ghanwani, A., Kini, S., McDysan, D., and D. 1174 Lopez, "Large Flow Use Cases for I2RS PBR and QoS", draft- 1175 krishnan-i2rs-large-flow-use-case-04 (work in progress), 1176 April 2014. 1178 [I-D.white-i2rs-use-case] 1179 White, R., Hares, S., and A. Retana, "Protocol Independent 1180 Use Cases for an Interface to the Routing System", draft- 1181 white-i2rs-use-case-05 (work in progress), June 2014. 1183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1184 Requirement Levels", BCP 14, RFC 2119, March 1997. 1186 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, 1187 "Policy Core Information Model -- Version 1 1188 Specification", RFC 3060, February 2001. 1190 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 1191 Moore, "Policy Quality of Service (QoS) Information 1192 Model", RFC 3644, November 2003. 1194 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 1195 "Policy-Enabled Path Computation Framework", RFC 5394, 1196 December 2008. 1198 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1199 Used to Form Encoding Rules in Various Routing Protocol 1200 Specifications", RFC 5511, April 2009. 1202 Authors' Addresses 1203 Susan Hares 1204 Huawei 1205 7453 Hickory Hill 1206 Saline, MI 48176 1207 USA 1209 Email: shares@ndzh.com 1211 Qin Wu 1212 Huawei 1213 101 Software Avenue, Yuhua District 1214 Nanjing, Jiangsu 210012 1215 China 1217 Email: sunseawq@huawei.com