idnits 2.17.1 draft-ietf-i2rs-pkt-eca-data-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 18 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 374 has weird spacing: '...on-info strin...' == Line 476 has weird spacing: '...-cnd-id uint3...' == Line 482 has weird spacing: '...vent-it uint1...' == Line 601 has weird spacing: '...payload uint3...' == Line 623 has weird spacing: '...load-id uint...' == (4 more instances...) -- The document date (October 5, 2016) is 2760 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) == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 2385, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-restconf' is defined on line 2390, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-acl-model' is defined on line 2395, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 2401, but no explicit reference was found in the text == Unused Reference: 'RFC7921' is defined on line 2420, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-09 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-17 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-08 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: April 8, 2017 R. White 6 Ericsson 7 October 5, 2016 9 Filter-Based Packet Forwarding ECA Policy 10 draft-ietf-i2rs-pkt-eca-data-model-02.txt 12 Abstract 14 This document describes the yang data model for packet forwarding 15 policy that filters received packets and forwards (or drops) the 16 packets. Prior to forwarding the packets out other interfaces, some 17 of the fields in the packets may be modified. If one considers the 18 packet reception an event, this packet policy is a minimalistic 19 Event-Match Condition-Action policy. This policy controls forwarding 20 of packets received by a routing device on one or more interfaces on 21 which this policy is enabled. The policy is composed of an ordered 22 list of policy rules. Each policy policy rule contains a set of 23 match conditions that filters for packets plus a set of actions to 24 modify the packet and forward packets. The match conditions can 25 match tuples in multiple layers (L1-L4, application), interface 26 received on, and and other conditions regarding the packet (size of 27 packet, time of day). The modify packet actions allow for setting 28 things within the packet plus decapsulation and encapsulation packet. 29 The forwarding actions include forwarding via interfaces, tunnels, or 30 nexthops and dropping the packet. The policy model can be used with 31 the session ephemeral (BGP Flow Specifications), reboot ephemeral 32 state (I2RS ephemeral), and non-ephemeral routing/forwarding state 33 (e.g. configuration state ). 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 8, 2017. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 70 1.2. Antecedents this Policy in IETF . . . . . . . . . . . . . 4 71 2. Generic Route Filters/Policy Overview . . . . . . . . . . . . 4 72 3. BNP Rule Groups . . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Packet ECA (event-condition-action) Filter Model in High 74 Level Yang . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.1. modules included . . . . . . . . . . . . . . . . . . . . 7 76 4.2. top level description . . . . . . . . . . . . . . . . . . 8 77 4.3. Conditional filters . . . . . . . . . . . . . . . . . . . 10 78 4.3.1. Event Match Filters . . . . . . . . . . . . . . . . . 11 79 4.3.2. ECA Packet Condition Matches . . . . . . . . . . . . 12 80 4.4. ECA Packet Actions . . . . . . . . . . . . . . . . . . . 19 81 4.5. Policy Conflict Resolution strategies . . . . . . . . . . 22 82 4.6. External Data . . . . . . . . . . . . . . . . . . . . . . 22 83 5. i2rs-eca-policy Yang module . . . . . . . . . . . . . . . . . 23 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 86 8. Informative References . . . . . . . . . . . . . . . . . . . 54 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 89 1. Introduction 91 This document describes the yang data model for packet forwarding 92 policy that filters received packets and forwards (or drops) the 93 packets. Prior to forwarding the packets out other interfaces, some 94 of the fields in the packets may be modified. If one considers the 95 reception of a packet as an event, this minimalistic Event-Match 96 Condition-Action policy. If one considers the reception of packets 97 containing Layer 1 to Layer 4 + application data a single packet, 98 then this minimalistic policy can be called a packet-only ECA policy. 99 This document will use the term packet-only ECA policy for this model 100 utilizing the term "packet" in this fashion. 102 This packet-only ECA policy data model supports an ordered list of 103 ECA policy rules where each policy rule has a name. The match 104 condition filters include matches on 106 o content of packet headers for layer 1 to layer 4, 108 o application protocol data and headers, 110 o interfaces the packet was received on, 112 o time packet was received, and 114 o size of packet. 116 The actions include packet modify actions and forwarding options. 117 The modify options allow for the following: 119 o setting fields in the packet header at Layer 2 (L2) to Layer 4 120 (L4), and 122 o encapsulation and decapsulation the packet. 124 The forwardingng actions allow forwardsing the packet via interfaces, 125 tunnels, next-hops, or dropping the packet. setting things within 126 the packet at Layer 2 (L2) to layer 4 (L4) plus overlay or 127 application data. 129 The first section of this draft contains an overview of the policy 130 structure. The second provides a high-level yang module. The third 131 contains the yang module. 133 The high-level yang and the actual yang are not aligned. This is an 134 interim-release of this document. 136 1.1. Definitions and Acronyms 138 INSTANCE: Routing Code often has the ability to spin up multiple 139 copies of itself into virtual machines. Each Routing code 140 instance or each protocol instance is denoted as Foo_INSTANCE in 141 the text below. 143 NETCONF: The Network Configuration Protocol 144 PCIM - Policy Core Information Model 146 RESTconf - http programmatic protocol to access yang modules 148 1.2. Antecedents this Policy in IETF 150 Antecedents to this generic policy are the generic policy work done 151 in PCIM WG. The PCIM work contains a Policy Core Information Model 152 (PCIM) [RFC3060], Policy Core Informational Model Extensions 153 [RFC3460] and the Quality of Service (QoS) Policy Information Model 154 (QPIM) ([RFC3644]) From PCIM comes the concept that policy rules 155 which are combined into policy groups. PCIM also refined a concept 156 of policy sets that allowed the nesting and aggregation of policy 157 groups. This generic model did not utilize the concept of sets of 158 groups, but could be expanded to include sets of groups in the 159 future. 161 2. Generic Route Filters/Policy Overview 163 This generic policy model represents filter or routing policies as 164 rules and groups of rules. 166 The basic concept are: 168 Policy set: 170 Policy set is a set of policies 172 Policy: 174 A policy is a is an ordered set of rules . 176 Rule 178 A Rule is represented by the semantics "If Condition then Action". 179 A Rule may have a priority assigned to it. 181 +-------------+ 182 | Policy Set | 183 +-^---------^-+ 184 | | 185 | | 186 +---------+ +---------+ 187 | policy | | rules |-=========|| 188 +---------+ +---------+ || 189 ^ || 190 | || 191 +-|----------+ || 192 | rule-list | || 193 +------------+ || 194 ^ ^ || 195 | | || 196 | | || 197 +-----^---+ +-----^--+ +---^-------+ || 198 | Rule |==| Rule |==| Rule |==|| 199 +---------+ +--------+ +-:------:---+ 200 : : 201 +-----------:+ +-:----------+ 202 | cfg-rule | | cfg rule | 203 | conditions | | Actions | 204 +--:-:-------+ +:---:-:--:--+ 205 : : : : : :................. 206 :...............: : : : :......... : 207 : : ......: : : : 208 : : : : : : 209 +:-------+ +-------V--+ +-V------+ +-V-----+ +-V-----+ +--V----+ 210 | Rule | | Rule | |eca- | |eca- | |eca- | |eca- | 211 | event | | Condition| |ingress-| |fwd- | |egress-| |qos- | ... 212 | match | | match | |actions | |actions| |actions| |actions| 213 +--------+ +--:---:---+ +--------+ +-------+ +-------+ +-------+ 214 : : 215 :........: : 216 : : 217 +----V----+ +-----V---------+ 218 |eca-event| | eca-condition | 219 | -match | | -match | 220 +---------+ +---------------+ 222 Figure 1: ECA rule structure 224 3. BNP Rule Groups 226 The pkt ECA policy is a policy whihc is an order set of pkt-ECA 227 policy rules. The rules assume the event is the reception of a 228 packet on the machine on a set of interfaces. This policy is 229 associated with a set of interfaces on a routing device (physical or 230 virtual). 232 A Policy allows for the easy combination of rules for management 233 stations or users. A policy has the following elements: 235 o name that identifies the grouping of policy rules 237 o module reference - reference to a yang module(s) in the yang 238 module library that this group of policy writes policy to 240 o list of rules 242 A policy group may have rulies at different order levels. For 243 example, policy group 1 could have three policy rules at rule order 1 244 and four policy rules at rule order 5. 246 The rule has the following elements: name, order, status, priority, 247 reference cnt, and match condition, and action as shown as shown in 248 figure 2. The order indicates the order of the rule within the the 249 complete list. The status of the rule is (active, inactive). The 250 priority is the priority within a specific order of policy/filter 251 rules. A reference count (refcnt) indicates the number of entities 252 (E.g. network modules) using this policy. The generic rule match- 253 action conditions have match operator, a match variable and a match 254 value. The rule actions have an action operator, action variable, 255 and an action value. 257 Rules can exist with the same rule order and same priority. Rules 258 with the same rule order and same priority are not guaranteed to be 259 at any specific ordering. The order number and priority have 260 sufficient depth that administrators who wish order can specify it. 262 The generic match conditions are specific to a particular layer are 263 refined by matches to a specific layer (as figure 2 shows), and 264 figure 5's high-level yang defines. The general actions may be 265 generic actions that are specific to a particular layer (L1, L2, L3, 266 service layer) or time of day or packet size. The qos actions can be 267 setting fields in the packet at any layer (L1-L4, service) or 268 encapsulating or decapsulating the packet at a layer. The fwd- 269 actions are forwarding functions that forward on an interface or to a 270 next-hop. The rule status is the operational status per rule. 272 +-----------------+ 273 | eca-pkt-matches | 274 +-------|---------+ 275 | 276 +-------------+-|-----------+-----------+ 277 | | | | 278 V V V V 279 ............ ............ ............ ........... 280 : L1 : : L2 : : L3 : : Service : . . . 281 : match : : match : : match : : match : 282 '''''''''''' '''''''''''' '''''''''''' ''''''''''' 284 Figure 2 match logic 286 4. Packet ECA (event-condition-action) Filter Model in High Level Yang 288 The description of packet event-condition-action data model include: 290 module included in module 292 top level diagram 294 4.1. modules included 296 Below is the high level module inclusions. 298 module:pkt-eca-policy 299 import ietf-inet-types {prefix "inet"} 300 import ietf-interface {prefix "if"} 301 import ietf-i2rs-rib {prefix "i2rs-rib"} 303 import ietf-interfaces { 304 prefix "if"; 305 } 306 import ietf-inet-types { 307 prefix inet; 308 //rfc6991 309 } 311 import ietf-i2rs-rib { 312 prefix "i2rs-rib"; 314 Figure 3 - high level inclusion 316 4.2. top level description 318 Below is the high level yang diagram 320 module ietf-pkt-eca-policy 321 +--rw pkt-eca-policy-cfg 322 | +--rw pkt-eca-policy-set 323 | +--rw policies* [policy-name] 324 | | +--rw policy-name string 325 | | +--rw vrf-name string 326 | | +--rw address-family 327 | | +--rw rule-list* [rule-name] 328 | | | +--rw rule-name 329 | | | +--rw rule-order-id uint16 330 | | | +--rw default-action-id integer 331 | | | +--rw default-resolution-strategy-id integer 332 | +--rw rules* [order-id rule-name] 333 | +--rw order-id uint16 334 | +--rw rule-name string 335 | +--rw policy-name string 336 | +--rw cfg-rule-conditions [rule-cnd-id] 337 | | +--rw rule-cnd-id uint32 338 | | +--rw support 339 | | | +--rw event-matches boolean 340 | | | +--rw pkt-matches boolean 341 | | | +--rw usr-context-matches boolean 342 | | +--rw eca-events-match* [rule-event-id] 343 | | | +--rw rule-event-it uint16 344 | | | | ... time-event match (see below) 345 | | +--rw eca-condition-match 346 | | | +--rw eca-pkt-matches* [pkt-match-id] 347 | | | | ...(see packet matches below) 348 | | | | ... (address, packet header, packet payload) 349 | | | +--rw eca-user-context-matches* [usr-match-id] 350 | | | | ... (see user context match below) 351 | +--rw cfg-rule-actions [cfgr-action-id] 352 | | +--rw cfgr-action-id 353 | | +--rw eca-actions* [action-id] 354 | | | +--rw action-id uint32 355 | | | +--rw eca-ingress-actions* 356 | | | | ... (permit, deny, mirror) 357 | | | +--rw eca-fwd-actions* 358 | | | | ... (invoke, tunnel encap, fwd) 359 | | | +--rw eca-egress-acttions* 360 | | | | .. . 361 | | | +--rw eca-qos-actions* 362 | | | | ... 364 | | | +--rw eca-security-actions* 365 | +--rw policy-conflict-resolution* [strategy-id] 366 | | +--rw strategy-id integer 367 | | +--rw filter-strategy identityref 368 | | | .. FMR, ADTP, Longest-match 369 | | +--rw global-strategy identityref 370 | | +--rw mandatory-strategy identityref 371 | | +--rw local-strategy identityref 372 | | +--rw resolution-fcn uint32 373 | | +--rw resolution-value uint32 374 | | +--rw resolution-info string 375 | | +--rw associated-ext-data* 376 | | | +--rw ext-data-id integer 377 | +--rw cfg-external-data* [cfg-ext-data-id] 378 | | +--rw cfg-ext-data-id integer 379 | | +--rw data-type integer 380 | | +--rw priority uint64 381 | | | uses external-data-forms 382 | | ... (other external data) 383 +--rw pkt-eca-policy-opstate 384 +--rw pkt-eca-opstate 385 +--rw policies-opstat* [policy-name] 386 | +--rw rules-installed; 387 | +--rw rules_opstat* [rule-name] 388 | +--rw strategy-used [strategy-id] 389 +--rw rules_opstate* [rule-order rule-name] 390 | +--rw status 391 | +--rw rule-inactive-reason 392 | +--rw rule-install-reason 393 | +--rw rule-installer 394 | +--rw refcnt 395 +--rw rules_pktstats* [rule-order rule-name] 396 | +--rw pkts-matched 397 | +--rw pkts-modified 398 | +--rw pkts-forward 399 +--rw op-external-data [op-ext-data-id] 400 | +--rw op-ext-data-id integer 401 | +--rw type identityref 402 | +--rw installed-priority integer 403 | | (other details on external data ) 405 figure 4 - high-level yang for policy set 407 The three levels of policy are expressed as: 409 Config Policy definitions 410 ======================================= 411 Policy level: pkt-eca-policy-set 412 group level: pkt-eca-policy-set:policies 413 rule level: pkt-eca-policy-set:rules 414 external id: pkt-eca-policy-set:cfg-external-data 416 Operational State for Policy 417 ======================================= 418 Policy level: pkt-eca-policy-opstate 419 group level: pkt-eca-opstate:policies-opstat* 420 rule level: pkt-eca-opstate:rules_opstat* 421 pkt-eca-opstate:rules-pktstat* 422 external id: pkt-eca-opstate:op-external-data* 424 figure 5 426 4.3. Conditional filters 428 The condition filters in the packet eca policy module included the 429 following: 431 o event filters - time as an augment to reception of a packet. 433 o conditional matches on packet content or user-related content 435 The sections below provide the high-level yang for these sections of 436 hte model. 438 module:i2rs-pkt-eca-policy 439 ..... 440 +--rw pkt-eca-policy-cfg 441 | +--rw pkt-eca-policy-set 442 | +--rw pkt-eca-policy-set 443 | | ... 444 | +--rw rules* [order-id rule-name] 445 | +--rw order-id uint16 446 | +--rw rule-name string 447 | +--rw policy-name string 448 | +--rw cfg-rule-conditions [rule-cnd-id] 449 | | +--rw rule-cnd-id integer 450 | | +--rw eca-events-match* [rule-event-id] 451 | | | +--rw rule-event-it uint16 452 | | | | ... time-event match (see below) 453 | | +--rw eca-condition-match 454 | | | +--rw eca-pkt-matches* [pkt-match-id] 455 | | | | ... (see L1-L4 matches below) 456 | | | +--rw eca-usr-context-matches* [usr-match-id] 457 | | | | (user, schedule, region, target, 458 | | | | state, direction) 460 Figure 6 462 4.3.1. Event Match Filters 464 The default event is the event of receiving a packet. In addition, 465 the events allow a time-event match. Time events are provided as a 466 list which includes specific times or ranges of time. 468 | +--rw pkt-eca-policy-set 469 | +--rw pkt-eca-policy-set 470 | | ... 471 | +--rw rules* [order-id rule-name] 472 | +--rw order-id uint16 473 | +--rw rule-name string 474 | +--rw policy-name string 475 | +--rw cfg-rule-conditions [rule-cnd-id] 476 | | +--rw rule-cnd-id uint32 477 | | +--rw support 478 | | | +--rw event-matches boolean 479 | | | +--rw pkt-matches boolean 480 | | | +--rw usr-context-matches boolean 481 | | +--rw eca-events-match* [rule-event-id] 482 | | | +--rw rule-event-it uint16 483 | | | +--rw time-type identityref 484 | | | +--(one-time) 485 | | | | +--rw event-time yang:date-and-time 486 | | | +--(range-time) 487 | | | +--rw event-start-time yang:date-and-time 488 | | | +--rw event-end-time yang:date-and-time 490 figure 7 492 4.3.2. ECA Packet Condition Matches 494 The ECA condition matches are packet matches (eca) 496 4.3.2.1. Packet-match filter list (eca-pkt-match*) 498 The packet match content filters include: address filters and packet 499 header content filters, and packet payload filters. 501 module:i2rs-pkt-eca-policy 502 +--pkt-eca-policy-set 503 +--rw rules* [order-id rule-name] 504 | |.... 505 | +--rw cfg-rule-conditions [rule-cnd-id] 506 | | +--rw rule-cnd-id uint32 507 | | +--rw support 508 | | | +--rw event-matches boolean 509 | | | +--rw pkt-matches boolean 510 | | | +--rw usr-context-matches boolean 511 | | +--rw eca-event-match 512 | | | ... 513 | | +--rw eca-condition-match 514 | | +--rw eca-pkt-matches* [pkt-match-id] 515 | | | +--rw packet-match-id uint16 516 | | | +--rw packet-match-type identityref 517 | | | +--(packet-match-type)? 518 | | | | +--:(address-pkt-match) 519 | | | | | ... 520 | | | | +--:(layer-pkt-match) 521 | | | | | ... 522 | | | | +--:(payload-pkt-match) 523 | | | | | ... 524 | | +--rw eca-user-matches [user-match-id] 526 Figure 8 528 4.3.2.1.1. Match filters for addresses in packet 530 The address matches match the L3, mpls, MAC and interface address 531 scope. Figure x shows this match 532 +--rw eca-pkt-matches* [pkt-match-id] 533 | +--rw packet-match-id uint16 534 | +--rw eca-pkt-match-type identityref 535 | +--address-scope? 536 | | +--:(route-type) 537 | | | +--: (ipv4) 538 | | | | ... src, dest, src-dest 539 | | | +--: (ipv6) 540 | | | | ... src, dest, src-dest 541 | | | +--: (mpls) 542 | | | | ... 32 bit label 543 | | | +--: (mac) 544 | | | | ... src, dest, src-dest 545 | | | +--: (interface-route) 546 | | | | .... interface 548 Figure 9 550 4.3.2.1.2. Packet header matches 552 The packet header matches match interface, L1-L4 headers, service 553 chain headers, and packet size. The L1 header expected to be a null 554 match except if there is an advanced L1 technology such as l1 with a 555 L1 identifier that can be detected in the packet. Figure x shows 556 these matches. 558 | +--rw (layer-type) 559 | | +--:(interface-match-type) 560 | | | |... 561 | | +--:(L1-header-match) 562 | | | |... 563 | | +--:(L2-header-match) 564 | | | +--(802.1Q) 565 | | | |.... 566 | | | +--(802.11) 567 | | | | ... 568 | | | +--(802.15) 569 | | | | ... 570 | | | +--(NVGRE) 571 | | | | ... 572 | | | +--(VXLAN) 573 | | | | ... 574 | | | +--(MPLS ) 575 | | | | .. 576 | | +--:(L3-header-match) 577 | | | +--(l3-ipv4-header) 578 | | | | ... 579 | | | +--(l3-ipv6-header) 580 | | | | ... 581 | | | +--(l3-gre-header) 582 | | | | ... 583 | | +--: L4-header-match 584 | | | +--(l4-tcp-header) 585 | | | | ... 586 | | | +--(l4-udp-header) 587 | | | | ... 588 | | | +--(l4-sctp-header) 589 | | | | ... 590 | | | +--: Service-header-match 591 | | | +--(sf-chain-meta-match) 592 | | | ... 593 | | | +--(sf-path-meta-match) 594 | | | .. 595 | | +--:(packet-size) 596 | | +--l1-size-match uint32 597 | | +--l2-size-match uint32 598 | | +--l3-size-match uint32 599 | | +--l4-size-mtach uint32 600 | | +--service-meta-size uint32 601 | | +--leaf service-meta-payload uint32 602 | +---rw packet 604 Figure 10 606 4.3.2.1.3. Payload matches 608 The payload information is a stream of bytes to be found in the 609 packet payload beyond the L4 or service-path header. The structure 610 of this data is simply a list of byte strings as figure x shows. 612 | | |.... 613 | | +--rw eca-pkt-matches* [pkt-match-id] 614 | | | +--rw packet-match-id uint16 615 | | | +--rw packet-match-type identityref 616 | | | +--(packet-match-type)? 617 | | | | +--:(address-pkt-match) 618 | | | | | ... 619 | | | | +--:(layer-pkt-match) 620 | | | | | ... 621 | | | | +--:(payload-pkt-match) 622 | | | | | +--rw packet-payload *[packet-payload-id] 623 | | | | | +--rw packet-payload-id uint16 624 | | | | | +--rw payload-match-bytes uint16 625 | | | | | +--rw packet-payload string 627 Figure 11 629 4.3.2.2. Matches on User Context 631 The match on user context allows filtering for a packet plus a filter 632 related to a user. 634 Since not all I2RS routers are access routers, the support for 635 matches has a flag for user filter. It is expected that core routers 636 may not support contextual matching. 638 One example of user filters is for is parental controls. During 639 school hours, the teenager Joe is restrict from certain web sites 640 from September 1 while Joe is at at school. This "school" filter is 641 an example of a period filter which has a start time (8:00am) and end 642 time (3:30pm), which is valid beginning September 1, 2016. This 643 filter applies only to the region of school networks. The filter 644 looks for specific entertainment (e.g. YouTube) web sites, social- 645 media (e.g. facebook), and gaming sites. This block is for their 646 mobile phone and tablet, but not the computer that says at home. 648 The following is the components 650 o user identifier (name, tenant id, virtual network), 652 o schedule for the user filter (once or periodic, time range (start/ 653 end), and weekly validity check), 655 o region this filter is valid. 657 o targeted services, applications, devices, and state. 659 module:i2rs-pkt-eca-policy 660 ..... 661 +--rw pkt-eca-policy-cfg 662 | +--rw pkt-eca-policy-set 663 | +--rw pkt-eca-policy-set 664 | | ... 665 | +--rw rules* [order-id rule-name] 666 | +--rw order-id uint16 667 | +--rw rule-name string 668 | +--rw policy-name string 669 | +--rw cfg-rule-conditions [rule-cnd-id] 670 | | +--rw rule-cnd-id uint32 671 | | | ... 672 | | +--rw eca-event-match* [rule-event-id] 673 | | | .. 674 | | +--rw eca-pkt-matches* [pkt-match-id] 675 | | | .... 676 | | +--rw eca-usr-context-matches* [usr-match-id] 677 | | | +--rw user* [user-id] 678 | | | | +--rw user-id uint32 679 | | | | +--rw user-name string 680 | | | | +--rw user-type identityref 681 | | | | | +--(user-type)? 682 | | | | | | +--:(tenant) 683 | | | | | | | +--rw tenant-id uint16 684 | | | | | | +--:(vn-id) 685 | | | | | | | +--rw vn-id uint16 686 | | | +--rw schedule* [schedule-name] 687 | | | | ..... 688 | | | +--rw target 689 | | | | +--rw protocol 690 | | | | | ... (UDP, TCP, ICMP, ICMPv6, IP, IPv6) 691 | | | | +--rw transport-ports 692 | | | | | +--rw src-port inet:port-number 693 | | | | | +--rw dest-port intent:port-number 694 | | | | +--service [service-name] 695 | | | | |... 696 | | | | +--rw application 697 | | | | |... 698 | | | | +--rw device 699 | | | | | .. 701 Figure 12 703 Schedule filters allow a time for the filter. Continuing our 704 parental control filters for school, the schedule an be a list of 705 weekly filters for Monday-Friday of the school week. The first 706 filter (School-Monday) would have a of start time of 8:00am GMT 707 September 5, 2016 an end time of 4:00pm GMT September 5, 2016. The 708 schedule type woudl be weekly. The validity-until time would be 709 December 20, 2016. The region impacted by this schedule would be 710 AS20999 which is the service provider of the school's network. 712 +--rw pkt-eca-policy-cfg 713 | +--rw pkt-eca-policy-set 714 | +--rw pkt-eca-policy-set 715 | | ... 716 | +--rw rules* [order-id rule-name] 717 | +--rw order-id uint16 718 | +--rw rule-name string 719 | +--rw policy-name string 720 | +--rw cfg-rule-conditions [rule-cnd-id] 721 | | +--rw rule-cnd-id uint32 722 | | +--rw eca-usr-context-matches* [usr-match-id] 723 | | | +--rw schedule* [schedule-name] 724 | | | | +--rw schedule-name 725 | | | | +--rw schedule-type identityref /* one-time, weekly, 2 weeks, monthly */ 726 | | | | +--rw start-type? yang:date-and-time 727 | | | | +--rw end-type? yang:date-and-time 728 | | | | +--rw validity-until yang:date-and-time /* valid until */ 729 | | | +--rw region *[as-4byte] 730 | | | | +--rw as-4byte uint32 /* region */ 732 figure 13 734 The target for this service filtering is specified by protocols, 735 applications, and devices. The figure below shows the filtering for 736 a target protocol and port number or an application. 738 +--rw pkt-eca-policy-cfg 739 | +--rw pkt-eca-policy-set 740 | +--rw pkt-eca-policy-set 741 | | ... 742 | +--rw rules* [order-id rule-name] 743 | +--rw order-id uint16 744 | +--rw rule-name string 745 | +--rw policy-name string 746 | +--rw cfg-rule-conditions [rule-cnd-id] 747 | | +--rw rule-cnd-id uint32 748 | | +--rw eca-usr-context-matches* [usr-match-id] 749 | | | +--rw target 750 | | | | +--rw service* [svc-id svc-name] 751 | | | | | +--rw svc-id uint16 752 | | | | | +--rw svc-name string 753 | | | | | +--rw protocol-support 754 | | | | | | +--rw TCP boolean 755 | | | | | | +--rw UDP boolean 756 | | | | | | +--rw ICMP boolean 757 | | | | | | +--rw ICMPv6 boolean 758 | | | | | | +--rw IP boolean 759 | | | | | +--rw src-port? inet:port-number 760 | | | | | +--rw dest-port? inet_port-number 761 | | | | +--rw application* [app-name] 762 | | | | | +--rw app-name string 763 | | | | | +--rw app-id uint16 764 | | | | | +--rw app-category 765 | | | | | /* business, educational, internet */ 766 | | | | | +--rw app-subcategory 767 | | | | | /* finance, email, game, social-net, web */ 768 | | | | | +--rw app-data-transmission 769 | | | | | /* client-server, web-brower, p2p, network */ 770 | | | | | +--rw app-risk-level 771 | | | | | /* exploitable, evasive, data-lost, malware-vehicle, tun 772 | | | | +--rw device 773 | | | | | +--rw pc boolean 774 | | | | | +--rw mobile-phone boolean 775 | | | | | +--rw tablet boolean 776 | | | | | +--rw voip-phone boolean 778 Figure 14 780 4.4. ECA Packet Actions 782 The packet actions list includes ingress actions,egress actions, Qos 783 actions that modify the packet, and security actions. The High level 784 Yang that shows where the action fit is in figure 15, and the details 785 are shown in figure 16. The QoS actions per header is shown in 786 figure 17. 788 module ietf-pkt-eca-policy 789 +--rw pkt-eca-policy-cfg 790 | +--rw pkt-eca-policy-set 791 | +--rw policies* [policy-name] 792 | | +--rw policy-name string 793 | | +--rw vrf-name string 794 | | +--rw address-family 795 | | +--rw rule-list* [rule-name] 796 | | | +--rw rule-name 797 | | | +--rw rule-order-id uint16 798 | | | +--rw default-action-id integer 799 | | | +--rw default-resolution-strategy-id integer 800 | +--rw rules* [order-id rule-name] 801 | +--rw order-id uint16 802 | +--rw rule-name string 803 | +--rw cfg-rule-conditions [rule-cnd-id] 804 | | ... 805 | +--rw cfg-rule-actions* [cfgr-action-id] 806 | | +--rw cfgr-action-id 807 | | +--rw eca-actions* [action-id] 808 | | | +--rw action-id uint32 809 | | | +--rw eca-ingress-actions 810 | | | | ... (permit, deny, mirror) 811 | | | +--rw eca-fwd-actions* 812 | | | | ... (invoke, tunnel encap, fwd) 813 | | | +--rw eca-egress-actions* 814 | | | | () 815 | | | +--rw eca-qos-actions* 816 | | | | ... 817 | | | +--rw eca-security-actions* 819 Figure 15 821 This figure shows the details for each action section (ingress, 822 egress, qos, and security). 824 | +--rw eca-ingress-actions 825 | | +--rw num-fwd-actions 826 | | +--rw fwd-actions 827 | | | +--rw permit boolean 828 | | | +--rw mirror boolean 829 | | | +--rw interface-fwd ip:interface-ref 830 | | | +--uses i2rs:rib-nexthop 831 | | | +--uses ip-next-fwd; 832 | +--rw eca-egress-actions 833 | | +--rw packet-rate uint32 834 | | +--rw byte-rate uint32 835 | | +--rw tunnel-encap boolean 836 | | +--rw exit-fwding boolean 837 | | +--rw interface-egress ip:interface-ref 838 | | +--uses i2rs:rib-nexthop 839 | | +--uses ip-next-fwd; 840 | +--rw eca-qos-actions 841 | | ... (see figure x below ) 842 | +--rw eca-security 843 | 844 | | +--rw security-action-type identityref 845 | | +--(security-action-type)? 846 | | +--:(content-security-action) ANYXML 847 | | | ... 848 | | +--:(attack-mitigation-type) ANYXML 849 | | | .. 850 | | +--:(single-packet-type) ANYXML 852 figure 16 - forwarding 854 > The QOS actions modify the headers are shown below. 856 | +--rw ecq-qos-actions 857 | | +--rw cnt-actions uint8 /* modifying actions */ 858 | | +--rw mod-actions 859 | | | +--case interface-actions 860 | | | | .. 861 | | | +--case L1-action 862 | | | | .. 863 | | | +--case L2-action 864 | | | | .. 865 | | | +--case L3-action 866 | | | | .. 867 | | | +--case L4-action 868 | | | | .. 869 | | | +--case service-action 870 | | | | .. 872 Figure 17 874 4.5. Policy Conflict Resolution strategies 876 Some policies within the filter-base policy will conflict. For 877 example, a global strategy may conflict with a local node strategy. 878 This portion of the filter-based data model provides this support. 880 | +--rw pc-resolution-strategies* [strategy-id] 881 | | +--rw strategy-id integer 882 | | +--rw pc-resolution-supported boolean 883 | | +--rw filter-strategy identityref 884 | | | .. FMR, ADTP, Longest-match 885 | | +--rw global-strategy identityref 886 | | +--rw mandatory-strategy identityref 887 | | +--rw local-strategy identityref 888 | | +--rw resolution-fcn uint32 889 | | +--rw resolution-value uint32 890 | | +--rw resolution-info string 891 | | +--rw associated-ext-data* 892 | | | +--rw ext-data-id integer 894 Figure 18 896 4.6. External Data 898 External data may be used to set the policy. 900 | +--rw cfg-external-data* [cfg-ext-data-id] 901 | | +--rw cfg-ext-data-id integer 902 | | +--rw data-type integer 903 | | +--rw priority uint64 904 | | +--rw external-data-forms anyxml /* mount point */ 906 Figure 19 908 5. i2rs-eca-policy Yang module 910 file "ietf-pkt-eca-policy@2016-02-09.yang" 911 module ietf-pkt-eca-policy { 912 namespace "urn:ietf:params:xml:ns:yang:ietf-pkt-eca-policy"; 913 // replace with iana namespace when assigned 914 prefix "pkt-eca-policy"; 916 import ietf-routing { 917 prefix "rt"; 918 } 919 import ietf-interfaces { 920 prefix "if"; 921 } 922 import ietf-inet-types { 923 prefix inet; 924 //rfc6991 925 } 927 import ietf-i2rs-rib { 928 prefix "i2rs-rib"; 929 } 931 // meta 932 organization "IETF I2RS WG"; 934 contact 935 "email: shares@ndzh.com 936 email: russ.white@riw.com 937 email: linda.dunbar@huawei.com 938 email: bill.wu@huawei.com"; 940 description 941 "This module describes a basic network policy 942 model with filter per layer."; 944 revision "2016-06-26" { 945 description "sec ond revision"; 946 reference "draft-ietf-i2rs-pkt-eca-policy-dm-03"; 948 } 950 // interfaces - no identity matches 952 // L1 header match identities 953 identity l1-header-match-type { 954 description 955 " L1 header type for match "; 956 } 958 identity l1-hdr-sonet-type { 959 base l1-header-match-type; 960 description 961 " L1 header sonet match "; 962 } 964 identity l1-hdr-OTN-type { 965 base l1-header-match-type; 966 description 967 " L1 header OTN match "; 968 } 970 identity l1-hdr-dwdm-type { 971 base l1-header-match-type; 972 description 973 " L1 header DWDM match "; 974 } 976 // L2 header match identities 977 identity l2-header-match-type { 978 description 979 " l2 header type for match "; 980 } 982 identity l2-802-1Q { 983 base l2-header-match-type; 984 description 985 " l2 header type for 802.1Q match "; 986 } 988 identity l2-802-11 { 989 base l2-header-match-type; 990 description 991 " l2 header type for 802.11 match "; 992 } 993 identity l2-802-15 { 994 base l2-header-match-type; 995 description 996 " l2 header type for 802.15 match "; 997 } 999 identity l2-NVGRE { 1000 base l2-header-match-type; 1001 description 1002 " l2 header type for NVGRE match "; 1003 } 1004 identity l2-mpls { 1005 base l2-header-match-type; 1006 description 1007 " l2 header type for MPLS match "; 1008 } 1010 identity l2-VXLAN { 1011 base l2-header-match-type; 1012 description 1013 " l2 header type for VXLAN match "; 1014 } 1016 // L3 header match identities 1017 identity l3-header-match-type { 1018 description 1019 " l3 header type for match "; 1020 } 1022 identity l3-ipv4-hdr { 1023 base l3-header-match-type; 1024 description 1025 " l3 header type for IPv4 match "; 1026 } 1028 identity l3-ipv6-hdr { 1029 base l3-header-match-type; 1030 description 1031 " l3 header type for IPv6 match "; 1032 } 1034 identity l3-gre-tunnel { 1035 base l3-header-match-type; 1036 description "l3 header r 1037 type for GRE tunnel match "; 1038 } 1039 identity l3-icmp-header { 1040 base l3-header-match-type; 1041 description "L3 header match for ICMP"; 1042 } 1044 identity l3-ipsec-ah-header { 1045 base l3-header-match-type; 1046 description "AH IPSEC header "; 1047 } 1049 identity l3-ipsec-esp-header { 1050 base l3-header-match-type; 1051 description "AH IPSEC header "; 1052 } 1054 // L4 header match identities 1056 identity l4-header-match-type { 1057 description "L4 header 1058 match types. (TCP, UDP, 1059 SCTP, UDPLite, etc. )"; 1060 } 1062 identity l4-tcp-header { 1063 base l4-header-match-type; 1064 description "L4 header for TCP"; 1065 } 1067 identity l4-udp-header { 1068 base l4-header-match-type; 1069 description "L4 header match for UDP"; 1070 } 1072 identity l4-udplite { 1073 base l4-header-match-type; 1074 description "L4 header match for 1075 UDP lite"; 1076 } 1078 identity l4-sctp-header { 1079 base l4-header-match-type; 1080 description "L4 header match for SCTP"; 1081 } 1083 // Service header identities 1085 identity service-header-match-type { 1086 description "service header 1087 match types: service function path 1088 (sf-path)), SF-chain, sf-discovery, 1089 and others (added here)"; 1090 } 1092 identity sf-chain-meta-match { 1093 base service-header-match-type; 1094 description "service header match for 1095 meta-match header"; 1096 } 1098 identity sf-path-meta-match { 1099 base service-header-match-type; 1100 description "service header match for 1101 path-match header"; 1102 } 1104 identity rule-status-type { 1105 description "status 1106 values for rule: invalid (0), 1107 valid (1), valid and installed (2)"; 1108 } 1110 identity rule-status-invalid { 1111 base rule-status-type; 1112 description "invalid rule status."; 1113 } 1115 identity rule-status-valid { 1116 base rule-status-type; 1117 description "This status indicates 1118 a valid rule."; 1120 } 1122 identity rule-status-valid-installed { 1123 base rule-status-type; 1124 description "This status indicates 1125 an installed rule."; 1126 } 1127 identity rule-status-valid-inactive { 1128 base rule-status-type; 1129 description "This status indicates 1130 a valid ruled that is not installed."; 1131 } 1133 identity rule-cr-type { 1134 description "status 1135 values for rule: FMR (0), ADTP (1), 1136 Longest-match (2)"; 1137 } 1139 identity rule-cr-FMR { 1140 base rule-cr-type; 1141 description "first match resolution."; 1142 } 1144 identity rule-cr-ADTP { 1145 base rule-cr-type; 1146 description "ADTP resolution."; 1147 } 1149 identity rule-cr-longest { 1150 base rule-cr-type; 1151 description "longest match resolution."; 1152 } 1154 grouping interface-match { 1155 leaf match-if-name { 1156 type if:interface-ref; 1157 description "match on interface name"; 1158 } 1159 description "interface 1160 has name, description, type, enabled 1161 as potential matches"; 1162 } 1164 grouping interface-actions { 1165 description 1166 "interface action up/down and 1167 enable/disable"; 1168 leaf interface-up { 1169 type boolean; 1170 description 1171 "action to put interface up"; 1172 } 1173 leaf interface-down { 1174 type boolean; 1175 description 1176 "action to put interface down"; 1177 } 1178 leaf interface-enable { 1179 type boolean; 1180 description 1181 "action to enable interface"; 1182 } 1183 leaf interface-disable { 1184 type boolean; 1185 description 1186 "action to disable interface"; 1187 } 1188 } 1190 grouping L1-header-match { 1191 choice l1-header-match-type { 1192 case l1-hdr-sonet-type { 1193 // sonet matches 1194 } 1195 case L1-hdr-OTN-type { 1196 // OTN matches 1197 } 1198 case L1-hdr-dwdm-type { 1199 // DWDM matches 1200 } 1201 description 1202 "The Layer 1 header match choices"; 1203 } 1204 description 1205 "The Layer 1 header match includes 1206 any reference to L1 technology"; 1207 } 1209 grouping L1-header-actions { 1210 leaf l1-hdr-sonet-act { 1211 type uint8; 1212 description "sonet actions"; 1213 } 1214 leaf l1-hdr-OTN-act { 1215 type uint8; 1216 description "OTN actions"; 1217 } 1218 leaf l1-hdr-dwdm-act { 1219 type uint8; 1220 description "DWDM actions"; 1221 } 1222 description "L1 header match 1223 types"; 1224 } 1226 grouping L2-802-1Q-header { 1227 description 1228 "This is short-term 802.1 header 1229 match which will be replaced 1230 by reference to IEEE yang when 1231 it arrives. Qtag 1 is 802.1Q 1232 Qtag2 is 802.1AD"; 1234 leaf vlan-present { 1235 type boolean; 1236 description " Include VLAN in header"; 1237 } 1238 leaf qtag1-present { 1239 type boolean; 1240 description " This flag value indicates 1241 inclusion of one 802.1Q tag in header"; 1242 } 1243 leaf qtag2-present{ 1244 type boolean; 1245 description "This flag indicates the 1246 inclusion of second 802.1Q tag in header"; 1247 } 1249 leaf dest-mac { 1250 type uint64; //change to uint48 1251 description "IEEE destination MAC value 1252 from the header"; 1253 } 1254 leaf src-mac { 1255 type uint64; //change to uint48 1256 description "IEEE source MAC 1257 from the header"; 1259 } 1260 leaf vlan-tag { 1261 type uint16; 1262 description "IEEE VLAN Tag 1263 from the header"; 1264 } 1265 leaf qtag1 { 1266 type uint32; 1267 description "Qtag1 value 1268 from the header"; 1269 } 1270 leaf qtag2 { 1271 type uint32; 1272 description "Qtag1 value 1273 from the header"; 1274 } 1275 leaf L2-ethertype { 1276 type uint16; 1277 description "Ether type 1278 from the header"; 1279 } 1280 } 1282 grouping L2-VXLAN-header { 1283 container vxlan-header { 1284 uses i2rs-rib:ipv4-header; 1285 leaf vxlan-network-id { 1286 type uint32; 1287 description "VLAN network id"; 1288 } 1289 description " choices for 1290 L2-VLAN header matches. 1291 Outer-header only. 1292 Need to fix inner header. "; 1293 } 1294 description 1295 "This VXLAN header may 1296 be replaced by actual VXLAN yang 1297 module reference"; 1298 } 1300 grouping L2-NVGRE-header { 1302 container nvgre-header { 1303 uses L2-802-1Q-header; 1304 uses i2rs-rib:ipv4-header; 1305 leaf gre-version { 1306 type uint8; 1307 description "L2-NVGRE GRE version"; 1308 } 1309 leaf gre-proto { 1310 type uint16; 1311 description "L2-NVGRE protocol value"; 1312 } 1313 leaf virtual-subnet-id { 1314 type uint32; 1315 description "L2-NVGRE subnet id value"; 1316 } 1317 leaf flow-id { 1318 type uint16; 1319 description "L2-NVGRE Flow id value"; 1320 } 1321 // uses L2-802-1Q-header; 1323 description 1324 "This NVGRE header may 1325 be replaced by actual NVGRE yang 1326 module reference"; 1327 } 1328 description "Grouping for 1329 L2 NVGRE header."; 1330 } 1332 grouping L2-header-match { 1334 choice l2-header-match-type { 1335 case l2-802-1Q { 1336 uses L2-802-1Q-header; 1337 } 1338 case l2-802-11 { 1339 // matches for 802.11 headers 1340 } 1341 case l2-802-15 { 1342 // matches for 802.1 Ethernet 1343 } 1344 case l2-NVGRE { 1345 // matches for NVGRE 1346 uses L2-NVGRE-header; 1347 } 1348 case l2-VXLAN-header { 1349 uses L2-VXLAN-header; 1350 } 1351 case l2-mpls-header { 1352 uses i2rs-rib:mpls-header; 1353 } 1354 description "Choice of L2 1355 headers for L2 match"; 1356 } 1357 description 1358 " The layer 2 header match includes 1359 any reference to L2 technology"; 1360 } 1362 grouping L2-NVGRE-mod-acts { 1363 // actions for NVGRE 1364 leaf set-vsid { 1365 type boolean; 1366 description 1367 "Boolean flag to set VSID in packet"; 1368 } 1369 leaf set-flowid { 1370 type boolean; 1371 description 1372 "Boolean flag to set VSID in packet"; 1373 } 1374 leaf vsi { 1375 type uint32; 1376 description 1377 "VSID value to set in packet"; 1378 } 1379 leaf flow-id { 1380 type uint16; 1381 description 1382 "flow-id value to set in packet"; 1383 } 1384 description "L2-NVRE Actions"; 1385 } 1387 grouping L2-VXLAN-mod-acts { 1388 leaf set-network-id { 1389 type boolean; 1390 description 1391 "flag to set network id in packet"; 1392 } 1393 leaf network-id { 1394 type uint32; 1395 description 1396 "network id value to set in packet"; 1397 } 1398 description "VXLAN header 1399 modification actions."; 1400 } 1402 grouping L2-mpls-mod-acts { 1403 leaf pop { 1404 type boolean; 1405 description 1406 "Boolean flag to pop mpls header"; 1407 } 1408 leaf push { 1409 type boolean; 1410 description 1411 "Boolean flag to push value into 1412 mpls header"; 1413 } 1414 leaf mpls-label { 1415 type uint32; 1416 description 1417 "mpls label to push in header"; 1419 } 1420 description "MPLS modify 1421 header actions"; 1422 } 1424 grouping l2-header-mod-actions { 1425 leaf l2-802-1Q { 1426 type uint8; 1427 description "actions for 802.1Q"; 1428 } 1429 leaf l2-802-11 { 1430 type uint8; 1431 description "actions for 802.11"; 1432 } 1433 leaf l2-802-15 { 1434 type uint8; 1435 description "ations for 802.15"; 1436 } 1438 uses L2-NVGRE-mod-acts; 1439 uses L2-VXLAN-mod-acts; 1440 uses L2-mpls-mod-acts; 1442 description 1443 " The layer 2 header match includes 1444 any reference to L2 technology"; 1445 } 1447 grouping L3-header-match { 1449 choice L3-header-match-type { 1450 case l3-ipv4-hdr { 1451 uses i2rs-rib:ipv4-header; 1452 } 1453 case l3-ipv6-hdr { 1454 uses i2rs-rib:ipv6-header; 1455 } 1456 case L3-gre-tunnel { 1457 uses i2rs-rib:gre-header; 1458 } 1459 description "match for L3 1460 headers for IPv4, IPv6, 1461 and GRE tunnels"; 1462 } 1463 description "match for L3 headers"; 1464 } 1466 grouping ipv4-encapsulate-gre { 1467 leaf encapsulate { 1468 type boolean; 1469 description "flag to encapsulate headers"; 1470 } 1471 leaf ipv4-dest-address { 1472 type inet:ipv4-address; 1473 description "Destination Address for GRE header"; 1474 } 1475 leaf ipv4-source-address { 1476 type inet:ipv4-address; 1477 description "Source Address for GRE header"; 1478 } 1479 description "encapsulation actions for IPv4 headers"; 1480 } 1482 grouping L3-header-actions { 1483 choice l3-header-act-type { 1484 case l3-ipv4-hdr { 1485 leaf set-ttl { 1486 type boolean; 1487 description "flag to set TTL"; 1488 } 1489 leaf set-dscp { 1490 type boolean; 1491 description "flag to set DSCP"; 1492 } 1493 leaf ttl-value { 1494 type uint8; 1495 description "TTL value to set"; 1496 } 1497 leaf dscp-val { 1498 type uint8; 1499 description "dscp value to set"; 1500 } 1501 } 1502 case l3-ipv6-hdr { 1503 leaf set-next-header { 1504 type boolean; 1505 description 1506 "flag to set next routing 1507 header in IPv6 header"; 1508 } 1509 leaf set-traffic-class { 1510 type boolean; 1511 description 1512 "flag to set traffic class 1513 in IPv6 header"; 1515 } 1516 leaf set-flow-label { 1517 type boolean; 1518 description 1519 "flag to set flow label 1520 in IPv6 header"; 1521 } 1522 leaf set-hop-limit { 1523 type boolean; 1524 description "flag 1525 to set hop limit in 1526 L3 packet"; 1527 } 1528 leaf ipv6-next-header { 1529 type uint8; 1530 description "value to 1531 set in next IPv6 header"; 1532 } 1533 leaf ipv6-traffic-class { 1534 type uint8; 1535 description "value to set 1536 in traffic class"; 1538 } 1539 leaf ipv6-flow-label { 1540 type uint16; 1541 description "value to set 1542 in IPOv6 flow label"; 1543 } 1544 leaf ipv6-hop-limit { 1545 type uint8; 1546 description "value to set 1547 in hop count"; 1548 } 1549 } 1551 case L3-gre-tunnel { 1552 leaf decapsulate { 1553 type boolean; 1554 description "flag to 1555 decapsulate GRE packet"; 1556 } 1557 description "GRE tunnel 1558 actions" ; 1559 } 1560 description "actions that can 1561 be performed on L3 header"; 1562 } 1563 description "actions to 1564 be performed on L3 header"; 1565 } 1567 grouping tcp-header-match { 1568 leaf tcp-src-port { 1569 type uint16; 1570 description "source port match value"; 1571 } 1572 leaf tcp-dst-port { 1573 type uint16; 1574 description "dest port value 1575 to match"; 1576 } 1577 leaf sequence-number { 1578 type uint32; 1579 description "sequence number 1580 value to match"; 1581 } 1582 leaf ack-number { 1583 type uint32; 1584 description "action value to 1585 match"; 1586 } 1587 description "match for TCP 1588 header"; 1589 } 1591 grouping tcp-header-action { 1592 leaf set-tcp-src-port { 1593 type boolean; 1594 description "flag to set 1595 source port value"; 1596 } 1597 leaf set-tcp-dst-port { 1598 type boolean; 1599 description "flag to set source port value"; 1600 } 1602 leaf tcp-s-port { 1603 type uint16; 1604 description "source port match value"; 1605 } 1606 leaf tcp-d-port { 1607 type uint16; 1608 description "dest port value 1609 to match"; 1611 } 1612 leaf seq-num { 1613 type uint32; 1614 description "sequence number 1615 value to match"; 1616 } 1617 leaf ack-num { 1618 type uint32; 1619 description "action value to 1620 match"; 1621 } 1622 description "Actions to 1623 modify TCP header"; 1624 } 1626 grouping udp-header-match { 1627 leaf udp-src-port { 1628 type uint16; 1629 description "UDP source 1630 port match value"; 1631 } 1632 leaf udp-dst-port { 1633 type uint16; 1634 description "UDP Destination 1635 port match value"; 1636 } 1637 description "match values for 1638 UDP header"; 1640 } 1642 grouping udp-header-action { 1643 leaf set-udp-src-port { 1644 type boolean; 1645 description "flag to set 1646 UDP source port match value"; 1647 } 1648 leaf set-udp-dst-port { 1649 type boolean; 1650 description 1651 "flag to set UDP destination port match value"; 1652 } 1653 leaf udp-s-port { 1654 type uint16; 1655 description "UDP source 1656 port match value"; 1657 } 1658 leaf udp-d-port { 1659 type uint16; 1660 description "UDP Destination 1661 port match value"; 1662 } 1664 description "actions to set 1665 values in UDP header"; 1666 } 1668 grouping sctp-chunk { 1669 leaf chunk-type { 1670 type uint8; 1671 description "sctp chunk type value"; 1672 } 1673 leaf chunk-flag { 1674 type uint8; 1675 description "sctp chunk type 1676 flag value"; 1677 } 1679 leaf chunk-length { 1680 type uint16; 1681 description "sctp chunk length"; 1682 } 1684 leaf chunk-data-byte-zero { 1685 type uint32; 1686 description "byte zero of 1687 stcp chunk data"; 1688 } 1689 description "sctp chunck 1690 header match fields"; 1691 } 1693 grouping sctp-header-match { 1694 uses sctp-chunk; 1695 leaf stcp-src-port { 1696 type uint16; 1697 description "sctp header match 1698 source port value"; 1699 } 1700 leaf sctp-dst-port { 1701 type uint16; 1702 description "sctp header match 1703 destination port value"; 1704 } 1705 leaf sctp-verify-tag { 1706 type uint32; 1708 description "sctp header match 1709 verification tag value"; 1710 } 1711 description "SCTP header 1712 match values"; 1713 } 1715 grouping sctp-header-action { 1716 leaf set-stcp-src-port { 1717 type boolean; 1718 description "set source port in sctp header"; 1719 } 1720 leaf set-stcp-dst-port { 1721 type boolean; 1722 description "set destination port in sctp header"; 1723 } 1724 leaf set-stcp-chunk1 { 1725 type boolean; 1726 description "set chunk value in sctp header"; 1727 } 1728 leaf chunk-type-value { 1729 type uint8; 1730 description "sctp chunk type value"; 1731 } 1732 leaf chunk-flag-value { 1733 type uint8; 1734 description "sctp chunk type 1735 flag value"; 1736 } 1738 leaf chunk-len { 1739 type uint16; 1740 description "sctp chunk length"; 1741 } 1743 leaf chunk-data-bzero { 1744 type uint32; 1745 description "byte zero of 1746 stcp chunk data"; 1747 } 1748 description "sctp qos actions"; 1749 } 1751 grouping L4-header-match { 1752 choice l4-header-match-type { 1753 case l4-tcp-header { 1754 uses tcp-header-match; 1756 } 1757 case l4-udp-header { 1758 uses udp-header-match; 1759 } 1760 case l4-sctp { 1761 uses sctp-header-match; 1762 } 1763 description "L4 match 1764 header choices"; 1765 } 1766 description "L4 header 1767 match type"; 1768 } 1770 grouping L4-header-actions { 1771 uses tcp-header-action; 1772 uses udp-header-action; 1773 uses sctp-header-action; 1774 description "L4 header matches"; 1775 } 1777 grouping service-header-match { 1778 choice service-header-match-type { 1779 case sf-chain-meta-match { 1780 description "uses 1781 sfc-sfc:service-function-chain-grouping: 1782 + sfc-sfc:service-function-chain"; 1783 } 1784 case sf-path-meta-match { 1785 description "uses 1786 sfc-spf:service-function-paths: 1787 + sfc-spf:service-function-path"; 1788 } 1789 description "SFC header match 1790 choices"; 1791 } 1792 description "SFC header and path 1793 matches"; 1794 } 1796 grouping sfc-header-actions { 1797 choice service-header-match-type { 1798 case sf-chain-meta-match { 1799 leaf set-chain { 1800 type boolean; 1801 description "flag to set 1802 chain in sfc. Should 1803 be amended to use SFC service 1804 chain matching. 1805 uses sfc-sfc:service-function-chain-grouping: 1806 + sfc-sfc:service-function-chain"; 1807 } 1808 } 1809 case sf-path-meta-match { 1810 leaf set-path { 1811 type boolean; 1812 description "flag to set path in 1813 sfc header. Amend to use sfc-spf 1814 function headers. Uses 1815 sfc-spf:service-function-paths: 1816 + sfc-spf:service-function-path."; 1817 } 1818 } 1819 description "choices in SFC for 1820 chain match and path match."; 1821 } 1822 description "modify action for 1823 SFC header."; 1824 } 1826 grouping rule_status { 1827 leaf rule-status { 1828 type string; 1829 description "status information 1830 free form string."; 1831 } 1832 leaf rule-inactive-reason { 1833 type string; 1834 description "description of 1835 why rule is inactive"; 1836 } 1837 leaf rule-install-reason { 1838 type string; 1839 description "response on rule installed"; 1840 } 1841 leaf rule-installer { 1842 type string; 1843 description "client id of installer"; 1844 } 1845 leaf refcnt { 1846 type uint16; 1847 description "reference count on rule. "; 1848 } 1849 description 1850 "rule operational status"; 1851 } 1853 // group status 1854 grouping groups-status { 1855 list group_opstate { 1856 key "grp-name"; 1857 leaf grp-name { 1858 type string; 1859 description "eca group name"; 1860 } 1861 leaf rules-installed { 1862 type uint32; 1863 description "rules in 1864 group installed"; 1865 } 1866 list rules_status { 1867 key "rule-name"; 1868 leaf rule-name { 1869 type string; 1870 description "name of rule "; 1871 } 1872 leaf rule-order { 1873 type uint32; 1874 description "rule-order"; 1875 } 1876 description "rules per 1877 group"; 1878 } 1879 description "group operational 1880 status"; 1881 } 1882 description "group to rules 1883 list"; 1884 } 1886 // links between rule to group 1888 grouping rule-group-link { 1889 list rule-group { 1890 key rule-name; 1891 leaf rule-name { 1892 type string; 1893 description "rule name"; 1894 } 1895 leaf group-name { 1896 type string; 1897 description "group name"; 1899 } 1900 description "link between 1901 group and link"; 1902 } 1903 description "rule-name to 1904 group link"; 1905 } 1907 // rule status by name 1908 grouping rules_opstate { 1909 list rules_status { 1910 key "rule-order rule-name"; 1911 leaf rule-order { 1912 type uint32; 1913 description "order of rules"; 1914 } 1915 leaf rule-name { 1916 type string; 1917 description "rule name"; 1918 } 1919 uses rule_status; 1920 description "eca rule list"; 1921 } 1922 description "rules 1923 operational state"; 1924 } 1926 // rule statistics by name and order 1927 grouping rules_opstats { 1928 list rule-stat { 1929 key "rule-order rule-name"; 1930 leaf rule-order { 1931 type uint32; 1932 description "order of rules"; 1933 } 1934 leaf rule-name { 1935 type string; 1936 description "name of rule"; 1937 } 1938 leaf pkts-matched { 1939 type uint64; 1940 description "number of 1941 packets that matched filter"; 1942 } 1943 leaf pkts-modified { 1944 type uint64; 1945 description "number of 1946 packets that filter caused 1947 to be modified"; 1948 } 1949 leaf pkts-dropped { 1950 type uint64; 1951 description "number of 1952 packets that filter caused 1953 to be modified"; 1954 } 1955 leaf bytes-dropped { 1956 type uint64; 1957 description "number of 1958 packets that filter caused 1959 to be modified"; 1960 } 1961 leaf pkts-forwarded { 1962 type uint64; 1963 description "number of 1964 packets that filter caused 1965 to be forwarded."; 1966 } 1967 leaf bytes-forwarded { 1968 type uint64; 1969 description "number of 1970 packets that filter caused 1971 to be forwarded."; 1972 } 1974 description "list of 1975 operational statistics for each 1976 rule."; 1977 } 1978 description "statistics 1979 on packet filter matches, and 1980 based on matches on many were 1981 modified and/or forwarded"; 1982 } 1984 grouping packet-size-match { 1985 leaf l1-size-match { 1986 type uint32; 1987 description "L1 packet match size."; 1988 } 1989 leaf l2-size-match { 1990 type uint32; 1991 description "L2 packet match size."; 1992 } 1994 leaf l3-size-match { 1995 type uint32; 1996 description "L3 packet match size."; 1997 } 1998 leaf l4-size-match { 1999 type uint32; 2000 description "L4 packet match size."; 2001 } 2002 leaf service-meta-size { 2003 type uint32; 2004 description "service meta info match size."; 2005 } 2006 leaf service-meta-payload { 2007 type uint32; 2008 description "service meta-play match size"; 2009 } 2010 description "packet size by layer 2011 only non-zero values are matched"; 2012 } 2014 grouping time-day-match { 2016 leaf hour { 2017 type uint8; 2018 description "hour 2019 of day in 24 hours. 2020 (add range)"; 2021 } 2022 leaf minute { 2023 type uint8; 2024 description 2025 "minute in day."; 2026 } 2027 leaf second { 2028 type uint8; 2029 description 2030 "second in day."; 2031 } 2033 description "matches for 2034 time of day."; 2036 } 2038 grouping user-event-match { 2039 leaf user-name { 2040 type string; 2041 description "name of user 2042 event"; 2043 } 2044 leaf match-string { 2045 type string; 2046 description "user match 2047 string"; 2048 } 2050 description "matches for 2051 time of day."; 2053 } 2055 grouping eca-event-matches { 2056 uses time-day-match; 2057 uses user-event-match; 2058 description "matches for events 2059 which include: 2060 time of day, and 2061 user specified matches."; 2063 } 2065 grouping eca-pkt-matches { 2066 uses interface-match; 2067 uses L1-header-match; 2068 uses L2-header-match; 2069 uses L3-header-match; 2070 uses L4-header-match; 2071 uses service-header-match; 2072 uses packet-size-match; 2073 description "ECA matches"; 2074 } 2076 grouping user-status-matches { 2077 leaf user { 2078 type string; 2079 description "user"; 2080 } 2081 leaf region { 2082 type string; 2083 description "region"; 2084 } 2085 leaf state { 2086 type string; 2087 description "state"; 2089 } 2091 leaf user-status { 2092 type string; 2093 description "status of user"; 2094 } 2096 description "user status 2097 matches - region, 2098 target, location"; 2099 } 2101 grouping eca-condition-matches { 2102 uses eca-pkt-matches; 2103 uses user-status-matches; 2104 description "pkt 2105 and user status matches"; 2106 } 2108 grouping eca-qos-actions { 2109 leaf cnt-actions { 2110 type uint32; 2111 description "count of ECA actions"; 2112 } 2113 list qos-actions { 2114 key "action-id"; 2115 leaf action-id { 2116 type uint32; 2117 description "action id"; 2118 } 2119 uses interface-actions; 2120 uses L1-header-actions; 2121 uses l2-header-mod-actions; 2122 uses L3-header-actions; 2123 uses L4-header-actions; 2125 description "ECA set or change 2126 packet Actions. Actions may be 2127 added here for interface, 2128 L1, L2, L3, L4 nad service forwarding 2129 headers."; 2130 } 2131 description "eca- qos actions"; 2132 } 2134 grouping ip-next-fwd { 2135 leaf rib-name { 2136 type string; 2137 description "name of RIB"; 2138 } 2139 leaf next-hop-name { 2140 type string; 2141 description "name of next hop"; 2142 } 2143 description "ECA set or change 2144 packet Actions"; 2145 } 2147 grouping eca-ingress-actions { 2148 leaf permit { 2149 type boolean; 2150 description "permit ingress 2151 traffic. False 2152 means to deny."; 2153 } 2154 leaf mirror { 2155 type boolean; 2156 description "copy bytes 2157 ingressed to mirror port"; 2158 } 2159 description "ingress eca match"; 2160 } 2162 grouping eca-fwd-actions { 2163 leaf interface-fwd { 2164 type if:interface-ref; 2165 description "name of interface to forward on"; 2166 } 2167 uses i2rs-rib:nexthop; 2168 uses ip-next-fwd; 2169 leaf drop-packet { 2170 type boolean; 2171 description "drop packet flag"; 2172 } 2173 description "ECA forwarding actions"; 2174 } 2176 grouping eca-security-actions { 2177 leaf actions-exist { 2178 type boolean; 2179 description "existance of 2180 eca security actions"; 2181 } 2182 description "content actions 2183 for security. Needs more 2184 description."; 2186 } 2188 grouping eca-egress-actions { 2189 leaf packet-rate { 2190 type uint32; 2191 description "maximum packet-rate"; 2192 } 2193 leaf byte-rate { 2194 type uint64; 2195 description "maximum byte-rate "; 2196 } 2197 description "packet security actions"; 2198 } 2200 grouping policy-conflict-resolution { 2201 list resolution-strategy { 2202 key "strategy-id"; 2203 leaf strategy-id { 2204 type uint32; 2205 description "Id for strategy"; 2206 } 2207 leaf stategy-name { 2208 type string; 2209 description "name of strategy"; 2210 } 2211 leaf filter-strategy { 2212 type string; 2213 description "type of resolution"; 2215 } 2216 leaf global-strategy { 2217 type boolean; 2218 description "global strategy"; 2219 } 2220 leaf mandatory-strategy { 2221 type boolean; 2222 description "required strategy"; 2223 } 2224 leaf local-strategy { 2225 type boolean; 2226 description "local strategy"; 2227 } 2228 leaf resolution-fcn { 2229 type uint64; 2230 description "resolution function id "; 2231 } 2232 leaf resolution-value { 2233 type uint64; 2234 description "resolution value"; 2235 } 2236 leaf resolution-info { 2237 type string; 2238 description "resolution info"; 2239 } 2240 list associate-ext-data { 2241 key "ext-data-id"; 2242 leaf ext-data-id { 2243 type uint64; 2244 description "ID of external data"; 2245 } 2246 leaf ext-data { 2247 type string; 2248 description "external data"; 2249 } 2250 description "linked external data"; 2251 } 2252 description "list of strategies"; 2253 } 2254 description "policy conflict 2255 resolution strategies"; 2256 } 2258 grouping cfg-external-data { 2259 list cfg-ext-data { 2260 key "cfg-ext-data-id"; 2261 leaf cfg-ext-data-id { 2262 type uint64; 2263 description "id for external data"; 2264 } 2265 leaf data-type { 2266 type uint32; 2267 description "external data type ID"; 2268 } 2269 leaf priority { 2270 type uint64; 2271 description "priority of data"; 2272 } 2273 leaf other-data { 2274 type string; 2275 description "string 2276 external data"; 2277 } 2278 description "external data"; 2279 } 2280 description "external data list"; 2281 } 2283 grouping pkt-eca-policy-set { 2284 list groups { 2285 key "group-name"; 2286 leaf group-name { 2287 type string; 2288 description 2289 "name of group of rules"; 2290 } 2291 leaf vrf-name { 2292 type string; 2293 description "VRF name"; 2294 } 2295 uses rt:address-family; 2296 list group-rule-list { 2297 key "rule-name"; 2298 leaf rule-name { 2299 type string; 2300 description "name of rule"; 2301 } 2302 leaf rule-order-id { 2303 type uint16; 2304 description "rule-order-id"; 2305 } 2306 description "rules per group"; 2307 } 2308 description "pkt eca rule groups"; 2309 } 2310 list eca-rules { 2311 key "order-id"; 2312 ordered-by user; 2313 leaf order-id { 2314 type uint16; 2315 description "Number of order 2316 in ordered list (ascending)"; 2317 } 2318 leaf eca-rule-name { 2319 type string; 2320 description "name of rule"; 2321 } 2322 leaf installer { 2323 type string; 2324 description 2325 "Id of I2RS client 2326 that installs this rule."; 2328 } 2329 uses eca-event-matches; 2330 uses eca-ingress-actions; 2331 uses eca-qos-actions; 2332 uses eca-security-actions; 2333 uses eca-fwd-actions; 2334 uses eca-egress-actions; 2335 uses cfg-external-data; 2336 uses policy-conflict-resolution; 2338 description "ECA rules"; 2339 } // end of rule 2340 description "Policy sets."; 2341 } 2343 grouping pkt-eca-opstate { 2344 uses groups-status; 2345 uses rule-group-link; 2346 uses rules_opstate; 2347 uses rules_opstats; 2348 description "pkt eca policy 2349 op-state main"; 2350 } 2352 container pkt-eca-policy-opstate { 2353 config "false"; 2354 uses pkt-eca-opstate; 2355 description "operational state"; 2356 } 2358 } 2360 2362 6. IANA Considerations 2364 This draft requests IANA Assign a urn in the IETF yang module space 2365 for: 2367 "urn:ietf:params:xml:ns:yang:ietf-pkt-eca-policy"; 2369 associated prefix "pkt-eca"; 2371 7. Security Considerations 2373 These generic filters are used in the I2RS FB-RIBs to filter packets 2374 in a traffic stream, act to modify packets, and forward data packets. 2375 These I2RS filters operate dynamically at same level as currently 2376 deployed configured filter-based RIBs to filter, change, and forward 2377 traffic. The dynamic nature of this protocol requires that I2RS 2378 Filters track the installer of group information and rules. 2380 This section will be augmented after a discussion with security 2381 experts. 2383 8. Informative References 2385 [I-D.ietf-i2rs-rib-info-model] 2386 Bahadur, N., Kini, S., and J. Medved, "Routing Information 2387 Base Info Model", draft-ietf-i2rs-rib-info-model-09 (work 2388 in progress), July 2016. 2390 [I-D.ietf-netconf-restconf] 2391 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2392 Protocol", draft-ietf-netconf-restconf-17 (work in 2393 progress), September 2016. 2395 [I-D.ietf-netmod-acl-model] 2396 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 2397 "Network Access Control List (ACL) YANG Data Model", 2398 draft-ietf-netmod-acl-model-08 (work in progress), July 2399 2016. 2401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2402 Requirement Levels", BCP 14, RFC 2119, 2403 DOI 10.17487/RFC2119, March 1997, 2404 . 2406 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, 2407 "Policy Core Information Model -- Version 1 2408 Specification", RFC 3060, DOI 10.17487/RFC3060, February 2409 2001, . 2411 [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) 2412 Extensions", RFC 3460, DOI 10.17487/RFC3460, January 2003, 2413 . 2415 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 2416 Moore, "Policy Quality of Service (QoS) Information 2417 Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, 2418 . 2420 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 2421 Nadeau, "An Architecture for the Interface to the Routing 2422 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 2423 . 2425 Authors' Addresses 2427 Susan Hares 2428 Huawei 2429 7453 Hickory Hill 2430 Saline, MI 48176 2431 USA 2433 Email: shares@ndzh.com 2435 Qin Wu 2436 Huawei 2437 101 Software Avenue, Yuhua District 2438 Nanjing, Jiangsu 210012 2439 China 2441 Email: bill.wu@huawei.com 2443 Russ White 2444 Ericsson 2446 Email: russw@riw.us