idnits 2.17.1 draft-hares-i2rs-bnp-info-model-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 287 has weird spacing: '...esource tree-...' == Line 288 has weird spacing: '...-access acc...' == Line 322 has weird spacing: '...ext-hop rib-n...' == Line 338 has weird spacing: '...uter-id uint3...' == Line 348 has weird spacing: '...Filters rule-...' -- The document date (March 8, 2015) is 3329 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.hares-i2rs-usecase-reqs-summary' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-architecture' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-restconf' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC5511' is defined on line 417, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-hares-i2rs-usecase-reqs-summary-01 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-09 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-05 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-04 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-02 Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). 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: September 9, 2015 J. Tantsura 6 R. White 7 Ericsson 8 March 8, 2015 10 An Information Model for Basic Network Policy and Filter Rules 11 draft-hares-i2rs-bnp-info-model-02 13 Abstract 15 This document contains the Basic Network Policy and Filters (BNP IM) 16 Information Model which provides a generic model for representing an 17 ordered list of routing policy or filter rules. Filter rules which 18 combine match-condition with action (forwarding or sets) are 19 supported by this policy. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 9, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 57 3. Generic Route Filters/Policy Overview . . . . . . . . . . . . 3 58 4. BNP Rule Groups . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. BNP Generic Info Model in High Level Yang . . . . . . . . . . 7 60 6. Example of use in filters . . . . . . . . . . . . . . . . . . 9 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 9. Informative References . . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 66 1. Introduction 68 This generic network policy provide a model to support an ordered 69 list of routing policy or an ordered list of filter rule. An ordered 70 list of policy can be used in protocols such as BGP. An ordered list 71 of filters can be used in filtering for routing data traffic or 72 flows. Two examples of the ordered-based filters is the I2RS Filter- 73 based RIBS or flow specification filtering. This generic model can 74 be used to combine filter rules such as: ACLs, Prefix-filtering, and 75 complex filter match-actions rules (match, set, modify, set). 77 This generic model combines rules for filter/policy into groups of 78 groups. project. 80 Antecedents to this generic policy are the generic policy work done 81 in PCIM WG. The PCIM work contains a Policy Core Information Model 82 (PCIM) [RFC3060], Policy Core Informational Model Extensions 83 [RFC3460] and the Quality of Service (QoS) Policy Information Model 84 (QPIM) ([RFC3644]) From PCIM comes the concept that policy rules 85 which are combined into policy groups. PCIM also refined a concept 86 of policy sets that allowed the nesting and aggregation of policy 87 groups. This generic model did not utilize the concept of sets of 88 groups, but could be expanded to include sets of gorups in the 89 future. 91 Policy rules may include specific filters such as ACL or prefix 92 filters by simple reference. The following drafts provide these more 93 specific filters; 95 o ACL policy [I-D.ietf-netmod-acl-model] 96 o BGP Prefix filter policy [I-D.zhdankin-idr-bgp-cfg] 98 2. Definitions and Acronyms 100 BGP: Border Gateway Protocol 102 CLI: Command Line Interface 104 IGP: Interior Gateway Protocol 106 Information Model: An abstract model of a conceptual domain, 107 independent of a specific implementations or data representation 109 INSTANCE: Routing Code often has the ability to spin up multiple 110 copies of itself into virtual machines. Each Routing code 111 instance or each protocol instance is denoted as Foo_INSTANCE in 112 the text below. 114 NETCONF: The Network Configuration Protocol 116 PCIM - Policy Core Information Model 118 RESTconf - http programmatic protocol to access yang modules 120 3. Generic Route Filters/Policy Overview 122 This generic policy model represents filter or routing policies as 123 rules and groups of rules. 125 The basic concept are: 127 Rule Group 129 A rule group is is an ordered set of rules . 131 Rule 133 A Rule is represented by the semantics "If Condition then Action". 134 A Rule may have a priority assigned to it. 136 +-----------+ +------------+ 137 |Rule Group | | Rule Group | 138 +-----------+ +------------+ 139 ^ ^ +----------------+ 140 | | ---| ACL Rules | 141 | | | | Additions | 142 | | | +----------------+ 143 | | | +----------------+ 144 +--------^-------+ +-------^-------+ |--|Prefix Rule | 145 | Rule | | Rule |<----| Additions | 146 +----------------+ +---------------+ | +----------------+ 147 : : | . . . 148 : : | +----------------+ 149 ......: :..... ---|Other Rules | 150 : : | Additions | 151 : : +----------------+ 152 : : 153 +---------V---------+ +-V-------------+ 154 | Rule Condition | | Rule Action | 155 +-------------------+ +---------------+ 156 : : : : : : 157 .....: . :..... .....: . :..... 158 : : : : : : 159 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+ 160 | Match | | match | |match | | Action || action ||action| 161 |Operator| |Variable| |Value | |Operator||Variable|| Value| 162 +--------+ +--------+ +------+ +--------++--------++------+ 164 Figure 1: BNP structure 166 4. BNP Rule Groups 168 Rule groups have the following elements: 170 o name that identifies the grouping of policy rules 172 o role - that is a combination of target resource (E.g. IPv4 FB-FIB 173 filters) and a scope (read, read-write, write-only). 175 o list of rules 177 The rule has the following elements: name, order, status, priority, 178 reference cnt, and match-action as shown as shown in figure 2. The 179 order indicates the order of the rule within the list. The status of 180 the rule is (active, inactive). The priority is the priority within 181 a specific order of policy/filter rules. A reference count (refcnt) 182 indicates the number of entities (E.g. network modules) using this 183 policy. The generic rule match-action conditions have match 184 operator, a match variable and a match value. The rule actions have 185 an action operator, action variable, and an action value. 187 The generic rules can be included with other types of rules as figure 188 2 shows. 190 Figure 2 - Rule Group 191 +-------------------------------------+ (optional) 192 | Rule Group |.... 193 +--------------------------------------+ : 194 * * * ^ : 195 | | | :....: 196 | | | 197 | | | 198 +------+ +-----+ +-------------------+ 199 | Name | |Role | | Rule_list | 200 | | | | | | 201 +------+ +-----+ +------|------------+ 202 * * +------|-----------+ 203 | | | rule | 204 | | +--|---------------+ 205 | | | 206 +--+ | | +----------+ 207 | |-| Name | 208 | | | +----------+ 209 +----+---+ ++----+ | +----------+ 210 |Resource |Scope| | | + Rule | 211 +--------+ +-----+ |-| order | 212 | +----------+ 213 | +----------+ 214 |-| Status | 215 | +----------+ 216 | +----------+ 217 |-| priority | 218 | +----------+ 219 | +----------+ 220 |-| refcnt | 221 | +----------+ 222 | +--------------+ 223 |-| Rule | 224 | match/action | 225 +-----|--------+ 226 | 227 +----|--------------|----|-----------+ 228 | | | 229 +-------|-------+ +----|---------+ +----|---------+ . . . 230 | bnp generic | | Access rule | | Prefix-list | 231 | match/action | | match/action | | rule | 232 +---------------+ +--------------+ +--------------+ 234 The conditions in one rule may cause actions to set values (E.g. BGP 235 communities) that are examined in a second rule as shown in figure 3. 237 Figure 3 - Rule's match-condition 239 +----------------+ 240 | Rule | 241 | Match/action | 242 +----------------+ 243 * * 244 | | 245 | | 246 +---------+ +--------+ 247 ...>|Condition|<.......| Action |<... 248 : +---------+<.......+--------+ : 249 : : * * : : 250 :..... | : :... : 251 | : 252 +--------+...........: 253 |Operator| 254 +--------+ 256 The generic match conditions are specific to a particular layer are 257 refined by matches to a specific layer (as figure 4 shows), and 258 figure 5's high-level yang defines. The general actions may be 259 generic actions that are specific to a particular layer (L1, L2, L3, 260 service layer) or general forwarding by interface or nexthop. The 261 high-level yang diagram for the matches in figure 5. 263 Figure 4 264 +-------------+ 265 | Match | 266 | Condition | 267 +-------|-----+ 268 | 269 +-------------+-|-----------+-----------+ 270 | | | | 271 V V V V 272 ............ ............ ............ ........... 273 : L1 : : L2 : : L3 : : Service : 274 : match : : match : : match : : match : 275 '''''''''''' '''''''''''' '''''''''''' ''''''''''' 277 5. BNP Generic Info Model in High Level Yang 279 Below is the high level yang diagram for the 280 Figure 5 281 module:bnp-generic-rules 282 import ietf-acl 283 import ietf-interface 284 +-rw rule-group* [group-name] 285 +--rw group-name 286 +--rw group-scope 287 | +--resource tree-identity 288 | +--access access-identity 289 +--rw group-installer install-identity 290 +--rw rule* [rule-name] 291 +--rw rule-name string 292 +--rw order unit16 293 +--rw installer 294 +--rw status enumeration 295 | +--ro rules-status 296 | +--ro rule-inactive-reason 297 | +--ro rule-installer 298 +--rw priority unit16 299 +--rw refcnt unit16 300 +--rw rule-match-act 301 +--rw match-act-type match-act-type-identity 302 +--case: BNP-GENERIC-MATCH-ACTION 303 | +--rw bnp-term-match 304 | | +--case: interface-match 305 | | +--case: L1-header-match 306 | | +--case: L2-header-match 307 | | +--case: L3-header-match 308 | | +--case: L4-header-match 309 | | +--case: Service-header-match 310 | +--rw bnp-action 311 | | +--rw genric-actions [nbr-act] 312 | | | +--rw n-acts 313 | | | +--rw qos-action 314 | | | | +--case L1-action 315 | | | | +--case L2-action 316 | | | | +--case L3-action 317 | | | | +--case L4-action 318 | | | | +--case service-action 319 | +--rw bnp-forward 320 | | +--rw forward 321 | | | +--rw interface interface-ref 322 | | | +--rw next-hop rib-nexthop-ref 323 | | | +--rw route-attributes 324 | | | +--rw rib-route-attributes-ref 325 | | +--rw fb-std-drop 326 +--case: ACL-MATCH-ACTION 327 +--rw acl-match-act acl-list-entry-name 329 6. Example of use in filters 331 The following is an example is an example structure for the rrule 332 match-condition applied to Filter-Based RIB containing a list of 333 routes 335 figure 6 336 module: FB-RIB 337 +--rw FB-RIB-instance-name 338 +--rw RB-RIB-router-id uint32 339 +--rw FB-RIB-interface* 340 | +--rw FB-RIB-interface interface-ref-id 341 +--rw FB-Default-RIB rib-ref 342 +--rw FB-RIB 343 +--rw FB-RIB-Name 344 +--rw FB-RIB-AFI 345 +--rw FB-RIB-intf* 346 +--rw FB-FIB-status-info 347 | +--rw fb-rib-update-ref uint64 348 +--rw FB-RIB-Ordered-Filters rule-group-list-ref 349 uses /nt:bnp-generic-rules 351 rule-group-list-ref points to rule-group-list 353 7. IANA Considerations 355 This draft includes no request to IANA. 357 8. Security Considerations 359 These generic filters are used in the I2RS FB-RIBs to filter packets 360 in a traffic stream, act to modify packets, and forward data packets. 361 These I2RS filters operate dynamically at same level as currently 362 deployed configured filter-based RIBs to filter, change, and forward 363 traffic. The dynamic nature of this protocol requires that I2RS 364 Filters track the installer of group information and rules. 366 This section will be augmented after a discussion with security 367 experts. 369 9. Informative References 371 [I-D.hares-i2rs-usecase-reqs-summary] 372 Hares, S. and M. Chen, "Summary of I2RS Use Case 373 Requirements", draft-hares-i2rs-usecase-reqs-summary-01 374 (work in progress), October 2014. 376 [I-D.ietf-i2rs-architecture] 377 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 378 Nadeau, "An Architecture for the Interface to the Routing 379 System", draft-ietf-i2rs-architecture-09 (work in 380 progress), March 2015. 382 [I-D.ietf-i2rs-rib-info-model] 383 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 384 Information Base Info Model", draft-ietf-i2rs-rib-info- 385 model-05 (work in progress), January 2015. 387 [I-D.ietf-netconf-restconf] 388 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 389 Protocol", draft-ietf-netconf-restconf-04 (work in 390 progress), January 2015. 392 [I-D.ietf-netmod-acl-model] 393 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 394 "Network Access Control List (ACL) YANG Data Model", 395 draft-ietf-netmod-acl-model-02 (work in progress), March 396 2015. 398 [I-D.zhdankin-idr-bgp-cfg] 399 Alex, A., Patel, K., Clemm, A., Hares, S., Jethanandani, 400 M., and X. Liu, "Yang Data Model for BGP Protocol", draft- 401 zhdankin-idr-bgp-cfg-00 (work in progress), January 2015. 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, 407 "Policy Core Information Model -- Version 1 408 Specification", RFC 3060, February 2001. 410 [RFC3460] Moore, B., "Policy Core Information Model (PCIM) 411 Extensions", RFC 3460, January 2003. 413 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 414 Moore, "Policy Quality of Service (QoS) Information 415 Model", RFC 3644, November 2003. 417 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 418 Used to Form Encoding Rules in Various Routing Protocol 419 Specifications", RFC 5511, April 2009. 421 Authors' Addresses 423 Susan Hares 424 Huawei 425 7453 Hickory Hill 426 Saline, MI 48176 427 USA 429 Email: shares@ndzh.com 431 Qin Wu 432 Huawei 433 101 Software Avenue, Yuhua District 434 Nanjing, Jiangsu 210012 435 China 437 Email: bill.wu@huawei.com 439 Jeff Tantsura 440 Ericsson 442 Email: Jeff Tantsura jeff.tantsura@ericsson.com 444 Russ White 445 Ericsson 447 Email: russw@riw.us