idnits 2.17.1 draft-hares-i2rs-bnp-info-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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). -- The document date (September 26, 2014) is 3498 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: 'AND' is mentioned on line 460, but not defined == Unused Reference: 'I-D.hares-i2rs-usecase-reqs-summary' is defined on line 857, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 884, 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-01 == Outdated reference: A later version (-02) exists of draft-hares-i2rs-usecase-reqs-summary-00 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-05 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-03 Summary: 1 error (**), 0 flaws (~~), 11 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: March 30, 2015 September 26, 2014 7 An Information Model for Basic Network Policy 8 draft-hares-i2rs-bnp-info-model-00 10 Abstract 12 This document contains three information Models: Basic Network Policy 13 (BNP IM). ACLs do not provide all the policy support required by 14 BGP, Policy Based Routing (PBR), SFC Topology Information Model (SF- 15 Topo IM), Service Forwarding Chaing IM (SFC IM), and and flow 16 specification filtering. The BNP IM has the following top-down 17 levels of Policy Hierarchy: Policy Set, Policy Group, Policy Rule, 18 and conditional actions within the policy rule (conditional match and 19 Actions). These can be used in PBR-RIB or BGP to provide an ordered 20 set of policy rules grouped with a Policy Group via operators (AND, 21 OR, etc.) and ordered by a combination of priority and precedence. 22 The Policy is an ordered set of Policy Groups. 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 March 30, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . 12 75 3.4.1. Policy-Rule Overview . . . . . . . . . . . . . . . . 12 76 3.4.2. Policy-Rule RBNF . . . . . . . . . . . . . . . . . . 13 77 3.5. BNP IM Grammar . . . . . . . . . . . . . . . . . . . . . 18 78 4. Extensions to the Policy IM . . . . . . . . . . . . . . . . . 18 79 4.1. Extension to the RIB IM . . . . . . . . . . . . . . . . . 18 80 4.2. Extension from the BGP IM . . . . . . . . . . . . . . . . 19 81 4.3. Extension from SFC Topology IM . . . . . . . . . . . . . 19 82 4.4. Extension from the SFC Traffic Filters . . . . . . . . . 19 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 7. Informative References . . . . . . . . . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 The Interface to the Routing System (I2RS) provides read and write 91 access to the information and state within the routing process within 92 routing elements. The I2RS client interacts with one or more I2RS 93 agents to collect information from network routing systems. 95 Processing of collected information at the I2RS agent may require the 96 I2RS Agent to filter certain information or group pieces of 97 information in order to reduce the data flow through the network to 98 the I2RS client. Some applications that that utilize the services of 99 I2RS client may also wish to require specific data in response to 100 network events or conditions based on pre-established rules. This 101 functionality is necessary to meet the requirements of i2rs enabled 102 services which include service-layer routing improvements, and 103 control of traffic flows and exit points. 105 This document introduces a Basic Network Policy information model 106 (BNP IM) to handle policies related to the network. This basic 107 policy model can be easily extended beyond the basic functions. The 108 [I-D.ietf-i2rs-architecture] suggests that associated with the I2RS 109 RIB model there will be "Policy-based Routing (ACLs)" and RIB "policy 110 controls". These basic policy functions can operate as part of this 111 functional blocks providing the basic model for policy operators. 112 This model can also be considered as the substance of the policy 113 templates. 115 The BNP IM is extensible allowing other extensions to make the BNP IM 116 policy adaptable to specific I2RS protocol features. This policy 117 model can be linked with other information models such as the 118 following: 120 o Policy Base Routing Information model (PBR-IM) (Model in section 121 4), 123 o I2RS RIB Informational Model (RIB IM) (see section 6) 124 ([I-D.ietf-i2rs-rib-info-model]) 126 o BGP Informational Model (BGP IM) (see section 6) 127 ([I-D.hares-i2rs-bgp-im]) 129 o Service Topology (see section 6) 130 ([I-D.hares-i2rs-info-model-service-topo]) 132 o Service Forwarding Chaining Filters Information Mode (SFC IM) (see 133 section 6) (ietf-hares-dunbar-i2rs-sfc-policy-im-00.txt) 135 The BNP IM model is a product of the industry approach to I2RS that 136 standardizes on a few basic network functions to obtain quick 137 deployment of initial I2RS RIB modules, and build on this success to 138 create network functions. Additional I2RS modules add I2RS 139 interfaces to policy-based routing, BGP, Service topology creation, 140 Service Chaining functions, and policy templates. 142 This information model leveraged previous work done on extensible 143 information model for representing policies. This work included the 144 Policy Core Information Model (PCIM) [RFC3060] [RFC3060], and an 145 extension to this model to address the need for QoS management, 146 called the Quality of Service (QoS) Policy Information Model (QPIM) 147 [RFC3644] [RFC3644]. 149 Most policy within routing and forwarding systems has become 150 hierarchical with individual specific policies being grouped as a 151 policy set. The hierarchical policy rule definition enhances policy 152 readability and reusability. Groups of network policies have labels 153 to aid operational use. Named groups of policy are easily identified 154 and reused as blocks. 156 The Basic Network Policy information model contains the following 157 three components: 159 Policy Group 161 Policy is described by a set of policy rules that may be grouped 162 into subsets. A Policy group is used to provide a hierarchical 163 policy definition that provides the model context or scope for 164 sub-rule actions. The model context includes identity, scope, 165 role, precedence, priority and security model. In a policy group 166 policy rules and policy groups can be nested within other policy 167 rules. 169 Policy Set 171 A Policy Set is a set of Policy Groups identified by a Policy Set 172 Name. 174 Policy Rule 176 A Policy Rule is represented by the semantics "If Condition then 177 Action". 179 This draft contains the Basic Network-Policy Information Model (BNP 180 IM). BNP IM is a generic network policy model. It can be thought of 181 as a coherent set of rules to administer, manage, and control access 182 to network resources and defines a network policy at its most general 183 level of abstraction. It models aspects such as actions and 184 conditions that constitute a policy element relationship, as well as 185 operators contained in the both condition and action that can either 186 be used to overwrite an old value of the variable or imply match 187 relationship. 189 2. Definitions and Acronyms 191 IGP: Interior Gateway Protocol 193 Information Model: An abstract model of a conceptual domain, 194 independent of a specific implementations or data representation 196 CLI: Command Line Interface 198 SNMP: The Simple Network Management Protocol 200 NETCONF: The Network Configuration Protocol 202 RBNF: Routing Backus-Naur Form 204 INSTANCE: Routing Code often has the ability to spin up multiple 205 copies of itself into virtual machines. Each Routing code 206 instance or each protocol instance is denoted as Foo_INSTANCE in 207 the text below. 209 3. Basic Network Policy Information Model (BNP IM) 211 3.1. BNP IM Overview 213 I2RS needs its own implicit and explicit policy. This section 214 provides an overview of the network policy model. The network policy 215 model is defined by the following components, whose relationship is 216 roughly depicted in the figure below. 218 +-----------------------+ 219 | Network-Policy | 220 +-----------+-----------+ 221 ^ 222 /|\ 223 | "extends" 224 +-----------^-------------+ 225 | Policy Set | 226 +--+-------------------+--+ 227 ^ ^ 228 /|\ /|\ 229 +------------+ +--------------+ 230 |Policy Group| | Policy Group | 231 +------------+ +--------------+ 232 ^ ^ +----------------+ 233 | | ---|ACL Policy-Rule | 234 | | | | Additions | 235 | | | +----------------+ 236 | "extends" | "extends" | +----------------+ 237 +--------^-------+ +-------^-------+ |--|PBR Policy-Rule | 238 | Policy Rule | | Policy Rule |<----| Additions | 239 +----------------+ +---------------+ | +----------------+ 240 : : | . . . 241 : : | +---------------+ 242 ......: :..... ---|RIB Policy-Rule| 243 : : | Additions | 244 : : +---------------+ 245 : : 246 +---------V---------+ +-V-------------+ 247 | Policy Condition | | Policy Action | 248 +-------------------+ +---------------+ 249 : : : : : : 250 .....: . :..... .....: . :..... 251 : : : : : : 252 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+ 253 | Match | |Policy | |Policy| | Set || Policy ||Policy| 254 |Operator| |Variable| |Value | |Operator||Variable|| Value| 255 +--------+ +--------+ +------+ +--------++--------++------+ 257 Figure 1: Overall model BNP IM structure 259 Network-Policy - contains sets of policies. 261 Policy-Set: Provides an ordered list of Policy Groups according to 262 the priority and precedence of the rules. rules. it is inserted into 263 the inheritance hierarchy above both Policy-Group and Policy-Rule. 265 Policy-Group: Defines the basic network policy Group model which 266 combines the a list of Policy-Rules. 268 Policy Rule: Represents the semantics of "If Condition then Action". 270 o Condition models the elementary match operation " match 271 ". 273 o Action models the elementary set operation. "SET TO 274 ". 276 In the Condition model, the 'Match' operator is usually implied while 277 in the action model, the 'Set' operator is explicitly used. 279 Policy-Sets, Policy-Groups, and Policy-Rules have basic functionality 280 (Policy-Basic IM) plus extensions defined by specific Information 281 Models such as: 283 The PBR Information Model (PBR IM) (contained in this document), 285 The I2RS_Local_Policy Model (LP IM) (contained in this document), 287 The RIB Information Model (RIB IM) 288 ([I-D.ietf-i2rs-rib-info-model]), 290 The BGP Information Model (BGP-IM) ([I-D.hares-i2rs-bgp-im]), 292 The Traffic Steering Information Model 293 ([I-D.hares-i2rs-info-model-service-topo]), 295 The SFC Information Model (SFC IM) (ietf-hares-dunbar-i2rs-sfc- 296 policy-im-00.txt) 298 The MPLS LDP Information Model (MPLS LDP IM) (TBD) . 300 I2RS Client-Agents Information Models MAY support only the Policy- 301 Basic IM, or MAY support any additional specific information models. 303 Each level of the Policy hierarchy (Policy-Set, Policy-Group, and 304 Policy-Rules have both a read and write scope 306 3.2. The Policy Set 308 3.2.1. Policy Set Overview 310 The Policy-Set structure has the following elements: 312 o Policy-Set_Name - Unique Name for Policy Set 313 o Policy-Set is introduced to provide an abstraction for a set of 314 rules. It is derived from Policy, and it is inserted into the 315 inheritance hierarchy above both PolicyGroup and PolicyRule. This 316 reflects the additional structural flexibility and semantic 317 capability of both subclasses. 319 3.2.2. Policy-Set RBNF 321 Figure 2 - Policy Set RBNF 323 ::= ( ...) 324 ::= 325 326 ::= ( ...) 328 3.3. The Policy Group 330 3.3.1. Policy Group Overview 332 In order to provide hierarchical policy definition and associate 333 policy rule with other constraint, the basic policy group model needs 334 to be defined. The corresponding extensions are introduced in a 335 component, whose structure is informally depicted in the following 336 diagram. 338 Figure 2 - Policy Group 339 +---------------------------------------+ (optional) 340 | Policy Group |.... 341 +---------------------------------------+ : 342 * * * * ^ : 343 | | | :....: 344 | | | | | 345 | | | | | 346 | | | | | 347 +--------+ +----+ +-----------+ +------------------+ 348 |Identity| |Role| |Group order| | Policy Rule | 349 +--------+ +----+ +---+--+---+| +------------------+ 350 * * * * * * 351 | | | | | 352 +--+ | - +---------+ +-------+ | +-+-------+ 353 | | | |priority | |policy | | |mandatory| 354 | | +---------+ |order | | +---------+ 355 +----+---+ ++----+ |-+----------+ +-------+ | +-------+ 356 |Resource| |Scope| |-|precedence| | ----+-+ Name + 357 +--------+ +-----+ | +----------+ | +--------+ | +-------+ 358 * * | +----------+ |-|priority| | +-------+ 359 | | |-|preference| | +--------+ +-|enabled| 360 | | | +----------+ | +----------+ +-------+ 361 | | | +----------+ |-|precedence| 362 | | |-| combine | | +----------+ 363 | | | +----------+ | +----------+ 364 | | | +----------+ |-|preference| 365 | | |-|refcnt | | +----------+ 366 | | +----------+ | +----------+ 367 +-----++-----+ +-| combine | 368 | Read||Write| | +----------+ 369 |Scope||Scope| | +----------+ 370 +-----++-----+ |-| refcnt | 371 +----------+ 373 The basic information model works as follows: Within the policy group 374 information model, hierarchy is used to model context or scope for 375 the sub-rule actions. A policy group contains Identity, role, and 376 group ordering information. The ordering is the variables priority, 377 precedence, preference, combination operators (AND plus OR), and 378 reference count (refcnt) for the policy group. The same ordering 379 information is kept at the rule level. 381 The elements of the Policy Group information model are as follows: 383 o An identity contains the name of the Policy group 384 o A role which identifies a resource (E.g. PBR-RIB, or BGP 385 Neighbor) and a read/write scope. A policy group may have read 386 scope, write scope, or both. 388 o A policy group has ordering that includes priority, precedence, 389 preference (within global route table) and combinational ordering 390 (combine). A group can have only one priority, precedence, and 391 preference. The default mechanism for establishing order to order 392 first on priority, and if matched to use precedence to order, and 393 if precedence ties, to use preference. Other priorities may be 394 used and the signalling of these is not covered at this revision. 395 The policy group reference count is a read-only variable on the 396 number of times this policy-group has been associated with an I2RS 397 interface to a protocol or a RIB (RIB or PBR RIB) 399 o A policy rule has policy condition for matching, actions, and the 400 same ordering values as the policy group which include: priority, 401 precedence, preference, and combination ordering. Policy rules 402 can be ordered within a RIB such as the PBR-RIB or within the a 403 rules set associated with a protocol. Please note that ACLS wit 404 their condition for matching, the DENY/ACCEPT action, and the 405 preference setting form one type of policy group. 407 o The mandatory flag indicates that this rule is mandatory to be 408 satisfied for this policy group. (This feature is still under 409 discussion within the group of authors.) 411 o The enabled flag indicates that this rule is enabled. The lack of 412 the flag allows rules to be inserted into a policy set without 413 being enabled. 415 o A policy rule can inherit scope and ordering from the policy group 416 or use its own values. A policy rule also can have its own 417 properties, e.g., enabled, mandatory, usage. Rules 419 o The policy rule policy group elements can be extended with policy- 420 specific components (policy-extensions, policy-group-extension 421 respectively). One such extension is the inheritance of the ACL 422 specific rule as policy rules. 424 3.3.2. Policy-Group RBNF 426 A more formal depiction in RBNF format follows below 428 Figure 4 - Policy-Group RBNF 430 ::= 431 432 433 () 434 [] 435 [] 437 ::= ( ...) 438 ::= | 439 ::= [] 441 ::= ( ) 442 | ( ) 444 ::= STRING; 445 ::= 446 447 448 449 451 ::= 452 ::= 453 ::= 454 ::= 455 ::= 457 :: = INTEGER; 458 :: = INTEGER: 459 ::= INTEGER; 460 :: = [AND] | OR| NULL; 461 :: = INTEGER; 462 ::= * 464 [Xpath in Yang may or may not be able to replace the definitions below ] 466 ::= 467 [] 468 [] 470 ::= 471 | 473 ::= 474 [] 475 [] 477 ::= 478 | 480 ::= ( 481 ...) 483 ::= ... /* Vendor Specific Policy */ 485 3.4. The Policy Rule 487 3.4.1. Policy-Rule Overview 489 The following diagram contains an informal graphical depiction of the 490 main elements of the information model: 492 Figure 5 - Policy Rule 494 +----------------+ 495 | Policy Rule | 496 +----------------+ 497 * * 498 | | 499 | | 500 +---------+ +--------+ 501 ...>|Condition|<.......| Action |<... 502 : +---------+<.......+--------+ : 503 : : * * : : 504 :..... | : :... : 505 | : 506 +--------+...........: 507 |Operator| 508 +--------+ 510 Roughly speaking, the basic information model works as follows: A 511 policy rule must identity, match conditions and actions; and it may 512 contain policy rule ordering and status information. A operator 513 connects variable and value in the action or condition. Condition 514 can map onto and be supported by other condition, while action can 515 map onto and be supported by other actions. 517 The elements of the Policy Rule information model are as follows: 519 o A policy can in turn be part of a hierarchy of policies Each 520 policy is distinguished via a policy-identity. 522 o Policy rule inherit scope from policy group. A policy role has a 523 certain scope(read/write). This scope is intended to capture the 524 unique I2RS read or write functionality of the role. This is a 525 place-holder for this function of the I2RS ROLE. Hopefully, 526 policy scope can be deleted. 528 o Furthermore, a policy rule contains conditions and actions, each 529 captured in their own list. The logic presented is a compromise 530 between the simple logical AND and the complicated negation. 532 o A condition contains a variable and a value and use a match 533 operator, to connect variable with value. Also condition may be 534 specific to a particular Info-Module like BGP IM. The list 535 Policy-Rule_Condition_Extensions specifies these conditions which 536 are unique to the protocol. 538 o An action contains a variable and a value. An action uses the Set 539 operator to connect a variable with a value. An action may be 540 specific to a particular Info-Module like BGP IM. The list 541 Policy-Rule_Action_Extensions specifies these conditions which are 542 unique to the protocol. This is captured in list Policy- 543 Rule_Action_Extensions 545 o The policy, condition, action and operator elements can be 546 extended with policy-specific components (policy-extensions, 547 condition-extension, action-extension and operator-extension 548 respectively) that are specific to other informational models. 550 o Resources below indicates the amount of space that the policy 551 might take in the routing instance. The issue is to try to 552 differentiate between the 50 ACL policy group and the 300,000 ACL 553 group. 555 o Policy Rule scope maps to ROLE Read/Write Concept. This concept 556 is under revision (see i2rs-security-draft) It is intended to 557 restrict even policy to a portion of the Routing tree. Whether 558 this makes policy simpler or more complex is the question. 560 o RIB-IM-Tree-Match - indicates a match stored as a tree form with 561 the longest match. 563 3.4.2. Policy-Rule RBNF 565 The information model for the Network-policy component is more 566 formally shown in RBNF below: 568 Figure 6 Policy Rule RBNF 570 ::= [] 571 [] 572 [] 574 575 576 [] 578 ::= 579 580 581 582 584 ::= [] 585 [] 587 ::= string; 588 ::= 589 ::= 590 ::= 591 ::= 592 ::= 593 ::= Boolean; 594 ::=Boolean; 596 ::= 597 ( ...) 598 [] 599 [] 600 [] 602 ::= [] 603 | [ ::= [] 606 | [ ::= PERMIT | DENY ; 609 ::= 610 [] 611 | [ ::= 614 615 617 [ ] 619 ::= 620 |] 622 ::= 623 625 ::= 626 627 628 [ ] 630 ::= 631 ( ...) 632 [] 633 [] 635 ::= [] 636 | [] 638 ::= [] 639 | [] 641 ::= [] 642 | [] 644 ::= 645 [] 646 | [] 648 ::= 649 | 650 | 651 | 653 ::= 654 655 [] 657 ! Policy Rule scope maps to ROLE Read/Write Concept 658 ! This concept is under revision (see i2rs-security-draft) 659 ! It is intended to restrict even policy to a portion of the 660 ! Routing tree. Whether this makes policy simpler or more 661 ! complex is the question. 662 ::= ( 663 ) 664 | ( 665 ) 667 ::= (( 668 ) ...) 669 | [] 671 ::= (( 672 )...) 673 [] 675 /* these scopes besides RIB IM are defined in each IM */ 677 ::= 678 680 ::= 681 683 ::= [ ...] 684 ::= [ ...] 685 ::= 686 687 688 690 /* extensions to other IM */ 692 /* External Read and Write Scope */ 693 ::= 694 [] 695 [] 696 [] 697 [] 698 [] 699 [] 701 ::= 702 [] 703 [] 704 [] 705 [] 706 [] 707 [] 709 /* External Rule Conditionals */ 710 ::= 711 [] 713 | [] 714 | [] 715 | [] 716 | [] 717 | [] 719 ::= 720 [] 721 | [] 722 | [] 723 | [] 724 | [] 725 | [] 727 ::= 728 [] 729 | [] 730 | [] 731 | [] 732 | [] 733 | [] 735 ::= 736 [] 737 | [] 738 | [] 739 | [] 740 | [] 741 | [] 743 ::= 744 [] 745 | [] 746 | [] 747 | [] 748 | [] 749 | [] 750 | [] 752 ::= 753 [] 754 | [] 755 | [] 756 | [] 757 | [] 758 | [] 759 | [] 760 | []/* other I2RS IM */ 762 3.5. BNP IM Grammar 764 This section specifies the network policy information model in 765 Routing Backus-Naur Form (RBNF, [RFC5511]). It also provides 766 diagrams of the main entities of which the information model is 767 comprised. 769 ::= ( ...) 770 ::= ( ...) 771 ::= (...) 773 4. Extensions to the Policy IM 775 4.1. Extension to the RIB IM 777 Figure 11 - RIB Information Model Extensions 779 ::= [ ::= [ ::= 782 783 784 ::= [ ::= [ ::= 791 ::= ( ...) 793 ::= 795 ::= ( ...) 796 ::= 797 798 799 800 802 ::= ( ...) 803 ::= ( ...) 804 ::= (...) 806 4.2. Extension from the BGP IM 808 Figure 12 - BGP Information Model Extensions 810 ::= [ ::= [ ::= 813 ::= ( ...) 815 4.3. Extension from SFC Topology IM 817 Figure 13 - SFC Topology Information Model Extensions 819 /* what part of the STopo Model can access */ 821 ::= [ ::= [ ::= 824 ::= ( ...) 826 4.4. Extension from the SFC Traffic Filters 828 Figure 14 - Traffic Steering Information Model Extensions 830 /* what part of the STopo Model can access */ 832 ::= [ ::= [ ::= 835 ::= 837 5. IANA Considerations 839 This draft includes no request to IANA. 841 6. Security Considerations 843 TBD 845 7. Informative References 847 [I-D.hares-i2rs-bgp-im] 848 Hares, S., Wang, L., and S. Zhuang, "An I2RS BGP 849 Information Model", draft-hares-i2rs-bgp-im-00 (work in 850 progress), July 2014. 852 [I-D.hares-i2rs-info-model-service-topo] 853 Hares, S., Wu, W., and X. Guan, "An Information model for 854 service topology", draft-hares-i2rs-info-model-service- 855 topo-01 (work in progress), July 2014. 857 [I-D.hares-i2rs-usecase-reqs-summary] 858 Hares, S., "Summary of I2RS Use Case Requirements", draft- 859 hares-i2rs-usecase-reqs-summary-00 (work in progress), 860 July 2014. 862 [I-D.ietf-i2rs-architecture] 863 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 864 Nadeau, "An Architecture for the Interface to the Routing 865 System", draft-ietf-i2rs-architecture-05 (work in 866 progress), July 2014. 868 [I-D.ietf-i2rs-rib-info-model] 869 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 870 Information Base Info Model", draft-ietf-i2rs-rib-info- 871 model-03 (work in progress), May 2014. 873 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 874 Requirement Levels", BCP 14, RFC 2119, March 1997. 876 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, 877 "Policy Core Information Model -- Version 1 878 Specification", RFC 3060, February 2001. 880 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 881 Moore, "Policy Quality of Service (QoS) Information 882 Model", RFC 3644, November 2003. 884 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 885 "Policy-Enabled Path Computation Framework", RFC 5394, 886 December 2008. 888 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 889 Used to Form Encoding Rules in Various Routing Protocol 890 Specifications", RFC 5511, April 2009. 892 Authors' Addresses 893 Susan Hares 894 Huawei 895 7453 Hickory Hill 896 Saline, MI 48176 897 USA 899 Email: shares@ndzh.com 901 Qin Wu 902 Huawei 903 101 Software Avenue, Yuhua District 904 Nanjing, Jiangsu 210012 905 China 907 Email: bill.wu@huawei.com@huawei.com