idnits 2.17.1 draft-hares-rtgwg-fb-rib-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 440 has weird spacing: '...bgp-rib strin...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (April 4, 2016) is 2944 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) == Missing Reference: 'I-D.ietf-netmod-routing-cfg' is mentioned on line 504, but not defined == Missing Reference: 'I-D.acee-rtgwg-yang-rib-extend' is mentioned on line 482, but not defined == Missing Reference: 'I-D.hares-i2rs-pkt-eca-data-model' is mentioned on line 492, but not defined == Missing Reference: 'I-D.wu-idr-flowspec-yang-cfg' is mentioned on line 509, but not defined == Missing Reference: 'I-D.hares-i2rs-fb-rib-data-model' is mentioned on line 486, but not defined == Missing Reference: 'I-D.ietf-i2rs-rib-data-model' is mentioned on line 497, but not defined == Unused Reference: 'I-D.ietf-i2rs-usecase-reqs-summary' is defined on line 527, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-13 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-08 == Outdated reference: A later version (-03) exists of draft-ietf-i2rs-usecase-reqs-summary-02 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-07 Summary: 0 errors (**), 0 flaws (~~), 14 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 Huawei 4 Intended status: Standards Track R. White 5 Expires: October 6, 2016 LinkedIn 6 April 4, 2016 8 Filter-Based RIB Data Model 9 draft-hares-rtgwg-fb-rib-01 11 Abstract 13 This document defines a yang data model for a Filter-based Routing 14 Information Base (RIB) Yang data model. A routing system uses the 15 Filter-based RIB to program FIB entries that process incoming packets 16 by matching on multiple fields (n-tuple) within the packet and then 17 performing a specified action on it. The FB-RIB can also specify an 18 action to forward the packet according to the FIB entries programmed 19 using the RIBs of its routing instance. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 6, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Definition of I2RS Filter Based RIB . . . . . . . . . . . 2 57 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 1.3. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 59 1.4. Yang High Level (YHL) graphical form . . . . . . . . . . 4 60 2. Where Filter-Based RIB Fits in Global RIBs . . . . . . . . . 5 61 3. Proposed Structure for Filter-Based RIBs . . . . . . . . . . 7 62 4. Yang High Level Structure for FB-RIBs . . . . . . . . . . . . 8 63 4.1. Top Level Yang Structure for ietf-fb-rib . . . . . . . . 9 64 4.2. Filter-Based RIB structures . . . . . . . . . . . . . . . 10 65 5. yang models . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5.1. Filter-Based RIB types . . . . . . . . . . . . . . . . . 11 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8.1. Normative References: . . . . . . . . . . . . . . . . . . 12 71 8.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 This document provides a yang module for flow filter n-tuple policy 77 that is locally configured. This flow filter policy has also been 78 called Policy routing in some implementations. 80 This document defines a yang data model for a Filter-based Routing 81 Information Base (RIB) Yang data model. A routing system uses the 82 Filter-based RIB to program FIB entries that process incoming packets 83 by matching on multiple fields within the packet and then performing 84 a specified action on it. The FB-RIB can also specify an action to 85 forward the packet according to the FIB entries programmed using the 86 RIBs of its routing instance. 88 1.1. Definition of I2RS Filter Based RIB 90 Filter-based routing is a technique used to make packet forwarding 91 decisions based on a n-tuple filter that is matched to the incoming 92 packets and the specified action. It should be noted that that this 93 is distinct from the static routes in the following RIBS: 95 o configured RIB created using static routes in 96 [I-D.ietf-netmod-routing-cfg] 98 o Extended static RIB defined in [I-D.acee-rtgwg-yang-rib-extend], 100 o Ephmeral Protocol Independent RIB defined in 101 [I-D.ietf-i2rs-rib-info-model], or 103 A Filter-Based RIB (Routing Information Base) is contained in a 104 routing instance. It contains a list of filters (match-action 105 conditions), a list of interface the filter-based forwarding operates 106 on. Filter-based RIBs (FB-RIBs) operate only on the interface the 107 FB-RIB are configured on. 109 A Filter Based RIB uses packet forwarding policy. If packet 110 reception is considered an event, then the I2RS Filter-based RIB uses 111 a minimalistic Event-Condition-Action policy. A Filter-based RIB 112 entry specifies matche filters for the fields in a packet (which may 113 include layer 1 to layer 3 header fields, transport or application 114 fields) or size of the packet or interface received on. The matches 115 are contained in an ordered list of filters which contain pairs of 116 match condition-action (aka event-condition-action). 118 If all matches fail, the default action is to forward the packet 119 using FIB entries that were programmed by the default Routing 120 Informational Base (RIB) manager configured in the Filter-Based RIB 121 (FB-RB) 123 Actions in the condition-action pair may impact forwarding or set 124 something in the packet that will impact forwarding. Policy actions 125 are typically applied before applying QoS constraints since policy 126 actions may override QoS constraint. 128 The Filter-Based RIB resides in ephemeral state as does the I2RS RIB 129 and I2RS topology models. 131 1.2. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119] 137 In this document, these words will appear with that interpretation 138 only when in ALL CAPS. Lower case uses of these words are not to be 139 interpreted as carrying RFC-2119 significance. 141 1.3. Definitions and Acronyms 143 CLI 145 Command Line Interface 147 FB-RIB 149 Filter-Based Routing Information Base 151 FB-Route 153 The policy rules in the filter-based RIB are prescriptive of the 154 Event-Condition-Action form which is often represented by if 155 Condition then action. All policy in the filter-based RIB are in 156 a ordered list, ordered by "order-number". Order number is 157 similar to some CLI concepts of line number. 159 Policy Group 161 Policy Groups are groups of policy rules that are set-up for the 162 convenience of operators who wish to link the rules connected to a 163 particular client. 165 * Groups do not affect the order of policy rulies. 167 * The policy groups in the basic network policy 168 [I-D.hares-i2rs-pkt-eca-data-model] allow grouping of policy by 169 name. This name allow easier management of customer-based or 170 provider based filters. This policy group is a second way to 171 access certain policy rules on the policy rule list. 173 RIB IM 175 RIB Informational Model (RIB IM) [I-D.ietf-i2rs-rib-info-model] 177 Routing instance 179 A routing instance, in the context of the FB-FIB is a collection 180 of RIBs, interfaces, and routing parameters. A routing instance 181 creates a logical slice of the router and allows different logical 182 slices; across a set of routers; to communicate with each other. 184 1.4. Yang High Level (YHL) graphical form 186 The High-level Yang graphical representation uses the following 187 symbols: 189 Brackets "[" and "]" enclose list keys. 191 Curly braces "{" and "}" contain names of optional features that 192 make the corresponding node conditional. 194 Abbreviations before data node names: "rw" means configuration 195 (read-write), "ro" state data (read-only), "-x" RPC operations, 196 and "-n" notifications. 198 Symbols after data node names: "?" means an optional node, "!" a 199 container with presence, and "*" denotes a "list" or "leaf-list". 201 Parentheses enclose choice and case nodes, and case nodes are also 202 marked with a colon (":"). 204 Ellipsis ("...") stands for contents of subtrees that are not 205 shown. 207 2. Where Filter-Based RIB Fits in Global RIBs 209 The Top-level Yang structure for a global FB-RIB types (similar to 210 acl) is not defined. The Filter-Based RIB should be defined under 211 this structure under a routing instance. The two things under this 212 RIB would be: configured Filter-Based RIB (aka Policy routing), I2RS 213 reboot Ephemeral Filter-Based RIB. ACLs [I-D.ietf-netmod-acl-model] 214 have the potential to be augmented to be included, but this version 215 of this document does address that issue. 217 The purpose of this section is illustrate why the flow specification 218 policy installed in yang modules loaded into intended configuration 219 needs to be able to be compared. After demonstrating why this is 220 needed, this section suggests a structure for filter-based RIBS. 222 BGP's Flow Specification (BGP-FS) configures filter-based policy in 223 the local BGP configuration, and passes this information in BGP 224 packets (in NLRI and Extended Communities). The BGP-FS YANG model 225 [I-D.wu-idr-flowspec-yang-cfg] specifies the locally configuration, 226 and the derived state that includes the BGP Flow Specifications 227 received. BGP-FS processing may install the locally configured BGP 228 Flow specification in the local FB-RIB. If it does, this policy is 229 like any other locally configured policy. 231 The BGP-FS may installed the flow policy received from a remote BGP 232 peer and stored in derived state. This policy has a different 233 characteristics as it will disappear if the peer connection between 234 the two peers drops, or if the peer changes the BGP-FS policy. Due 235 to the ephemeral nature of the BGP-FS, it should be installed unique. 236 Otherwise, If the local configuration state changes, it cannot 237 differentiate between the true configured state and the ephemeral 238 states (I2RS ephemeral and BGP-session ephemeral). Both I2RS 239 ephemeral and BGP-session ephemeral policy will disappear upon a 240 reboot. 242 ietf-fb-rib module 243 +--rw routing-instance 244 +--rw ietf-fb-rib 245 +--rw default-instance-name string 246 +--rw default-router-id rt:router-id 247 +--rw config-fb-rib // config state 248 uses fb-ribs 249 +--rw I2rs-fb-rib // ephemeral state 250 uses fb-ribs 251 +--rw BGP-FB-RIB // Install derived 252 uses fb-ribs // BGP-FS policy state 254 Figure 6: Global FB RIB Yang Structure 256 I2RS architecture [I-D.ietf-i2rs-architecture] specifies that by 257 default the Local configuration will win if the local configuration 258 changes. In the NETCONF/NETMOD language, the "last write wins". 260 An example will help illustrate this: 262 local configuration installs filter for IP-Dest=128.2/16, IP- 263 SRC=192.5.7/24 DPORT=ALL drop in the running configuration, and 264 then synchronously loads it to the intended configuration and 265 applied configuration. 267 I2RS installs an ephemeral filter for IP-Dest=128.2/16, IP- 268 SRC=192.5.7/24 DPORT=125 forward intended configuration 269 synchronously. 271 BGP-FS processing installs BGP-FS policy for IP-Dest=128.2/16, IP- 272 SRC=192.5.7/24 DPORT=125 forward, traffic-rate by bytes. 274 local configuration install a filter for IP-Dest=128.2/16, IP- 275 SRC=192.5.7/24, DPort=125, drop. This local configuration policy 276 would win over the I2RS policy and the BGP-FS. The I2RS process 277 is required to receive an event indicating the overwrite. The 278 BGP-FS process should also receive an event indicating an 279 overwrite. 281 The I2RS [I-D.ietf-i2rs-architecture] also allows that the preference 282 between local-configuration and I2RS ephemeral state can be 283 determined by operator-applied policy. However, illustrations of 284 this are out of scope for this version of this document. 286 3. Proposed Structure for Filter-Based RIBs 288 There are three levels in the Filter-Based RIBs (FB-RIB) structure: 290 o a global FB-RIB structures, 292 o the common structure of the FB-RIB, and 294 o the groupings that make up the FB-RIB 296 All structures have two types: configuration/ephemeral state and 297 operational state. 299 This yang model describes three types of FB-RIBS: configuration, 300 I2RS, and BGP Flow Specification. The configuration FB-RIB yang 301 module is config state ("config true" and "ephemeral false") and 302 survives a reboot. The I2RS FB-RB yang model is reboot ephemeral 303 ("config true" and "ephemeral true"). The BGP Flow Specification 304 Filter-Based RIB stores policy which is received by the BGP peers, 305 and can be considered policy configured as part of BGP infrastructure 306 ("config true" and "peer-ephemeral true;") 307 Configuration RIBS 309 bgp-fs-fb-rib - is the BGP processes installation of 310 the BGP Flow Specification (BGP-FS) policy rules 311 from remote peers. Locally configured 312 BGP-FS rules are configured in the BGP peer 313 structure. 315 +-----------------------------------------+ 316 | routing instance | 317 +-------|-------------|----------------|--+ 318 | | | 319 | | | 320 +---------|----+ +-----|-----+ +--------|-----+ 321 |config-fb-rib | |i2rs-fb-rib| |bgp-fs-fb-rib | 322 +------|-------+ +-----|------+ +------|------+ 323 |............:....|...............| 324 : (uses common structures 325 : in separate lists of FB-RIBs) 326 +--------|----+ 327 |fb-ribs* | 328 | | 329 +--|----------+ 330 | 332 Figure 3: Routing instance with three types of 333 Filter-FIB lists 335 4. Yang High Level Structure for FB-RIBs 337 The following section provides the high level yang structure diagrams 338 for the following levels of structures for both config/ephemeral 339 state and operationa. 341 o ietf-fb-rib - contains filter-based RIBS for config, I2RS FB-RIB, 342 and BGP Flow Specification. 344 o fb-rib - that contains the structures for the filter-based 345 grouping 347 o fb-rib-types - that contains the structures for groupings within 348 the filter-based RIBS 350 These structures are contained within the yang section in this draft. 352 The packet-reception ECA policy yang module is contained in the draft 353 [I-D.hares-i2rs-pkt-eca-data-model]. 355 For those who desire more information regarding the logic behind the 356 I2RS Filter-Based RIB, please see the Informational Model at: 357 [I-D.kini-i2rs-fb-rib-info-model]. 359 4.1. Top Level Yang Structure for ietf-fb-rib 361 The Top-level Yang structure for a global FB-RIB types (similar to 362 acl) is not defined for filter-based RIBS. The I2RS Filter-Based RIB 363 should be defined under this structure under a routing instance. The 364 three things under this RIB would be: configured Filter-Based RIB 365 (aka Policy routing), I2RS reboot Ephemeral Filter-Based RIB, and BGP 366 Flow Specification's Filter-Based RIB. All of these RIBs have 367 similar actions. 369 There are two types top-level structures for ietf-fb-ribs: config and 370 operational state. 372 The Top-level Yang structure for a global configuration of Filter- 373 Based RIBs are: 375 Augments rt:logical-network-elements:\ 376 :logical-network-element:network-instances: \ 377 network-instance 379 ietf-fb-rib module 380 +--rw ietf-fb-rib 381 +--rw default-instance-name string 382 +--rw default-router-id rt:router-id 383 +--rw config-fb-ribs 384 if-feature "config-filter-based-RIB"; 385 uses fb-ribs; 386 +--rw i2rs-fb-ribs 387 if-feature "I2RS-filter-based-RIB"; 388 uses fb-rib-t:fb-ribs; 389 +--rw bgp-fs-fb-ribs 390 if-feature "BGP-FS-filter-based-RIB"; 391 uses fb-rib-t:fb-ribs; 393 Figure 5: configuration state 395 The Top-level Yang structure for a global operational state of 396 Filter-Based RIBs are: 398 Augments rt:logical-network-elements:\ 399 :logical-network-element:network-instances: \ 400 network-instance 402 ietf-fb-rib module 403 +--rw ietf-fb-rib-opstate 404 +--rw default-instance-name string 405 +--rw default-router-id rt:router-id 406 +--rw config-fb-rib-opstate 407 if-feature "config-filter-based-RIB"; 408 uses fb-rib-t:fb-ribs-oper-status; 409 +--rw i2rs-fb-rib-opstate { 410 if-feature "I2RS-filter-based-RIB"; 411 uses fb-rib-t:fb-ribs-oper-status; 412 +--rw bgp-fs-fb-rib-opstate 413 if-feature "BGP-FS-filter-based-RIB"; 414 uses fb-rib-t:fb-ribs-oper-status; 416 Figure 5: operational state 418 4.2. Filter-Based RIB structures 420 The Top-level yang structures at the Filter-Based RIB level have two 421 types: configuration and operational state. 423 The Top-level Yang structure for the FB-RIB types is: 425 module: fb-rib-types: 426 +--rw fb-ribs 427 +--rw fb-rib* [rib-name] 428 | +--rw rib-name string 429 | | rw fb-type identityref / ephemeral or not 430 | +--rw rib-afi rt:address-family 431 | +--rw fb-rib-intf* [name] 432 | | +--rw name string 433 | | +--rw intf if:interface 434 | +--rw default-rib 435 | | +--rw rt-rib rt:routing:routing-instance:name 436 | | +--rw config-rib string; // config rib name 437 | | +--rw i2rs-rib:routing-instance:name 438 | | +--rw i2rs-rib string; //ephemeral rib name 439 | | +--rw bgp-instance-name string 440 | | +--rw bgp-rib string //session ephemeral 441 | +--rw fb-rib-refs 442 | | +--rw fb-rib-update-ref uint32 /count of writes 443 | +--rw instance-using* 444 | | device:networking-instance:networking-instance-name 445 | +--use pkt-eca:pkt-eca-policy-set 447 Figure 6: FB RIB Type Structure 449 HIgh Level Yang 451 +--rw fb-ribs-oper-status 452 +--rw fb-rib-oper-status* [fb-rib-name] 453 uses pkt-eca:pkt-eca-opstate 455 5. yang models 457 5.1. Filter-Based RIB types 459 Yang model is contained in draft-hares-i2rs-fb-rib-data-model-01.txt 461 Please see this draft for the data model. 463 6. IANA Considerations 465 TBD 467 7. Security Considerations 469 A I2RS RIB is ephemeral data store that will dyanamically change 470 traffic paths set by the routing configuration. An I2RS FB-RIB 471 provides dynamic Event-Condition-Action policy that will further 472 change the operation of forwarding by allow dyanmic policy and 473 ephemeral RIBs to alter the traffic paths set by routing 474 configuration. Care must be taken in deployments to use the 475 appropriate security and operational control to make use of the tools 476 the I2RS RIB and I2RS FB-RIB provide. 478 8. References 480 8.1. Normative References: 482 [I-D.acee-rtgwg-yang-rib-extend] 483 Lindem, A. and Y. Qu, "RIB YANG Data Model", draft-acee- 484 rtgwg-yang-rib-extend-01 (work in progress), March 2016. 486 [I-D.hares-i2rs-fb-rib-data-model] 487 Hares, S., Kini, S., Dunbar, L., Krishnan, R., Bogdanovic, 488 D., and R. White, "Filter-Based RIB Data Model", draft- 489 hares-i2rs-fb-rib-data-model-03 (work in progress), March 490 2016. 492 [I-D.hares-i2rs-pkt-eca-data-model] 493 Hares, S., Wu, Q., and R. White, "Filter-Based Packet 494 Forwarding ECA Policy", draft-hares-i2rs-pkt-eca-data- 495 model-02 (work in progress), February 2016. 497 [I-D.ietf-i2rs-rib-data-model] 498 Wang, L., Ananthakrishnan, H., Chen, M., 499 amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A 500 YANG Data Model for Routing Information Base (RIB)", 501 draft-ietf-i2rs-rib-data-model-05 (work in progress), 502 March 2016. 504 [I-D.ietf-netmod-routing-cfg] 505 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 506 Management", draft-ietf-netmod-routing-cfg-21 (work in 507 progress), March 2016. 509 [I-D.wu-idr-flowspec-yang-cfg] 510 Wu, N., Zhuang, S., and A. Choudhary, "A YANG Data Model 511 for Flow Specification", draft-wu-idr-flowspec-yang-cfg-02 512 (work in progress), October 2015. 514 8.2. Informative References 516 [I-D.ietf-i2rs-architecture] 517 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 518 Nadeau, "An Architecture for the Interface to the Routing 519 System", draft-ietf-i2rs-architecture-13 (work in 520 progress), February 2016. 522 [I-D.ietf-i2rs-rib-info-model] 523 Bahadur, N., Kini, S., and J. Medved, "Routing Information 524 Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work 525 in progress), October 2015. 527 [I-D.ietf-i2rs-usecase-reqs-summary] 528 Hares, S. and M. Chen, "Summary of I2RS Use Case 529 Requirements", draft-ietf-i2rs-usecase-reqs-summary-02 530 (work in progress), March 2016. 532 [I-D.ietf-netmod-acl-model] 533 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 534 "Network Access Control List (ACL) YANG Data Model", 535 draft-ietf-netmod-acl-model-07 (work in progress), March 536 2016. 538 [I-D.kini-i2rs-fb-rib-info-model] 539 Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, 540 R., Bogdanovic, D., and R. White, "Filter-Based RIB 541 Information Model", draft-kini-i2rs-fb-rib-info-model-03 542 (work in progress), February 2016. 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, 546 DOI 10.17487/RFC2119, March 1997, 547 . 549 Authors' Addresses 551 Susan Hares 552 Huawei 553 7453 Hickory Hill 554 Saline, MI 48176 555 USA 557 Email: shares@ndzh.com 559 Russ White 560 LinkedIn 562 Email: russ@riw.us