idnits 2.17.1 draft-ietf-i2rs-pkt-eca-data-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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 375 has weird spacing: '... +--rw ecq-q...' == Line 388 has weird spacing: '...ext-hop rib-n...' == Line 436 has weird spacing: '...dentity match...' == Line 565 has weird spacing: '... base servi...' -- The document date (June 16, 2016) is 2843 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.ietf-i2rs-architecture' is defined on line 1611, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 1617, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-restconf' is defined on line 1622, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-acl-model' is defined on line 1627, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1633, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-08 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-13 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-07 Summary: 1 error (**), 0 flaws (~~), 13 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: December 18, 2016 R. White 6 Ericsson 7 June 16, 2016 9 Filter-Based Packet Forwarding ECA Policy 10 draft-ietf-i2rs-pkt-eca-data-model-00.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 December 18, 2016. 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 . . . . . . . . . . . . . 3 71 2. Generic Route Filters/Policy Overview . . . . . . . . . . . . 4 72 3. BNP Rule Groups . . . . . . . . . . . . . . . . . . . . . . . 5 73 4. BNP Generic Info Model in High Level Yang . . . . . . . . . . 7 74 5. i2rs-eca-policy Yang module . . . . . . . . . . . . . . . . . 10 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 77 8. Informative References . . . . . . . . . . . . . . . . . . . 36 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 80 1. Introduction 82 This document describes the yang data model for packet forwarding 83 policy that filters received packets and forwards (or drops) the 84 packets. Prior to forwarding the packets out other interfaces, some 85 of the fields in the packets may be modified. If one considers the 86 reception of a packet as an event, this minimalistic Event-Match 87 Condition-Action policy. If one considers the reception of packets 88 containing Layer 1 to Layer 4 + application data a single packet, 89 then this minimalistic policy can be called a packet-only ECA policy. 90 This document will use the term packet-only ECA policy for this model 91 utilizing the term "packet" in this fashion. 93 This packet-only ECA policy data model supports an ordered list of 94 ECA policy rules where each policy rule has a name. The match 95 condition filters include matches on 96 o packet headers for layer 1 to layer 4, 98 o application protocol data and headers, 100 o interfaces the packet was received on, 102 o time packet was received, and 104 o size of packet. 106 The actions include packet modify actions and forwarding options. 107 The modify options allow for the following: 109 o setting fields in the packet header at Layer 2 (L2) to Layer 4 110 (L4), and 112 o encapsulation and decapsulation the packet. 114 The forwardingng actions allow forwardsing the packet via interfaces, 115 tunnels, next-hops, or dropping the packet. setting things within 116 the packet at Layer 2 (L2) to layer 4 (L4) plus overlay or 117 application data. 119 The first section of this draft contains an overview of the policy 120 structure. The second provides a high-level yang module. The third 121 contains the yang module. 123 1.1. Definitions and Acronyms 125 INSTANCE: Routing Code often has the ability to spin up multiple 126 copies of itself into virtual machines. Each Routing code 127 instance or each protocol instance is denoted as Foo_INSTANCE in 128 the text below. 130 NETCONF: The Network Configuration Protocol 132 PCIM - Policy Core Information Model 134 RESTconf - http programmatic protocol to access yang modules 136 1.2. Antecedents this Policy in IETF 138 Antecedents to this generic policy are the generic policy work done 139 in PCIM WG. The PCIM work contains a Policy Core Information Model 140 (PCIM) [RFC3060], Policy Core Informational Model Extensions 141 [RFC3460] and the Quality of Service (QoS) Policy Information Model 142 (QPIM) ([RFC3644]) From PCIM comes the concept that policy rules 143 which are combined into policy groups. PCIM also refined a concept 144 of policy sets that allowed the nesting and aggregation of policy 145 groups. This generic model did not utilize the concept of sets of 146 groups, but could be expanded to include sets of groups in the 147 future. 149 2. Generic Route Filters/Policy Overview 151 This generic policy model represents filter or routing policies as 152 rules and groups of rules. 154 The basic concept are: 156 Rule Group 158 A rule group is is an ordered set of rules . 160 Rule 162 A Rule is represented by the semantics "If Condition then Action". 163 A Rule may have a priority assigned to it. 165 +-----------+ +------------+ 166 |Rule Group | | Rule Group | 167 +-----------+ +------------+ 168 ^ ^ 169 | | 170 | | 171 +--------^-------+ +-------^-------+ 172 | Rule | | Rule | 173 +----------------+ +---------------+ 174 : : 175 : : 176 ......: :..... 177 : : 178 +---------V---------+ +-V-------------+ 179 | Rule Condition | | Rule Action | 180 +-------------------+ +---------------+ 181 : : : : : : 182 .....: . :..... .....: . :..... 183 : : : : : : 184 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+ 185 | Match | | match | |match | | Action || action ||action| 186 |Operator| |Variable| |Value | |Operator||Variable|| Value| 187 +--------+ +--------+ +------+ +--------++--------++------+ 189 Figure 1: ECA rule structure 191 3. BNP Rule Groups 193 The pkt ECA policy is an order set of pkt-ECA policy rules. The 194 rules assume the event is the reception of a packet on the machine on 195 a set of interfaces. This policy is associated with a set of 196 interfaces on a routing device (physical or virtual). 198 A Rule group allows for the easy combination of rules for management 199 stations or users. A Rule group has the following elements: 201 o name that identifies the grouping of policy rules 203 o module reference - reference to a yang module(s) in the yang 204 module library that this group of policy writes policy to 206 o list of rules 208 Rule groups may have multiple policy groups at specific orders. For 209 example, policy gorup 1 could have three policy rules at rule order 1 210 and four policy rules at rule order 5. 212 The rule has the following elements: name, order, status, priority, 213 reference cnt, and match condition, and action as shown as shown in 214 figure 2. The order indicates the order of the rule within the the 215 complete list. The status of the rule is (active, inactive). The 216 priority is the priority within a specific order of policy/filter 217 rules. A reference count (refcnt) indicates the number of entities 218 (E.g. network modules) using this policy. The generic rule match- 219 action conditions have match operator, a match variable and a match 220 value. The rule actions have an action operator, action variable, 221 and an action value. 223 Rules can exist with the same rule order and same priority. Rules 224 with the same rule order and same priority are not guaranteed to be 225 at any specific ordering. The order number and priority have 226 sufficient depth that administrators who wish order can specify it. 228 Figure 2 - Rule Group 229 +--------------------------------------+ 230 | Rule Group | 231 +--------------------------------------+ 232 * * * 233 | | | 234 | | | 235 | | | 236 +------+ +-------------------+ 237 | Name | | Rule_list | 238 | | | | 239 +------+ +------|------------+ 240 +----------------|-----------------------------+ 241 | rule | 242 |-|------|----------|-----------|------------|-+ 243 | | | | | 244 +---|--+ +-|----+ +---|-------+ +-|------+ +-------+ 245 | Name | |rule | | ECA | |rule | |ref-cnt| 246 +------+ |order | | match | |priority| +-------+ 247 |number| |qos-actions| +--------+ 248 +------+ |fwd-actions| 249 +-----------+ 251 The generic match conditions are specific to a particular layer are 252 refined by matches to a specific layer (as figure 3 shows), and 253 figure 5's high-level yang defines. The general actions may be 254 generic actions that are specific to a particular layer (L1, L2, L3, 255 service layer) or time of day or packet size. The qos actions can be 256 setting fields in the packet at any layer (L1-L4, service) or 257 encapsulating or decapsulating the packet at a layer. The fwd- 258 actions are forwarding functions that forward on an interface or to a 259 next-hop. The rule status is the operational status per rule. 261 Figure 3 262 +-------------+ 263 | Match | 264 | Condition | 265 +-------|-----+ 266 | 267 +-------------+-|-----------+-----------+ 268 | | | | 269 V V V V 270 ............ ............ ............ ........... 271 : L1 : : L2 : : L3 : : Service : . . . 272 : match : : match : : match : : match : 273 '''''''''''' '''''''''''' '''''''''''' ''''''''''' 275 4. BNP Generic Info Model in High Level Yang 277 Below is the high level inclusion 279 Figure 5 280 module:bnp-eca-policy 281 import ietf-inet-types {prefix "inet"} 282 import ietf-interface {prefix "if"} 283 import ietf-i2rs-rib {prefix "i2rs-rib"} 285 import ietf-interfaces { 286 prefix "if"; 287 } 288 import ietf-inet-types { 289 prefix inet; 290 //rfc6991 291 } 293 import ietf-i2rs-rib { 294 prefix "i2rs-rib"; 296 Below is the high level yang diagram 297 Packet Reception ECA policy 298 module ietf-pkt-eca-policy 299 +--rw pkt-eca-policy-cfg 300 | +--rw pkt-eca-policy-set 301 | +--rw groups* [group-name] 302 | | +--rw vrf-name string 303 | | +--rw address-family 304 | | +--rw group-rule-list* [rule-name] 305 | | | +--rw rule-name 306 | | | +--rw rule-order-id 307 | +--rw rules* [order-id rule-name] 308 | +--rw eca-matches 309 | | ... 310 | +--rw eca-qos-actions 311 | | ... 312 | +--rw eca-fwd-actions 313 | | ... 314 +--rw pkt-eca-policy-opstate 315 +--rw pkt-eca-opstate 316 +--rw groups* [group-name] 317 | +--rw rules-installed; 318 | +--rw rules_status* [rule-name] 319 +--rw rule-group-link* [rule-name] 320 | +--rw group-name 321 +--rw rules_opstate* [rule-order rule-name] 322 | +--rw status 323 | +--rw rule-inactive-reason 324 | +--rw rule-install-reason 325 | +--rw rule-installer 326 | +--rw refcnt 327 +--rw rules_op-stats* [rule-order rule-name] 328 +--rw pkts-matched 329 +--rw pkts-modified 330 +--rw pkts-forwarde 332 The three levels of policy are expressed as: 334 Config Policy definitions 335 ======================================= 336 Policy level: pkt-eca-policy-set 337 group level: pkt-eca-policy-set:groups 338 rule level: bnp-eca-policy-set:rules 340 Operational State for Policy 341 ======================================= 342 Policy level: pkt-eca-policy-opstate 343 group level: pkt-eca-policy-opstate:groups-status 344 rule level: bnp-eca-policy-opstate:rules_opstate* 345 bnp-eca-policy-opstate:rules_opstats* 347 figure 349 The filter matches struture is shown below 351 module:i2rs-pkt-eca-policy 352 +--rw pkt-eca-policy-cfg 353 | +--rw pkt-eca-policy-set 354 | +--rw groups* [group-name] 355 | | ... 356 | +--rw rules [order-id rule-name] 357 | +--rw eca-matches 358 | | | +--case: interface-match 359 | | | +--case: L1-header-match 360 | | | +--case: L2-header-match 361 | | | +--case: L3-header-match 362 | | | +--case: L4-header-match 363 | | | +--case: Service-header-match 364 | | | +--case: packet-size 365 | | | +--case: time-of-day 367 module:i2rs-pkt-eca-policy 368 +--rw pkt-eca-policy-cfg 369 | +--rw pkt-eca-policy-set 370 | +--rw groups* [group-name] 371 | | ... 372 | +--rw rules* [order-id rule-name] 373 | +--rw eca-matches 374 | | . . . 375 | +--rw ecq-qos-actions 376 | | +--rw cnt-actions 377 | | +--rw mod-actions 378 | | | +--case interface-actions 379 | | | +--case L1-action 380 | | | +--case L2-action 381 | | | +--case L3-action 382 | | | +--case L4-action 383 | | | +--case service-action 384 | +--rw eca-fwd-actions 385 | | +--rw num-fwd-actions 386 | | +--rw fwd-actions 387 | | | +--rw interface interface-ref 388 | | | +--rw next-hop rib-nexthop-ref 389 | | | +--rw route-attributes 390 | | | +--rw rib-route-attributes-ref 391 | | | +--rw fb-std-drop 393 5. i2rs-eca-policy Yang module 395 file "ietf-pkt-eca-policy@2016-02-09.yang" 397 module ietf-pkt-eca-policy { 398 namespace "urn:ietf:params:xml:ns:yang:ietf-pkt-eca-policy"; 399 // replace with iana namespace when assigned 400 prefix "pkt-eca-policy"; 402 import ietf-routing { 403 prefix "rt"; 404 } 405 import ietf-interfaces { 406 prefix "if"; 407 } 408 import ietf-inet-types { 409 prefix inet; 410 //rfc6991 411 } 413 import ietf-i2rs-rib { 415 prefix "i2rs-rib"; 416 } 418 // meta 419 organization "IETF I2RS WG"; 421 contact 422 "email: shares@ndzh.com 423 email: russ.white@riw.com 424 email: linda.dunbar@huawei.com 425 email: bill.wu@huawei.com"; 427 description 428 "This module describes a basic network policy 429 model with filter per layer."; 431 revision "2016-02-09" { 432 description "initial revision"; 433 reference "draft-hares-i2rs-pkt-eca-policy-dm-00"; 434 } 436 // interfaces - no identity matches 438 // L1 header match identities 439 identity l1-header-match-type { 440 description 441 " L1 header type for match "; 442 } 444 identity l1-hdr-sonet-type { 445 base l1-header-match-type; 446 description 447 " L1 header sonet match "; 448 } 450 identity l1-hdr-OTN-type { 451 base l1-header-match-type; 452 description 453 " L1 header OTN match "; 454 } 456 identity l1-hdr-dwdm-type { 457 base l1-header-match-type; 458 description 459 " L1 header DWDM match "; 460 } 461 // L2 header match identities 462 identity l2-header-match-type { 463 description 464 " l2 header type for match "; 465 } 467 identity l2-802-1Q { 468 base l2-header-match-type; 469 description 470 " l2 header type for 802.1Q match "; 471 } 473 identity l2-802-11 { 474 base l2-header-match-type; 475 description 476 " l2 header type for 802.11 match "; 477 } 479 identity l2-802-15 { 480 base l2-header-match-type; 481 description 482 " l2 header type for 802.15 match "; 483 } 485 identity l2-NVGRE { 486 base l2-header-match-type; 487 description 488 " l2 header type for NVGRE match "; 489 } 490 identity l2-mpls { 491 base l2-header-match-type; 492 description 493 " l2 header type for MPLS match "; 494 } 496 identity l2-VXLAN { 497 base l2-header-match-type; 498 description 499 " l2 header type for VXLAN match "; 500 } 502 // L3 header match identities 503 identity l3-header-match-type { 504 description 505 " l3 header type for match "; 506 } 507 identity l3-ipv4-hdr { 508 base l3-header-match-type; 509 description 510 " l3 header type for IPv4 match "; 511 } 513 identity l3-ipv6-hdr { 514 base l3-header-match-type; 515 description 516 " l3 header type for IPv6 match "; 517 } 519 identity l3-gre-tunnel { 520 base l3-header-match-type; 521 description 522 " l3 header type for GRE tunnel match "; 523 } 525 // L4 header match identities 527 identity l4-header-match-type { 528 description "L4 header 529 match types. (TCP, UDP, 530 SCTP, etc. )"; 531 } 533 identity l4-tcp-header { 534 base l4-header-match-type; 535 description "L4 header for TCP"; 536 } 538 identity l4-udp-header { 539 base l4-header-match-type; 540 description "L4 header match for UDP"; 541 } 543 identity l4-sctp-header { 544 base l4-header-match-type; 545 description "L4 header match for SCTP"; 546 } 548 // Service header identities 550 identity service-header-match-type { 551 description "service header 552 match types: service function path 553 (sf-path)), SF-chain, sf-discovery, 554 and others (added here)"; 556 } 558 identity sf-chain-meta-match { 559 base service-header-match-type; 560 description "service header match for 561 meta-match header"; 562 } 564 identity sf-path-meta-match { 565 base service-header-match-type; 566 description "service header match for 567 path-match header"; 568 } 570 identity rule-status-type { 571 description "status 572 values for rule: invalid (0), 573 valid (1), valid and installed (2)"; 574 } 576 identity rule-status-invalid { 577 base rule-status-type; 578 description "invalid rule status."; 579 } 581 identity rule-status-valid { 582 base rule-status-type; 583 description "This status indicates 584 a valid rule."; 586 } 588 identity rule-status-valid-installed { 589 base rule-status-type; 590 description "This status indicates 591 an installed rule."; 592 } 593 identity rule-status-valid-inactive { 594 base rule-status-type; 595 description "This status indicates 596 a valid ruled that is not installed."; 597 } 599 grouping interface-match { 600 leaf match-if-name { 601 type if:interface-ref; 602 description "match on interface name"; 603 } 604 description "interface 605 has name, description, type, enabled 606 as potential matches"; 607 } 609 grouping interface-actions { 610 description 611 "interface action up/down and 612 enable/disable"; 613 leaf interface-up { 614 type boolean; 615 description 616 "action to put interface up"; 617 } 618 leaf interface-down { 619 type boolean; 620 description 621 "action to put interface down"; 622 } 623 leaf interface-enable { 624 type boolean; 625 description 626 "action to enable interface"; 627 } 628 leaf interface-disable { 629 type boolean; 630 description 631 "action to disable interface"; 632 } 633 } 635 grouping L1-header-match { 636 choice l1-header-match-type { 637 case l1-hdr-sonet-type { 638 // sonet matches 639 } 640 case L1-hdr-OTN-type { 641 // OTN matches 642 } 643 case L1-hdr-dwdm-type { 644 // DWDM matches 645 } 646 description 647 "The Layer 1 header match choices"; 648 } 649 description 650 "The Layer 1 header match includes 651 any reference to L1 technology"; 652 } 654 grouping L1-header-actions { 655 leaf l1-hdr-sonet-act { 656 type uint8; 657 description "sonet actions"; 658 } 659 leaf l1-hdr-OTN-act { 660 type uint8; 661 description "OTN actions"; 662 } 663 leaf l1-hdr-dwdm-act { 664 type uint8; 665 description "DWDM actions"; 666 } 667 description "L1 header match 668 types"; 669 } 671 grouping L2-802-1Q-header { 672 description 673 "This is short-term 802.1 header 674 match which will be replaced 675 by reference to IEEE yang when 676 it arrives. Qtag 1 is 802.1Q 677 Qtag2 is 802.1AD"; 679 leaf vlan-present { 680 type boolean; 681 description " Include VLAN in header"; 682 } 683 leaf qtag1-present { 684 type boolean; 685 description " This flag value indicates 686 inclusion of one 802.1Q tag in header"; 687 } 688 leaf qtag2-present{ 689 type boolean; 690 description "This flag indicates the 691 inclusion of second 802.1Q tag in header"; 692 } 694 leaf dest-mac { 695 type uint64; //change to uint48 696 description "IEEE destination MAC value 697 from the header"; 698 } 700 leaf src-mac { 701 type uint64; //change to uint48 702 description "IEEE source MAC 703 from the header"; 705 } 706 leaf vlan-tag { 707 type uint16; 708 description "IEEE VLAN Tag 709 from the header"; 710 } 711 leaf qtag1 { 712 type uint32; 713 description "Qtag1 value 714 from the header"; 715 } 716 leaf qtag2 { 717 type uint32; 718 description "Qtag1 value 719 from the header"; 720 } 721 leaf L2-ethertype { 722 type uint16; 723 description "Ether type 724 from the header"; 725 } 726 } 728 grouping L2-VXLAN-header { 729 container vxlan-header { 730 uses i2rs-rib:ipv4-header; 731 leaf vxlan-network-id { 732 type uint32; 733 description "VLAN network id"; 734 } 735 description " choices for 736 L2-VLAN header matches. 737 Outer-header only. 738 Need to fix inner header. "; 739 } 740 description 741 "This VXLAN header may 742 be replaced by actual VXLAN yang 743 module reference"; 744 } 746 grouping L2-NVGRE-header { 747 container nvgre-header { 748 uses L2-802-1Q-header; 749 uses i2rs-rib:ipv4-header; 750 leaf gre-version { 751 type uint8; 752 description "L2-NVGRE GRE version"; 753 } 754 leaf gre-proto { 755 type uint16; 756 description "L2-NVGRE protocol value"; 757 } 758 leaf virtual-subnet-id { 759 type uint32; 760 description "L2-NVGRE subnet id value"; 761 } 762 leaf flow-id { 763 type uint16; 764 description "L2-NVGRE Flow id value"; 765 } 766 // uses L2-802-1Q-header; 767 description 768 "This NVGRE header may 769 be replaced by actual NVGRE yang 770 module reference"; 771 } 772 description "Grouping for 773 L2 NVGRE header."; 774 } 776 grouping L2-header-match { 778 choice l2-header-match-type { 779 case l2-802-1Q { 780 uses L2-802-1Q-header; 781 } 782 case l2-802-11 { 783 // matches for 802.11 headers 784 } 785 case l2-802-15 { 786 // matches for 802.1 Ethernet 787 } 788 case l2-NVGRE { 789 // matches for NVGRE 790 uses L2-NVGRE-header; 791 } 792 case l2-VXLAN-header { 793 uses L2-VXLAN-header; 795 } 796 case l2-mpls-header { 797 uses i2rs-rib:mpls-header; 798 } 799 description "Choice of L2 800 headers for L2 match"; 801 } 802 description 803 " The layer 2 header match includes 804 any reference to L2 technology"; 805 } 807 grouping L2-NVGRE-mod-acts { 808 // actions for NVGRE 809 leaf set-vsid { 810 type boolean; 811 description 812 "Boolean flag to set VSID in packet"; 813 } 814 leaf set-flowid { 815 type boolean; 816 description 817 "Boolean flag to set VSID in packet"; 818 } 819 leaf vsi { 820 type uint32; 821 description 822 "VSID value to set in packet"; 823 } 824 leaf flow-id { 825 type uint16; 826 description 827 "flow-id value to set in packet"; 828 } 829 description "L2-NVRE Actions"; 830 } 832 grouping L2-VXLAN-mod-acts { 833 leaf set-network-id { 834 type boolean; 835 description 836 "flag to set network id in packet"; 837 } 838 leaf network-id { 839 type uint32; 840 description 841 "network id value to set in packet"; 842 } 843 description "VXLAN header 844 modification actions."; 845 } 847 grouping L2-mpls-mod-acts { 848 leaf pop { 849 type boolean; 850 description 851 "Boolean flag to pop mpls header"; 852 } 853 leaf push { 854 type boolean; 855 description 856 "Boolean flag to push value into 857 mpls header"; 858 } 859 leaf mpls-label { 860 type uint32; 861 description 862 "mpls label to push in header"; 863 } 864 description "MPLS modify 865 header actions"; 866 } 868 grouping l2-header-mod-actions { 869 leaf l2-802-1Q { 870 type uint8; 871 description "actions for 802.1Q"; 872 } 873 leaf l2-802-11 { 874 type uint8; 875 description "actions for 802.11"; 876 } 877 leaf l2-802-15 { 878 type uint8; 879 description "ations for 802.15"; 880 } 882 uses L2-NVGRE-mod-acts; 883 uses L2-VXLAN-mod-acts; 884 uses L2-mpls-mod-acts; 886 description 887 " The layer 2 header match includes 888 any reference to L2 technology"; 889 } 891 grouping L3-header-match { 893 choice L3-header-match-type { 894 case l3-ipv4-hdr { 895 uses i2rs-rib:ipv4-header; 896 } 897 case l3-ipv6-hdr { 898 uses i2rs-rib:ipv6-header; 899 } 900 case L3-gre-tunnel { 901 uses i2rs-rib:gre-header; 902 } 903 description "match for L3 904 headers for IPv4, IPv6, 905 and GRE tunnels"; 906 } 907 description "match for L3 headers"; 908 } 910 grouping ipv4-encapsulate-gre { 911 leaf encapsulate { 912 type boolean; 913 description "flag to encapsulate headers"; 914 } 915 leaf ipv4-dest-address { 916 type inet:ipv4-address; 917 description "Destination Address for GRE header"; 918 } 919 leaf ipv4-source-address { 920 type inet:ipv4-address; 921 description "Source Address for GRE header"; 922 } 923 description "encapsulation actions for IPv4 headers"; 924 } 926 grouping L3-header-actions { 927 choice l3-header-act-type { 928 case l3-ipv4-hdr { 929 leaf set-ttl { 930 type boolean; 931 description "flag to set TTL"; 932 } 933 leaf set-dscp { 934 type boolean; 935 description "flag to set DSCP"; 936 } 937 leaf ttl-value { 938 type uint8; 939 description "TTL value to set"; 940 } 941 leaf dscp-val { 942 type uint8; 943 description "dscp value to set"; 944 } 945 } 946 case l3-ipv6-hdr { 947 leaf set-next-header { 948 type boolean; 949 description 950 "flag to set next routing 951 header in IPv6 header"; 952 } 953 leaf set-traffic-class { 954 type boolean; 955 description 956 "flag to set traffic class 957 in IPv6 header"; 959 } 960 leaf set-flow-label { 961 type boolean; 962 description 963 "flag to set flow label 964 in IPv6 header"; 965 } 966 leaf set-hop-limit { 967 type boolean; 968 description "flag 969 to set hop limit in 970 L3 packet"; 971 } 972 leaf ipv6-next-header { 973 type uint8; 974 description "value to 975 set in next IPv6 header"; 976 } 977 leaf ipv6-traffic-class { 978 type uint8; 979 description "value to set 980 in traffic class"; 982 } 983 leaf ipv6-flow-label { 984 type uint16; 985 description "value to set 986 in IPOv6 flow label"; 988 } 989 leaf ipv6-hop-limit { 990 type uint8; 991 description "value to set 992 in hop count"; 993 } 994 } 996 case L3-gre-tunnel { 997 leaf decapsulate { 998 type boolean; 999 description "flag to 1000 decapsulate GRE packet"; 1001 } 1002 description "GRE tunnel 1003 actions" ; 1004 } 1005 description "actions that can 1006 be performed on L3 header"; 1007 } 1008 description "actions to 1009 be performed on L3 header"; 1010 } 1012 grouping tcp-header-match { 1013 leaf tcp-src-port { 1014 type uint16; 1015 description "source port match value"; 1016 } 1017 leaf tcp-dst-port { 1018 type uint16; 1019 description "dest port value 1020 to match"; 1021 } 1022 leaf sequence-number { 1023 type uint32; 1024 description "sequence number 1025 value to match"; 1026 } 1027 leaf ack-number { 1028 type uint32; 1029 description "action value to 1030 match"; 1031 } 1032 description "match for TCP 1033 header"; 1034 } 1035 grouping tcp-header-action { 1036 leaf set-tcp-src-port { 1037 type boolean; 1038 description "flag to set 1039 source port value"; 1040 } 1041 leaf set-tcp-dst-port { 1042 type boolean; 1043 description "flag to set source port value"; 1044 } 1046 leaf tcp-s-port { 1047 type uint16; 1048 description "source port match value"; 1049 } 1050 leaf tcp-d-port { 1051 type uint16; 1052 description "dest port value 1053 to match"; 1054 } 1055 leaf seq-num { 1056 type uint32; 1057 description "sequence number 1058 value to match"; 1059 } 1060 leaf ack-num { 1061 type uint32; 1062 description "action value to 1063 match"; 1064 } 1065 description "Actions to 1066 modify TCP header"; 1067 } 1069 grouping udp-header-match { 1070 leaf udp-src-port { 1071 type uint16; 1072 description "UDP source 1073 port match value"; 1074 } 1075 leaf udp-dst-port { 1076 type uint16; 1077 description "UDP Destination 1078 port match value"; 1079 } 1080 description "match values for 1081 UDP header"; 1083 } 1085 grouping udp-header-action { 1086 leaf set-udp-src-port { 1087 type boolean; 1088 description "flag to set 1089 UDP source port match value"; 1090 } 1091 leaf set-udp-dst-port { 1092 type boolean; 1093 description 1094 "flag to set UDP destination port match value"; 1095 } 1096 leaf udp-s-port { 1097 type uint16; 1098 description "UDP source 1099 port match value"; 1100 } 1101 leaf udp-d-port { 1102 type uint16; 1103 description "UDP Destination 1104 port match value"; 1105 } 1107 description "actions to set 1108 values in UDP header"; 1109 } 1111 grouping sctp-chunk { 1112 leaf chunk-type { 1113 type uint8; 1114 description "sctp chunk type value"; 1115 } 1116 leaf chunk-flag { 1117 type uint8; 1118 description "sctp chunk type 1119 flag value"; 1120 } 1122 leaf chunk-length { 1123 type uint16; 1124 description "sctp chunk length"; 1125 } 1127 leaf chunk-data-byte-zero { 1128 type uint32; 1129 description "byte zero of 1130 stcp chunk data"; 1132 } 1133 description "sctp chunck 1134 header match fields"; 1135 } 1137 grouping sctp-header-match { 1138 uses sctp-chunk; 1139 leaf stcp-src-port { 1140 type uint16; 1141 description "sctp header match 1142 source port value"; 1143 } 1144 leaf sctp-dst-port { 1145 type uint16; 1146 description "sctp header match 1147 destination port value"; 1148 } 1149 leaf sctp-verify-tag { 1150 type uint32; 1151 description "sctp header match 1152 verification tag value"; 1153 } 1154 description "SCTP header 1155 match values"; 1156 } 1158 grouping sctp-header-action { 1159 leaf set-stcp-src-port { 1160 type boolean; 1161 description "set source port in sctp header"; 1162 } 1163 leaf set-stcp-dst-port { 1164 type boolean; 1165 description "set destination port in sctp header"; 1166 } 1167 leaf set-stcp-chunk1 { 1168 type boolean; 1169 description "set chunk value in sctp header"; 1170 } 1171 leaf chunk-type-value { 1172 type uint8; 1173 description "sctp chunk type value"; 1174 } 1175 leaf chunk-flag-value { 1176 type uint8; 1177 description "sctp chunk type 1178 flag value"; 1179 } 1180 leaf chunk-len { 1181 type uint16; 1182 description "sctp chunk length"; 1183 } 1185 leaf chunk-data-bzero { 1186 type uint32; 1187 description "byte zero of 1188 stcp chunk data"; 1189 } 1190 description "sctp qos actions"; 1191 } 1193 grouping L4-header-match { 1194 choice l4-header-match-type { 1195 case l4-tcp-header { 1196 uses tcp-header-match; 1197 } 1198 case l4-udp-header { 1199 uses udp-header-match; 1200 } 1201 case l4-sctp { 1202 uses sctp-header-match; 1203 } 1204 description "L4 match 1205 header choices"; 1206 } 1207 description "L4 header 1208 match type"; 1209 } 1211 grouping L4-header-actions { 1212 uses tcp-header-action; 1213 uses udp-header-action; 1214 uses sctp-header-action; 1215 description "L4 header matches"; 1216 } 1218 grouping service-header-match { 1219 choice service-header-match-type { 1220 case sf-chain-meta-match { 1221 description "uses 1222 sfc-sfc:service-function-chain-grouping: 1223 + sfc-sfc:service-function-chain"; 1224 } 1225 case sf-path-meta-match { 1226 description "uses 1227 sfc-spf:service-function-paths: 1228 + sfc-spf:service-function-path"; 1229 } 1230 description "SFC header match 1231 choices"; 1232 } 1233 description "SFC header and path 1234 matches"; 1235 } 1237 grouping sfc-header-actions { 1238 choice service-header-match-type { 1239 case sf-chain-meta-match { 1240 leaf set-chain { 1241 type boolean; 1242 description "flag to set 1243 chain in sfc. Should 1244 be amended to use SFC service 1245 chain matching. 1246 uses sfc-sfc:service-function-chain-grouping: 1247 + sfc-sfc:service-function-chain"; 1248 } 1249 } 1250 case sf-path-meta-match { 1251 leaf set-path { 1252 type boolean; 1253 description "flag to set path in 1254 sfc header. Amend to use sfc-spf 1255 function headers. Uses 1256 sfc-spf:service-function-paths: 1257 + sfc-spf:service-function-path."; 1258 } 1259 } 1260 description "choices in SFC for 1261 chain match and path match."; 1262 } 1263 description "modify action for 1264 SFC header."; 1265 } 1267 grouping rule_status { 1268 leaf rule-status { 1269 type string; 1270 description "status information 1271 free form string."; 1272 } 1273 leaf rule-inactive-reason { 1274 type string; 1275 description "description of 1276 why rule is inactive"; 1277 } 1278 leaf rule-install-reason { 1279 type string; 1280 description "response on rule installed"; 1281 } 1282 leaf rule-installer { 1283 type string; 1284 description "client id of installer"; 1285 } 1286 leaf refcnt { 1287 type uint16; 1288 description "reference count on rule. "; 1289 } 1290 description 1291 "rule operational status"; 1292 } 1294 // group status 1295 grouping groups-status { 1296 list group_opstate { 1297 key "grp-name"; 1298 leaf grp-name { 1299 type string; 1300 description "eca group name"; 1301 } 1302 leaf rules-installed { 1303 type uint32; 1304 description "rules in 1305 group installed"; 1306 } 1307 list rules_status { 1308 key "rule-name"; 1309 leaf rule-name { 1310 type string; 1311 description "name of rule "; 1312 } 1313 leaf rule-order { 1314 type uint32; 1315 description "rule-order"; 1316 } 1317 description "rules per 1318 group"; 1319 } 1320 description "group operational 1321 status"; 1322 } 1323 description "group to rules 1324 list"; 1325 } 1327 // links between rule to group 1329 grouping rule-group-link { 1330 list rule-group { 1331 key rule-name; 1332 leaf rule-name { 1333 type string; 1334 description "rule name"; 1335 } 1336 leaf group-name { 1337 type string; 1338 description "group name"; 1339 } 1340 description "link between 1341 group and link"; 1342 } 1343 description "rule-name to 1344 group link"; 1345 } 1347 // rule status by name 1348 grouping rules_opstate { 1349 list rules_status { 1350 key "rule-order rule-name"; 1351 leaf rule-order { 1352 type uint32; 1353 description "order of rules"; 1354 } 1355 leaf rule-name { 1356 type string; 1357 description "rule name"; 1358 } 1359 uses rule_status; 1360 description "eca rule list"; 1361 } 1362 description "rules 1363 operational state"; 1364 } 1366 // rule statistics by name and order 1367 grouping rules_opstats { 1368 list rule-stat { 1370 key "rule-order rule-name"; 1371 leaf rule-order { 1372 type uint32; 1373 description "order of rules"; 1374 } 1375 leaf rule-name { 1376 type string; 1377 description "name of rule"; 1378 } 1379 leaf pkts-matched { 1380 type uint64; 1381 description "number of 1382 packets that matched filter"; 1383 } 1384 leaf pkts-modified { 1385 type uint64; 1386 description "number of 1387 packets that filter caused 1388 to be modified"; 1389 } 1390 leaf pkts-dropped { 1391 type uint64; 1392 description "number of 1393 packets that filter caused 1394 to be modified"; 1395 } 1396 leaf bytes-dropped { 1397 type uint64; 1398 description "number of 1399 packets that filter caused 1400 to be modified"; 1401 } 1402 leaf pkts-forwarded { 1403 type uint64; 1404 description "number of 1405 packets that filter caused 1406 to be forwarded."; 1407 } 1408 leaf bytes-forwarded { 1409 type uint64; 1410 description "number of 1411 packets that filter caused 1412 to be forwarded."; 1413 } 1415 description "list of 1416 operational statistics for each 1417 rule."; 1419 } 1420 description "statistics 1421 on packet filter matches, and 1422 based on matches on many were 1423 modified and/or forwarded"; 1424 } 1426 grouping packet-size-match { 1427 leaf l1-size-match { 1428 type uint32; 1429 description "L1 packet match size."; 1430 } 1431 leaf l2-size-match { 1432 type uint32; 1433 description "L2 packet match size."; 1434 } 1435 leaf l3-size-match { 1436 type uint32; 1437 description "L3 packet match size."; 1438 } 1439 leaf l4-size-match { 1440 type uint32; 1441 description "L4 packet match size."; 1442 } 1443 leaf service-meta-size { 1444 type uint32; 1445 description "service meta info match size."; 1446 } 1447 leaf service-meta-payload { 1448 type uint32; 1449 description "service meta-play match size"; 1450 } 1451 description "packet size by layer 1452 only non-zero values are matched"; 1453 } 1455 grouping time-day-match { 1457 description "matches for 1458 time of day."; 1459 } 1461 grouping eca-matches { 1462 uses interface-match; 1463 uses L1-header-match; 1464 uses L2-header-match; 1465 uses L3-header-match; 1466 uses L4-header-match; 1467 uses service-header-match; 1468 uses packet-size-match; 1469 uses time-day-match; 1470 description "ECA matches"; 1471 } 1473 grouping eca-qos-actions { 1474 leaf cnt-actions { 1475 type uint32; 1476 description "count of ECA actions"; 1477 } 1478 uses interface-actions; 1479 uses L1-header-actions; 1480 uses l2-header-mod-actions; 1481 uses L3-header-actions; 1482 uses L4-header-actions; 1484 description "ECA set or change 1485 packet Actions. Actions may be 1486 added here for interface, 1487 L1, L2, L3, L4 nad service forwarding 1488 headers."; 1489 } 1491 grouping ip-next-fwd { 1492 leaf rib-name { 1493 type string; 1494 description "name of RIB"; 1495 } 1496 leaf next-hop-name { 1497 type string; 1498 description "name of next hop"; 1499 } 1500 description "ECA set or change 1501 packet Actions"; 1502 } 1504 grouping eca-fwd-actions { 1505 leaf interface-fwd { 1506 type if:interface-ref; 1507 description "name of interface to forward on"; 1508 } 1509 uses i2rs-rib:nexthop; 1510 uses ip-next-fwd; 1511 leaf drop-packet { 1512 type boolean; 1513 description "drop packet flag"; 1514 } 1515 description "ECA forwarding actions"; 1516 } 1518 grouping pkt-eca-policy-set { 1519 list groups { 1520 key "group-name"; 1521 leaf group-name { 1522 type string; 1523 description 1524 "name of group of rules"; 1525 } 1526 leaf vrf-name { 1527 type string; 1528 description "VRF name"; 1529 } 1530 uses rt:address-family; 1531 list group-rule-list { 1532 key "rule-name"; 1533 leaf rule-name { 1534 type string; 1535 description "name of rule"; 1536 } 1537 leaf rule-order-id { 1538 type uint16; 1539 description "rule-order-id"; 1540 } 1541 description "rules per group"; 1542 } 1543 description "pkt eca rule groups"; 1544 } 1545 list eca-rules { 1546 key "order-id eca-rule-name"; 1547 ordered-by user; 1548 leaf order-id { 1549 type uint16; 1550 description "Number of order 1551 in ordered list (ascending)"; 1552 } 1553 leaf eca-rule-name { 1554 type string; 1555 description "name of rule"; 1556 } 1557 leaf installer { 1558 type string; 1559 description 1560 "Id of I2RS client 1561 that installs this rule."; 1562 } 1563 uses eca-matches; 1564 uses eca-qos-actions; 1565 uses eca-fwd-actions; 1566 description "ECA rules"; 1567 } // end of rule 1568 description "Policy sets."; 1569 } 1571 grouping pkt-eca-opstate { 1572 uses groups-status; 1573 uses rule-group-link; 1574 uses rules_opstate; 1575 uses rules_opstats; 1576 description "pkt eca policy 1577 op-state main"; 1578 } 1580 container pkt-eca-policy-opstate { 1581 config "false"; 1582 uses pkt-eca-opstate; 1583 description "operational state"; 1584 } 1585 } 1586 1588 6. IANA Considerations 1590 This draft requests IANA Assign a urn in the IETF yang module space 1591 for: 1593 "urn:ietf:params:xml:ns:yang:ietf-pkt-eca-policy"; 1595 associated prefix "pkt-eca"; 1597 7. Security Considerations 1599 These generic filters are used in the I2RS FB-RIBs to filter packets 1600 in a traffic stream, act to modify packets, and forward data packets. 1601 These I2RS filters operate dynamically at same level as currently 1602 deployed configured filter-based RIBs to filter, change, and forward 1603 traffic. The dynamic nature of this protocol requires that I2RS 1604 Filters track the installer of group information and rules. 1606 This section will be augmented after a discussion with security 1607 experts. 1609 8. Informative References 1611 [I-D.ietf-i2rs-architecture] 1612 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1613 Nadeau, "An Architecture for the Interface to the Routing 1614 System", draft-ietf-i2rs-architecture-15 (work in 1615 progress), April 2016. 1617 [I-D.ietf-i2rs-rib-info-model] 1618 Bahadur, N., Kini, S., and J. Medved, "Routing Information 1619 Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work 1620 in progress), October 2015. 1622 [I-D.ietf-netconf-restconf] 1623 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1624 Protocol", draft-ietf-netconf-restconf-13 (work in 1625 progress), April 2016. 1627 [I-D.ietf-netmod-acl-model] 1628 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 1629 "Network Access Control List (ACL) YANG Data Model", 1630 draft-ietf-netmod-acl-model-07 (work in progress), March 1631 2016. 1633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1634 Requirement Levels", BCP 14, RFC 2119, 1635 DOI 10.17487/RFC2119, March 1997, 1636 . 1638 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, 1639 "Policy Core Information Model -- Version 1 1640 Specification", RFC 3060, DOI 10.17487/RFC3060, February 1641 2001, . 1643 [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) 1644 Extensions", RFC 3460, DOI 10.17487/RFC3460, January 2003, 1645 . 1647 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 1648 Moore, "Policy Quality of Service (QoS) Information 1649 Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, 1650 . 1652 Authors' Addresses 1654 Susan Hares 1655 Huawei 1656 7453 Hickory Hill 1657 Saline, MI 48176 1658 USA 1660 Email: shares@ndzh.com 1662 Qin Wu 1663 Huawei 1664 101 Software Avenue, Yuhua District 1665 Nanjing, Jiangsu 210012 1666 China 1668 Email: bill.wu@huawei.com 1670 Russ White 1671 Ericsson 1673 Email: russw@riw.us