idnits 2.17.1 draft-kini-i2rs-fb-rib-info-model-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 395: '...rt filter-based routing, a router MUST...' RFC 2119 keyword, line 396: '... use RIB and MUST not use FB-RIB. ...' RFC 2119 keyword, line 426: '...te into a FB-RIB MUST provide the abil...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 550 has weird spacing: '...opstate opera...' == Line 686 has weird spacing: '...bgp-rib strin...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * If a router doesn't support filter-based routing, a router MUST use RIB and MUST not use FB-RIB. The default RIB for a FB-RIB should destination-based RIB, and this RIB may be generated by routing protocols. However, the FB-RIB forwarding must take precedence over the default RIB. -- The document date (February 7, 2016) is 2994 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-i2rs-architecture' is mentioned on line 800, but not defined == Missing Reference: 'I-D.ietf-i2rs-rib-info-model' is mentioned on line 818, but not defined == Missing Reference: 'I-D.hares-i2rs-pkt-eca-data-model' is mentioned on line 795, but not defined == Missing Reference: 'I-D.ietf-i2rs-ephemeral-state' is mentioned on line 806, but not defined == Missing Reference: 'I-D.ietf-i2rs-rib-data-model' is mentioned on line 811, but not defined == Missing Reference: 'I-D.hares-i2rs-fb-rib-data-model' is mentioned on line 789, but not defined == Missing Reference: 'RFC2119' is mentioned on line 823, but not defined == Missing Reference: 'RFC7223' is mentioned on line 828, but not defined ** Obsolete undefined reference: RFC 7223 (Obsoleted by RFC 8343) == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-09 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-06 == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-20 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 2 errors (**), 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. Kini 3 Internet-Draft Ericsson 4 Intended status: Standards Track S. Hares 5 Expires: August 10, 2016 L. Dunbar 6 Huawei 7 A. Ghanwani 8 R. Krishnan 9 Dell 10 D. Bogdanovic 11 Juniper Networks 12 R. White 13 Linkedin 14 February 7, 2016 16 Filter-Based RIB Information Model 17 draft-kini-i2rs-fb-rib-info-model-03 19 Abstract 21 This document defines an information model associated with the I2RS 22 ephemeral state for filter-based routing of IP packets via a Filter- 23 based Routing Information Base (FB-RIB). FB-RIBs (ephemeral and non- 24 ephemeral) are associated with specific interfaces interfaces on a 25 routing device, and process packets received on these interfaces 26 according a filtering policy. A filtering policy is a a minimalistic 27 event-match_condition-action (ECA) policy with only one event - the 28 reception of a frame/packet of data on an interface. The match 29 conditions in the filter policy are n-tuple matches based on the 30 content of the frame/packet or the time of its arrival. Filter-based 31 policy allows actions which modifying the frame/packet, forward the 32 frame or packet, or drop the frame/packet. Filter-Based Policy in 33 FB-RIBs engages before any destination based routing so the FB-RIBs 34 provide a destination-based default RIB that will be used if none of 35 the filters are matched. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on August 10, 2016. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Definition of I2RS Filter Based RIB . . . . . . . . . . . 3 73 1.2. I2RS Use Cases Suported by Filter-Based RIB . . . . . . . 4 74 1.3. Definitions and Acronyms . . . . . . . . . . . . . . . . 4 75 2. I2RS Filter-Based RIB place among Filter-Based RIBS . . . . . 5 76 2.1. Ephemeral State versus Configuration State . . . . . . . 5 77 2.2. Need for Order . . . . . . . . . . . . . . . . . . . . . 6 78 2.3. ECA Policy Supported . . . . . . . . . . . . . . . . . . 8 79 2.4. Relationship between Filter-RIBs and RIBS . . . . . . . . 8 80 3. Filter-Based-RIB module . . . . . . . . . . . . . . . . . . . 9 81 3.1. ietf-fb-rib Configuration: Top level Container . . . . . 10 82 3.2. ietf-fb-rib-opstate: Operational Top Level Container . . 12 83 3.3. fb-ribs: List of Filter-Based RIBs (Configuration) . . . 14 84 3.4. fb-rib-oper-status - list of filter-ribs with operational 85 status . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 3.5. Packet-reception Event-Condition-Action Policy . . . . . 16 87 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 6.1. Normative References: . . . . . . . . . . . . . . . . . . 19 91 6.2. Informative References . . . . . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction 96 The Interface to the Routing System (I2RS) 97 [I-D.ietf-i2rs-architecture] architecture provides dynamic read and 98 write access to the information and state within the routing 99 elements. The I2RS client interacts with the I2RS agent in one or 100 more network routing systems. 102 This document provides an information module for Filter Based Routing 103 Information Base (FB-RIB) and describes the I2RS interaction with 104 routing filters within a routing element. 106 1.1. Definition of I2RS Filter Based RIB 108 Filter-based routing is a technique used to make packet forwarding 109 decisions based policy-based filters that are matched to the incoming 110 packets. These filter policies are a minimalistic "event-Match 111 Condition-Action" policy with one event - the reception of a frame or 112 packet on an associated interface. The ECA policies have: 114 o event = reception of frame/packet on associated interface, 116 o match condition = policy filters which match portions of frame/ 117 packet, 119 o actions - to modify frame/packet, and forward or drop frame/packet 121 Filter-Based forwarding may match on the condition of any portion of 122 the frame/packet. Figure 1 shows some of the filters that can be 123 applied to the reception of packets. The filter for individual 124 fields can be combined with an "AND" or and "OR", but the default 125 combination is that of an "AND". 127 Ingress filter Matches (for ECA policy) 128 | 129 | 130 +--------+------+------+---+--+-----+-----+----+-----+------+------+ 131 | | | | | | | | | | 132 | | | | | | | | | | 133 L1 L2 L3 L4 VLAN VNID size Time packet/ ... 134 header header header header header frame 135 receive 136 count 138 Figure 1: Possible matching conditions for basic network filters 140 A Filter-Based Routing Information Base (FB-RIB)) is a set of packet- 141 reception ECA policy rules which are: 143 o ordered, and 145 o apply to specific interfaces 147 If all matches fail, default action is to forward the packet using a 148 specific RIB from: 150 o routing RIBs as described in [I-D.ietf-netmod-routing-cfg]" 152 o ephemeral I2RS RIBs as described in 153 [I-D.ietf-i2rs-rib-info-model]. 155 1.2. I2RS Use Cases Suported by Filter-Based RIB 157 The I2RS use cases which benefit from Filter-Based Routing are: 159 o Protocol independent Use cases and large flow use cases described 160 in [I-D.hares-i2rs-usecase-reqs-summary]. 162 o the use cases of steering traffic to their designated service 163 functions that are different than the packet's destinations, and 165 o large flow use cases described in 166 [I-D.hares-i2rs-usecase-reqs-summary] 168 1.3. Definitions and Acronyms 170 CLI 172 Command Line Interface 174 FB-RIB 176 Filter-Based Routing Information Base 178 FB-Filter 180 One filter in the filter-based RIB. The filters are Event- 181 Condition-Action filters often represented by the form "if 182 Condition then action". 184 Policy Group 186 Policy Groups are groups of policy rules. The groups of policy in 187 the basic network policy [I-D.hares-i2rs-pkt-eca-data-model] allow 188 grouping of policy by name. This name allow easier management of 189 customer-based or provider based filters. 191 RIB IM 193 RIB Informational Model (RIB IM) is an information model which 194 describes a Routing Information Base 196 Routing instance 198 A routing instance is a core data model within 199 [I-D.ietf-netmod-routing-cfg]. An instance creates a logical 200 slice of the router and allows different logical slices to 201 communicate to communicate with each other. 203 2. I2RS Filter-Based RIB place among Filter-Based RIBS 205 The following three types of Filter-Based RIBs exist: 207 o Policy Based Routing - configured by packet ECA policy, 209 o I2RS Filter-Based RIBs - proposed by this document, 211 o BGP Flow Specification [RFC5575]. 213 This section examines issues regarding ephemeral versus config state, 214 the need for order within policies, and the current yang support for 215 packet-reception ECA policy. 217 2.1. Ephemeral State versus Configuration State 219 Filter-Based RIBs with packet-reception ECA policy exist in three 220 types of state: configuration state, ephemeral reboot state (I2RS), 221 and BGP Session state. 223 Policy Routing configures the packet-reception ECA policy in 224 configuration state, and runs this policy to specific interfaces. 225 This configuration state may be configured by NETCONF/RESTCONF in 226 yang modules or proprietary configuation via CLI. This specification 227 examines configuration state specified in yang modules and extended 228 by proprietary additions to yang modules. Yang modules which specify 229 the normal routing RIBs include: 231 [I-D.ietf-netmod-routing-cfg] 233 statics routes (TBD) 235 Configuration state set via secure protocols (NETCONF [RFC6241] or 236 RESTCONF [I-D.ietf-netconf-restconf]) and survives the reboot of the 237 system. draft-hares-rtgwg-fb-rib refers to Filter-Based RIB 238 described above which contains an ordered list of packet 239 I2RS ephemeral state [I-D.ietf-i2rs-ephemeral-state] is state which 240 does not persist across a reboot (software or hardware). I2RS 241 ephemeral state can be indicated a portion of a sub-tree, a sub-tree, 242 tree within a yang modules, or a full module. I2RS Ephemeral state 243 may reference configuration state or protocol state (E.g. MPLS LSP 244 or BGP peer state). 246 The I2RS Filter-Based RIB is defined as a ephemeral module with 247 possible links to the following: 249 default RIBs either in the I2RS RIB module 250 [I-D.ietf-i2rs-rib-data-model] or configured RIB 251 [I-D.ietf-netmod-routing-cfg], 253 interfaces that I2RS Filter-Based RIB is running on. 255 BGP Flow Specification [RFC5575] passes packet-reception ECA Policy 256 in BGP UPDATE packets (NLRI and BGP Extended Communities). The BGP 257 Flow Specification packet-reception ECA policy is bgp peer session 258 ephemeral state which disappears when the BGP peer closes the BGP 259 Session. This bgp session ephemeral state can refer to configuration 260 state for interfaces configured, and for default RIBs. [RFC5575] 261 does not consider I2RS configuration state. 263 Precedence between these three types of state is defined as most 264 dynamic to least dyanmic, or 266 1. BGP Session packet-reception Filter Policy, 268 2. I2RS Filter-Based RIB Policy, 270 3. Configuration Filter-RIB Policy (aka Policy RIB). 272 Precedence impacts when two types of state try to operate on the 273 exact same filter match in the policy. However, Filter-Based RIBS 274 operate first on "order" and priority within the order, and then on 275 the level of ephemeral state. 277 2.2. Need for Order 279 Filter-Based RIBs use packet-reception ECA policy instead of 280 destination based forwarding to determine where to forward/send a 281 packet. A packet which matches multiple filters in a Filter-Based 282 RIB will be forwarded based on the first filter matched. Due to 283 first-match processing, the order of filters matters in the process. 284 All Filter-Based RIBs (configuration, I2RS, and BGP Flow 285 Specification) forwarded based on the first match filter. 287 Filter-Based Policy is inserted in the RIB by order number. If order 288 number is tied, then precedence is based on the type of filter, 289 longest prefix match (MAC or IP address (IPv4/IPv6), lowest value, or 290 longest string). It is expected that order will contain a large 291 enough number space to differentiate most policies. 293 Note: [RFC5575] does not support order, but current work is beginning 294 draft-hares-idr-flow-spec-combo-00.txt to support order in BGP flow 295 specification. 297 flow-rule-cmp (a,b) 298 { 299 comp1 = next_component(a); /component is the type of filter 300 comp2 = next_component(b); 301 while (comp1 || comp2) { 302 // component_type returns infinity on end of list 303 if (component_type(comp1) < component_type(comp2)) { 304 return A_HAS_PRECEDENCE; 305 } 307 if (component_type(comp1) > component_type(comp2)) { 308 return B_HAS_PRECEDENCE; 309 } 310 // IP values) 311 if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) { 312 common = MIN(prefix_length(comp1),prefix_length(comp2)); 313 cmp = prefix_compare (comp1,comp2,common); 314 // not equal, lowest value has precedence 315 // equal, longest match has precedence; 316 } else if (component_type (comp1) == MAC_DESTINATION || 317 MAC_SOURCE) { 318 common = MIN(MAC_address_length(comp1), 319 MAC_address_length(comp2)); 320 cmp = MAC_Address_compare(comp1,comp2,common); 321 //not equal, lowest value has precedence 322 //equal, longest match has precedence 323 } else { 324 common = MIN(component_length(comp1), 325 component_length(comp2)); 326 cmp = memcmp(data(comp1), data(comp2), common); 327 //not equal, lowest value has precedence 328 //equal, longest string has precedence 329 } 330 } 331 } 333 Figure 2 - precedence 335 2.3. ECA Policy Supported 337 The filter based-RIB uses event-condition-action policy (ECA) rules. 338 The following policies are used in this version of the yang module: 340 o Access lists (ACLs) [I-D.ietf-netmod-acl-model] 342 o Packet-reception ECA policy [I-D.hares-i2rs-pkt-eca-data-model] 344 Proprietary filters may augment these IETF defined ECA rules. The 345 IETF filters support basic filtering plus QOS and load balancing. 346 Below is an example set of match conditions on ingreessI2RS that the 347 basic I2RS FB-RIB can support. 349 2.4. Relationship between Filter-RIBs and RIBS 351 Filter-based RIBS (FB-RIBs) provide packet-reception event-match 352 condition-action policy, but if the filters do not provide match the 353 Filter-Based RIBs provide default RIBs for destination based 354 forwarding (IP or MAC). The following are restrictionsThe for the 355 default RIBs: 357 o The configuration FB-RIBs can only refer to another configuration 358 RIB. 360 o The I2RS FB-RIBs can refer to a configuration RIB, an I2RS reboot 361 ephemeral RIB, or a BGP Session ephemeral RIB. The BGP peer 362 session may be dropped while a I2RS FB-RIB is in session. If so, 363 all defaults pointing to the BGP RIB must be removed. The I2RS 364 RIB may be removed, and if so all defaults pointing to that route 365 must be removed. The default order of precedence for the default 366 RIB is the BGP-Peer default RIB, the I2RS default FB-RIB, and the 367 configuration default RIB. 369 o The BGP session FB-RIBs can refer to a configuration RIBs, a I2RS 370 Ephemeral RIB, and a BGP RIB. Just as with the I2RS FB-RIB, the 371 precedence if multiple default RIBs exist are: BGP Peer default 372 RIB, then I2RS default RIB, followed by configuration default RIB. 374 o The I2RS Ephemeral RIB module is described in 375 [I-D.ietf-i2rs-rib-info-model] and [I-D.ietf-i2rs-rib-data-model]. 376 The I2RS RIB contains a collection of RIBs with the following 377 information per instance: 379 * The set of interfaces indicates which interfaces are associated 380 with this routing instance. 382 * The RIBs specify how incoming traffic is to be forwarded based 383 on destination (E.g. RIB and FB-RIB). 385 * The routing parameters control the information in the RIBs. 387 o A routing instance may have both an I2RS RIB modules and I2RS FB- 388 FIB modules associated with it. If the I2RS RIB list of 389 interfaces does not contain the list of interfaces the FB-RIB is 390 operating on, then the I2RS RIB must not be installed as a default 391 RIB. 393 o FB-RIB and RIB can not be used at the same time, which means: 395 * If a router doesn't support filter-based routing, a router MUST 396 use RIB and MUST not use FB-RIB. The default RIB for a FB-RIB 397 should destination-based RIB, and this RIB may be generated by 398 routing protocols. However, the FB-RIB forwarding must take 399 precedence over the default RIB. 401 * If a router supports filter-based routing: 403 + FB-RIB is used 405 + Multiple FB-RIBs may exist within a routing instance 407 + An interface can be associated with at most one FB-RIB 409 + The Default RIB for a FB-RIB is used if several criteria 410 beyond destination address is not matched. 412 3. Filter-Based-RIB module 414 A Filter-Based RIB (FB-RIB)contains an ordered set of filter routes 415 where each filter-route is a match condition followed by an action. 416 An FB-RIB is contained in a routing-instance defined by 417 [I-D.ietf-netmod-routing-cfg]. An FB-RIB has a list of interfaces 418 that is a subset of the list of interfaces in the routing-instance 419 that it is contained in. An incoming packet on an interface 420 belonging to a FB-RIB is first handled by the FIB programmed using 421 that FB-RIB. If no match action succeeds, then the packet is 422 forwarded using the FIB programmed using the RIB of that routing 423 instance. 425 An ordered set of filters implies that the insertion of a filter 426 route into a FB-RIB MUST provide the ability to insert a filter route 427 at any specific position and delete of a filter-based route at a 428 specific position. The ability to change a filter route at a 429 specific position combines these two functions (delete an existing 430 filter route rule and add a new policy rule). 432 Each FB-RIB is contained within a routing instance, but one routing 433 instance (named by an INSTANCE_NAME) can contain multiple FB-RIBs. 434 Each routing instance is associated with a set of interfaces, a 435 router-id, and list of FB-RIBs. Each interface can be associated 436 with at most one FB RIB. 438 The processing within the FB-RIB process within the routing system is 439 expected to do the following: 441 o When a packet successfully matches match term/entry in a filter- 442 route, the corresponding rule-actions are applied. 444 o If a packet does not match the match term/entry in the filter 445 route, the filter route processing goes to the next term/entry in 446 the order, and looks for a match, within the current filter or 447 goes to the next filter in the list. This continues until either 448 a filter route match term/entry is successfully matched, or no 449 more filters in the list exists. 451 o If no match has been found within list of filters in FB-RIB list, 452 then the packet will be forwarded using the I2RS RIB specified by 453 the FB-RIB if one exists. If no I2RS RIB is specified, the FB-RIB 454 will check a configured RIB. If no configured RIB exists, the 455 packet will be discarded. 457 Groups within a I2RS FB-RIB allow the logical grouping of rules under 458 a name for ease of access. For example, take two customers. 459 Customer-A has three packet-reception ECA policies that insert rules 460 at order 5, 10, and 20. Customer-B has three packet-reception ECA 461 policies that insert rules at 4, 8, and 9. The use of the group 462 names "Customer-A" and "Customer-B" allow easy addition or deletion 463 of these rules, but do not change the ordering of these rules. 465 3.1. ietf-fb-rib Configuration: Top level Container 467 The FB-RIB configuration entries associated with each FB-RIB in a 468 routing instance are: 470 default-instance-name (FB-FIB-instance-name): default Routing 471 Instance name for all FB-RIBs 473 default-router-id (FB-RIB-router-id): router id associated with the 474 FB-RIB function of the Routing instance 476 config-fb-rib: list of filter-based RIBs created by configuration 477 processes, and described in draft-hares-rtgwg-fb-rib which 478 utilizes [I-D.hares-i2rs-fb-rib-data-model] to define common 479 filter-based RIB structures. 481 i2rs-fb-rib: list of I2RS reboot ephemeral filter-based RIBs. 482 Described in this draft with data model in 483 [I-D.hares-i2rs-fb-rib-data-model] which utilizes 484 [I-D.hares-i2rs-fb-rib-data-model] to define common filter-based 485 RIB structures. 487 bgp-fb-rib: list of BGP Session ephemeral filter-based RIBs 488 Described in this draft, and data model in (draft-hares-idr-bgp- 489 fb-rib-data-model). which utilizes 490 [I-D.hares-i2rs-fb-rib-data-model] to define common filter-based 491 RIB structures, and [I-D.hares-i2rs-pkt-eca-data-model] to the 492 common packet-reception ECA filters. 494 Configuration RIBS 496 +-----------------------------------------+ 497 | routing instance | 498 +-------|-------------|----------------|--+ 499 | | | 500 | | | 501 +---------|----+ +-----|-----+ +--------|-----+ 502 |config-fb-rib | |i2rs-fb-rib| |bgp-fs-fb-rib | 503 +------|-------+ +-----|------+ +------|------+ 504 |............:....|...............| 505 : (uses common structures 506 : in separate lists of FB-RIBs) 507 +--------|----+ 508 |fd-ribs* | 509 | | 510 +--|----------+ 511 | 513 Figure 3: Routing instance with three types of 514 Filter-FIB lists 516 The Top-level Yang structure for a global configuration of Filter- 517 Based RIBs are: 519 Augments rt:logical-network-elements:\ 520 :logical-network-element:network-instances: \ 521 network-instance 523 ietf-fb-rib module 524 +--rw ietf-fb-rib 525 +--rw default-instance-name string 526 +--rw default-router-id rt:router-id 527 +--rw config-fb-ribs 528 if-feature "config-filter-based-RIB"; 529 uses fb-ribs; 530 +--rw i2rs-fb-ribs 531 if-feature "I2RS-filter-based-RIB"; 532 uses fb-rib-t:fb-ribs; 533 +--rw bgp-fs-fb-ribs 534 if-feature "BGP-FS-filter-based-RIB"; 535 uses fb-rib-t:fb-ribs; 537 Figure 5: configuration state 539 3.2. ietf-fb-rib-opstate: Operational Top Level Container 541 The FB-RIB operational state entries associated with each FB-RIB in a 542 routing instance are: 544 default-instance-name (FB-FIB-instance-name): Default Routing 545 Instance for FB-RIBs. 547 default-router-id (FB-RIB-router-id): Default Router ID associated 548 FB-RIBs. 550 config-fb-rib-opstate operational state for config RIB described in 551 draft-hares-rtgwg-fb-rib which utilizes 552 [I-D.hares-i2rs-fb-rib-data-model] to define common structures. 554 i2rs-fb-rib-opstate: operational state for I2RS reboot ephemeral 555 Filter-Based RIB. Logic is described in this draft, and data 556 model is described in [I-D.hares-i2rs-fb-rib-data-model]. Common 557 structures are defined in [I-D.hares-i2rs-fb-rib-data-model]. 559 bgp-fb-rib-opstate: BGP Session ephemeral Filter-Based RIB-interface 560 with logic described in this draft, and data model in (draft- 561 hares-bgp-fb-rib-data-model). Common structures are also defined 562 in [I-D.hares-i2rs-fb-rib-data-model], and 563 [I-D.hares-i2rs-pkt-eca-data-model]. 565 Operational state 567 +-----------------------------------------+ 568 | routing instance | 569 +-------|-------------|----------------|--+ 570 | | | 571 | | | 572 +---------|----+ +-----|------+ +--------|-----+ 573 |config-fb-rib-| |i2rs-fb-rib-| |bgp-fs-fb-rib-| 574 | opstate | | opstate | | opstate | 575 +------|-------+ +-----|------+ +------|-------+ 576 |............:....|...............| 577 : (uses common structures 578 : in separate lists of FB-RIBs) 579 +--------|-----------+ 580 |fb-ribs_oper_status | 581 | | 582 +--|-----------------+ 583 | 585 Figure 4: Routing instance with three types of 586 Filter-FIB lists 588 The Top-level Yang structure for a global operational state of 589 Filter-Based RIBs are: 591 Augments rt:logical-network-elements:\ 592 :logical-network-element:network-instances: \ 593 network-instance 595 ietf-fb-rib module 596 +--rw ietf-fb-rib-opstate 597 +--rw default-instance-name string 598 +--rw default-router-id rt:router-id 599 +--rw config-fb-rib-opstate 600 if-feature "config-filter-based-RIB"; 601 uses fb-rib-t:fb-ribs-oper-status; 602 +--rw i2rs-fb-rib-opstate { 603 if-feature "I2RS-filter-based-RIB"; 604 uses fb-rib-t:fb-ribs-oper-status; 605 +--rw bgp-fs-fb-rib-opstate 606 if-feature "BGP-FS-filter-based-RIB"; 607 uses fb-rib-t:fb-ribs-oper-status; 609 Figure 5: operational state 611 3.3. fb-ribs: List of Filter-Based RIBs (Configuration) 613 Filter-Based RIB structures for configuration (fb-ribs) contain a 614 list of fb-rib structures with the following high-level structure: 616 fb-rib-name: Name of fb-Rib (key), 618 address-family: AFI for Address Family, 620 fb-type: type of FB-RIB (config, I2RS reboot ephemeral, or BGP Flow 621 Specification session ephemeral). 623 Interface_list(FB-RIB-interface): A list of interfaces that all of 624 the FB-RIB RIB operates over. This list must be a subset of the 625 interface_list associated with the routing instance. 627 default-RIBS: structure with default RIBS in configuration space, 628 I2RS RIB space, or BGP VPN space. 630 instance-using: list of instances using this FB-RIB (normally one). 632 fb-rb-updates: Tracking Write-References to this RIB. 634 uses pkt-eca:pkt-eca-policy-set: pkt ECA Policy described in 635 [I-D.hares-i2rs-pkt-eca-data-model] 636 +--------|----+ 637 |FB-RIBs* | 638 | | 639 +--|----------+ 640 | 641 ^ 642 /|\ 643 +-----^---------------------------+ 644 | FB-RIB | 645 +----|-------|----------|-----|---+ 646 | +-----|-----+ +--------+ +-------+ 647 | |interface | |default | |default| 648 | | list | |I2RS | | Config| 649 | | (Names) | | RIB | | RIB | 650 | +-----------+ +--------+ +-------+ 651 | 652 +-----------------------+ 653 | FB-RIB Ordered List | 654 | of pkt ECA policy |---------+ 655 +-----------|-----------+ | 656 | | 657 +-----------|-----------+ | 658 | Groups | | 659 +-----------|-----------+ | 660 | | 661 +-----------|--------------+ | 662 | Rules |------+ 663 |(ordered list of rules of | 664 | the form match-action) | 665 +--------------------------+ 667 Figure 5: fb-rib (configuration FB-RIB) 669 The Top-level Yang structure for the FB-RIB types is: 671 module: fb-rib-types: 672 +--rw fb-ribs 673 +--rw fb-rib* [rib-name] 674 | +--rw rib-name string 675 | | rw fb-type identityref / ephemeral or not 676 | +--rw rib-afi rt:address-family 677 | +--rw fb-rib-intf* [name] 678 | | +--rw name string 679 | | +--rw intf if:interface 680 | +--rw default-rib 681 | | +--rw rt-rib rt:routing:routing-instance:name 682 | | +--rw config-rib string; // config rib name 683 | | +--rw i2rs-rib:routing-instance:name 684 | | +--rw i2rs-rib string; //ephemeral rib name 685 | | +--rw bgp-instance-name string 686 | | +--rw bgp-rib string //session ephemeral 687 | +--rw fb-rib-refs 688 | | +--rw fb-rib-update-ref uint32 /count of writes 689 | +--rw instance-using* 690 | | device:networking-instance:networking-instance-name 691 | +--use pkt-eca:pkt-eca-policy-set 693 Figure 6: FB RIB Type Structure 695 3.4. fb-rib-oper-status - list of filter-ribs with operational status 697 The Filter-Based RIB structures for operational state have the 698 following entries: 700 fb-rib-name: Name of fb-Rib (key) 702 uses pkt-eca:pkt-eca-opstate: pkt ECA policy operational state 703 described in [I-D.hares-i2rs-pkt-eca-data-model] 705 HIgh Level Yang 707 +--rw fb-ribs-oper-status 708 +--rw fb-rib-oper-status* [fb-rib-name] 709 uses pkt-eca:pkt-eca-opstate 711 3.5. Packet-reception Event-Condition-Action Policy 713 The three levels of policy are expressed as: 715 Config Policy definitions 716 ======================================= 717 Policy level: pkt-eca-policy-set 718 group level: pkt-eca-policy-set:groups 719 rule level: bnp-eca-policy-set:rules 721 Operational State for Policy 722 ======================================= 723 Policy level: pkt-eca-policy-opstate 724 group level: pkt-eca-policy-opstate:groups-status 725 rule level: bnp-eca-policy-opstate:rules_opstate* 726 bnp-eca-policy-opstate:rules_opstats* 728 figure 730 High level Yang structure for Configuration and operational status 731 are shown in figure x below. 733 Packet Reception ECA policy 734 module ietf-pkt-eca-policy 735 +--rw pkt-eca-policy-cfg 736 | +--rw pkt-eca-policy-set 737 | +--rw groups* [group-name] 738 | | +--rw vrf-name string 739 | | +--rw address-family 740 | | +--rw group-rule-list* [rule-name] 741 | | | +--rw rule-name 742 | | | +--rw rule-order-id 743 | +--rw rules [order-id rule-name] 744 | +--rw eca-matches 745 | | ... 746 | +--rw eca-qos-actions 747 | | ... 748 | +--rw eca-fwd-actions 749 | | ... 750 +--rw pkt-eca-policy-opstate 751 +--rw pkt-eca-opstate 752 +--rw groups* [group-name] 753 | +--rw rules-installed; 754 | +--rw rules_status* [rule-name] 755 +--rw rule-group-link* [rule-name] 756 | +--rw group-name 757 +--rw rules_opstate* [rule-order rule-name] 758 | +--rw status 759 | +--rw rule-inactive-reason 760 | +--rw rule-install-reason 761 | +--rw rule-installer 762 | +--rw refcnt 763 +--rw rules_op-stats* [rule-order rule-name] 764 +--rw pkts-matched 765 +--rw pkts-modified 766 +--rw pkts-forwarded 768 Figure 4 - High-Level Yang structure. 770 4. IANA Considerations 772 This informational draft does not specify any IANA requests. 774 5. Security Considerations 776 A I2RS defines an ephemeral data store that will dyanamically change 777 traffic paths set by the routing configuration. An I2RS FB-RIB 778 provides dynamic Event-Condition-Action policy that will further 779 change the operation of forwarding by allow dyanmic policy and 780 ephemeral RIBs to alter the traffic paths set by routing 781 configuration. Care must be taken in deployments to use the 782 appropriate security and operational control to make use of the tools 783 the I2RS RIB and I2RS FB-RIB provide. 785 6. References 787 6.1. Normative References: 789 [I-D.hares-i2rs-fb-rib-data-model] 790 Hares, S., Kini, S., Dunbar, L., Ghanwani, A., Krishnan, 791 R., Bogdanovic, D., Tantsura, J., and R. White, "Filter- 792 Based RIB Data Model", draft-hares-i2rs-fb-rib-data- 793 model-01 (work in progress), January 2016. 795 [I-D.hares-i2rs-pkt-eca-data-model] 796 Hares, S., Wu, Q., and R. White, "Filter-Based Packet 797 Forwarding ECA Policy", draft-hares-i2rs-pkt-eca-data- 798 model-00 (work in progress), January 2016. 800 [I-D.ietf-i2rs-architecture] 801 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 802 Nadeau, "An Architecture for the Interface to the Routing 803 System", draft-ietf-i2rs-architecture-12 (work in 804 progress), December 2015. 806 [I-D.ietf-i2rs-ephemeral-state] 807 Haas, J. and S. Hares, "I2RS Ephemeral State 808 Requirements", draft-ietf-i2rs-ephemeral-state-02 (work in 809 progress), September 2015. 811 [I-D.ietf-i2rs-rib-data-model] 812 Wang, L., Ananthakrishnan, H., Chen, M., 813 amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A 814 YANG Data Model for Routing Information Base (RIB)", 815 draft-ietf-i2rs-rib-data-model-04 (work in progress), 816 November 2015. 818 [I-D.ietf-i2rs-rib-info-model] 819 Bahadur, N., Kini, S., and J. Medved, "Routing Information 820 Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work 821 in progress), October 2015. 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, 825 DOI 10.17487/RFC2119, March 1997, 826 . 828 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 829 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 830 . 832 6.2. Informative References 834 [I-D.hares-i2rs-usecase-reqs-summary] 835 Hares, S. and M. Chen, "Summary of I2RS Use Case 836 Requirements", draft-hares-i2rs-usecase-reqs-summary-02 837 (work in progress), May 2015. 839 [I-D.ietf-netconf-restconf] 840 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 841 Protocol", draft-ietf-netconf-restconf-09 (work in 842 progress), December 2015. 844 [I-D.ietf-netmod-acl-model] 845 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 846 "Network Access Control List (ACL) YANG Data Model", 847 draft-ietf-netmod-acl-model-06 (work in progress), 848 December 2015. 850 [I-D.ietf-netmod-routing-cfg] 851 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 852 Management", draft-ietf-netmod-routing-cfg-20 (work in 853 progress), October 2015. 855 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 856 and D. McPherson, "Dissemination of Flow Specification 857 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 858 . 860 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 861 and A. Bierman, Ed., "Network Configuration Protocol 862 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 863 . 865 Authors' Addresses 867 Sriganesh Kini 868 Ericsson 870 Email: sriganesh.kini@ericsson.com 871 Susan Hares 872 Huawei 873 7453 Hickory Hill 874 Saline, MI 48176 875 USA 877 Email: shares@ndzh.com 879 Linda Dunbar 880 Huawei 881 USA 883 Email: linda.dunbar@huawei.com 885 Anoop Ghanwani 886 Dell 888 Email: anoop@alumni.duke.edu 890 Ram Krishnan 891 Dell 893 Email: Ramkri123@gmail.com 895 Dean Bogdanovic 896 Juniper Networks 897 Westford, MA 899 Email: deanb@juniper.net 901 Russ White 902 Linkedin 904 Email: russ@riw.us