idnits 2.17.1 draft-kini-i2rs-fb-fib-info-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 479 has weird spacing: '...uter-id uint3...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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: o If a router doesn't support filter-based routing, a router MUST use RIB and MUST not use FB-RIB. -- The document date (March 8, 2015) is 3335 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-i2rs-architecture' is mentioned on line 743, but not defined == Missing Reference: 'I-D.ietf-i2rs-rib-info-model' is mentioned on line 749, but not defined == Missing Reference: 'I-D.ietf-netmod-acl-model' is mentioned on line 754, but not defined == Missing Reference: 'I-D.hares-i2rs-bnp-info-model' is mentioned on line 738, but not defined == Unused Reference: 'RFC2119' is defined on line 795, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-hares-i2rs-usecase-reqs-summary-01 == Outdated reference: A later version (-01) exists of draft-shaikh-rtgwg-policy-model-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 6 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: September 9, 2015 Huawei 6 A. Ghanwani 7 Dell 8 R. Krishnan 9 Brocade 10 Q. Wu 11 Huawei 12 D. Bogdanovic 13 Juniper Networks 14 J. Tantsura 15 R. White 16 Ericsson 17 March 8, 2015 19 Filter-Based RIB Information Model 20 draft-kini-i2rs-fb-fib-info-model-00 22 Abstract 24 This document defines an information model I2RS Filter based RIB 25 (Routing information Model). Filter based forwarding matches fields 26 in the IP header plus other higher layer packet information. These 27 matches may be ordered. Matches may contain actions which could 28 impact forward, such as setting a nexthop. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 9, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4 66 3. Filter-Based Routing Information Model Overview . . . . . . . 5 67 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Generic Rules for Filter-Based RIBS . . . . . . . . . . . 6 69 4. Filter-Based-RIB module . . . . . . . . . . . . . . . . . . . 9 70 4.1. FB-RIB entries . . . . . . . . . . . . . . . . . . . . . 11 71 4.2. FB-RIB Description . . . . . . . . . . . . . . . . . . . 12 72 4.3. Rules on Order Rule . . . . . . . . . . . . . . . . . . . 13 73 4.4. I2RS FB-RIB interaction with configured filter rules . . 15 74 4.5. Relationship between RB-RIB Rule Model and RIB 75 Information Model . . . . . . . . . . . . . . . . . . . . 15 76 5. L3 Match-Action Rules . . . . . . . . . . . . . . . . . . . . 16 77 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 9.1. Normative References: . . . . . . . . . . . . . . . . . . 18 82 9.2. Informative References . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 85 1. Introduction 87 The Interface to the Routing System (I2RS) 88 [I-D.ietf-i2rs-architecture] architecture provides dynamic read and 89 write access to the information and state within the routing 90 elements. The I2RS client interacts with the I2RS agent in one or 91 more network routing systems. 93 This document provides a generic information model for a I2RS filter 94 based RIB (FB-RIB) and describes the I2RS interaction with routing 95 filters within a routing element. 97 Filter based (FB) routing matches fields in the IP header plus other 98 higher layer packet information. Filters with a match-action pair 99 allow the filters to impact the forwarding of packets. Actions may 100 impact forwarding or set something in the packet that will impact 101 forwarding. 103 A Filter-Based RIB (Routing Information Base) contains a list of 104 filters (match-action conditions) and a default RIB of the form found 105 in [I-D.ietf-i2rs-rib-info-model]. The default RIB routes any packet 106 not matched by the order list of filter rules. If any packet does 107 not match filter, it is dropped. 109 Some drafts which provide models for match filters are the following: 111 o Access lists (ACLs) [I-D.ietf-netmod-acl-model] (Note: This filter 112 provides match-action filters), 114 o routing filter policy based on filters for IP prefixes (IPv4, 115 IPv6) (E.g. [I-D.yan-rtgwg-routing-policy-yang]) or ordered 116 prefix lists (e.g. [I-D.zhdankin-idr-bgp-cfg]), 118 o generic match-policy filters that support QOS filters (E.g. 119 [I-D.hares-i2rs-bnp-info-model]). 121 o routing filters that include BGP originated routes tracked by BGP 122 attribute(asPath, BGP community, extended BGP community, RDs) or 123 peer ([I-D.shaikh-rtgwg-policy-model]), 125 o Filters passed in BGP for flows (E.g. [RFC5575])) 127 This generic model for filters aligns with the generic model for 128 topology in providing a simple model that can be utilize for other 129 filters. The abstract filter model utilizes a generic filter based 130 model that can be applied for specific filters at each level. The 131 default RIB specification for the FB-RIB uses the I2RS RIB Model. 133 +------------------------+ 134 | | 135 | Abstract Network Model | 136 | | 137 +------------------------+ 138 | 139 +-------+-------+-- 140 | | 141 V V 142 +---------------+ +------------+ +-----------+ 143 | Abstract | | Abstract | | I2RS | 144 | Filter-Based | | Topology | | RIB | 145 | (FB)RIB Model | | Model | | Model | 146 +---------------+ +------------+ +-----------+ 147 | 148 augments | 149 +-------------+-------------+-----------+ 150 | | | | 151 V V V V 152 ............ ............ ............ ........... 153 : L1 : : L2 : : L3 : : Service : 154 : FB-RIB : : FB-RIB : : FB-RIB : : FB-RIB : 155 : Model : : Model : : Model : : Model : 156 '''''''''''' '''''''''''' '''''''''''' ''''''''''' 158 Figure 1: The network model structure 160 2. Definitions and Acronyms 162 CLI 164 Command Line Interface 166 FB Default RIB 168 The FB Default RIB is the default Routing Information Based use 169 based for forwarding traffic for routes which do not match any FB- 170 RIB Rule. 172 FB-RIB 174 Filter-Based Routing Information Base 176 IGP 178 IGP is an Interior Gateway Protocol 180 PCIM 182 Policy Core Information Model directly and indirectly the work of 183 the PCIM Working Group. 185 Policy Rule 187 The PCIM framework defines a policy rule is often represented by 188 "if Condition then action". The action may have set, modify, or 189 notify actions. This draft uses the filters in 190 [I-D.hares-i2rs-bnp-info-model], but policy can be used from a 191 variety of filters. 193 Policy Group 195 The PCIM Framework defines policy groups as a group of policy 196 rules into ordered and prioritized groups of policy. 198 Policy Set 200 The PCIM framework defines a the Policy set (specifically the 201 PolicySetComponent) as an aggregation class that allows 202 aggregation of Policy Groups and the nesting of Policy Groups 203 under Policy set rules. The PolicySet rules include nesting 204 policies and matching strategies (all-matching or first-match), 205 priorities between rules, and roles. One of the roles that must 206 be conditionally matched is the models denotation of "read-only" 207 or "read-write" policy rules into ordered and prioritized groups 208 of policy. The [I-D.hares-i2rs-bnp-info-model] suggests that non- 209 nested policy groups may be sufficient for I2RS status and 210 configuration work. 212 RIB IM 214 RIB Informational Model (RIB IM) [I-D.ietf-i2rs-rib-info-model] 216 Routing instance 218 Routing Code often has the ability to spin up multiple copies of 219 itself into virtual machines. Each Routing code instance or each 220 protocol instance is denoted as N_INSTANCE in the text below. 222 3. Filter-Based Routing Information Model Overview 224 Filter based routing is a technique used to make packet routing 225 decisions based on filter policies set by the network administrator. 226 Routing decisions in a Filter-Based RIB (FB-RIB) are based on several 227 criteria beyond destination address, such as application, IP protocol 228 used, identity of the end system, and even packet size. Policy 229 actions are typically applied before applying QoS constraints since 230 policy actions may override QoS constraint. 232 The Filter-Based routing may provide many benefits, including better 233 resource allocation, load balancing and QoS. 235 The I2RS use cases which benefit from Filter-Based Routing are: 236 Protocol independent Use cases and large flow use cases described in 237 [I-D.hares-i2rs-usecase-reqs-summary]. 239 The Filter-based policies are specified in most routers/switches as 240 an ordered set of rules. Each policy rule has a set of match 241 conditions, and a set of actions which may include forwarding actions 242 and QoS actions. This draft uses a generic description of filters 243 rules described in [I-D.hares-i2rs-bnp-info-model], but other policy 244 models could be used if they have the same characteristics. 246 (Note: Antecedents of this generic structure for filter/policy rules 247 can be found in the IETF PCIM work ([RFC3060], [RFC3460], and 248 [RFC3644]).) 250 3.1. Scope 252 A Filter-Based RIB (FB-RIB) information model can be considered in 253 either a top-down view examining the filter policy which controls the 254 RIBs or from a bottom-up view which considers the data plane. A top- 255 down view considers how the I2RS client provides filters for what can 256 be added to a FB-RIB. This draft takes a bottom-up approach and 257 looks at just the routes being installed in the FB-RIB. The bottoms- 258 up view considers how routes link to forwarding data planes that must 259 be supported. In this view, the match filters must consider IP [both 260 IPv4 and IPv6], but may also consider MPLS and encapsulated protocols 261 such as TCP [RFC0793], UDP [RFC0768], STCP [RFC4960], ICMP [RFC0792]. 262 This draft takes the bottoms-up viewpoint which looks at how the FB- 263 RIB controls the data plane. 265 This provides a generic FB-FIB description in section 4, and provide 266 FB-FIB extension to cover the L3 IP filter covering IPv4 [RFC0791] 267 and IPV6 [RFC2460]) in section 5. 269 3.2. Generic Rules for Filter-Based RIBS 271 Generic filter rules are described in 272 [I-D.hares-i2rs-bnp-info-model]. The filter rules are included as 273 list of groups of rules which in turn contain rules. This grouping 274 hierarchy allows the ordering of all rules, and a logical group of 275 filter rules based on a logical group (E.g. customers). 277 Within a particular order (E.g. Order 2), priority will establish 278 the filter sequence within the order. If two priorities match, it is 279 assumed the ordering of the filters do not impact the level 281 Each Rule within the Rule list has a rule-action match condition 282 which is based on type. Type can be the "generic filter match- 283 actions" or match actions specific to another type of policy (e.g. 284 ACL rule match-action). For the generic filter match-actions has 285 match field (bnp-term-match), action field (bnp-action), and a 286 forwarding field (bnp-generic forwarding) as figure 1 shows. 288 +-----------------+ 289 | group of rules | 290 +-----------------+ 291 | 292 +-----------------+ 293 | list of rules | 294 +-----------------+ 295 | 296 +-----------------+ 297 | Rule | 298 +-------|---------+ 299 | 300 +-------------------+ 301 | Rule Match action | 302 +------|------------+ 303 +----|---------------+ 304 +-----|---------+ +-------|-----+ 305 | Generic Rule | | ACL Rule | 306 | match-action | | match-action | 307 +-----------|--+ +--------------+ 308 | 309 +-----------|----|-----------|------------------+ 310 | | | 311 +--------V------+ +----V--------+ +-------V-----+ 312 | bnp term-match| | bnp-action | | bnp-generic | 313 | Condition | | action | | forwarding | 314 | | | | | actions | 315 +--------|------+ +-------|-----+ +-------------+ 316 | | (drop, forward) 317 | | 318 +-------|------|-|-------+ +-|-|-----|------|--------|-+ 319 | | | | | | | | 320 V V V V V V V V 321 ....... ....... ....... .......... ........ ..... ...... ......... 322 :L1 : :L2 : :L3 : : Service: : L1 : :L2 : :L3 : :Service: 323 :match: :match: :match: : match : :action: :act.: :act.: :action : 324 ''''''' ''''''' ''''''' '''''''''' '''''''' ''''' ''''' ''''''''' 325 Figure 2 327 An example of this hierarchy is shown in figure 2: 329 Group 330 Name: internal-nets 331 Scope: L3-FB-RIB, R/W 332 group-installer: v-netops 333 rule-list 334 rule-1; 335 name: v-netops-lan 336 order: 1 337 installer: v-netops 338 status 339 ro-status: active 340 ro-rule-inactive-reason null 341 ro-iule-installer: v-netops 342 priority 1 343 rule-match-act 344 case:BNP-GENERIC-MATCH-ACTION 345 Case:L3-Header 346 term-match DEST-Header 192.200.1.*/24 347 term-action: 348 n-acts: 0 349 term-forward: drop 350 rule-2 351 name:ICMP packets 352 order: 2 353 installer: v-netops 354 status: 355 ro-status: inactive 356 ro-rule-inactive-reason: admin-inactive 357 ro-installer-active-filter: (null) 358 priority 3 359 rule-match-act: 360 Case:BNP-GENERIC_MATCH-ACTION 361 Case:L3-Header 362 term-match: ICMP-Type 363 term-action: 364 n-acts: 0 365 term-forward: drop 367 Figure 3: Example structure 369 4. Filter-Based-RIB module 371 A Filter-Based RIB (FB-RIB) is an entity that contains an ordered set 372 of filters (match/action conditions) and a default RIB of the form 373 found in [I-D.ietf-i2rs-rib-info-model]. An ordered set of filters 374 implies that the insertion of a filter route into a FB-RIB MUST 375 provide the ability to insert a filter route at any specific position 376 and delete of a filter-based route at a specific position. The 377 ability to change a filter route at a specific position combines 378 these two functions (delete an existing filter route rule and add a 379 new policy rule). 381 Each FB-RIB is contained within a routing instance, but one routing 382 instance (named by an INSTANCE_NAME) can contain multiple FB-RIBs. 383 Each routing instance is associated with a set of interfaces, a 384 router-id, a FB default-RIB, and list of FB-RIBs. Only some of the 385 interfaces associated with a routing instance may be associated with 386 a FB-RIB. Each interface can be associated with at most one FB RIB. 388 Packets arriving on an interface associated with a FB-RIB will be 389 forwarded based on filters in a FB-RIB or the FB-RIB Default RIB (if 390 no matches occur). The processing within the FB-RIB process within 391 the routing system is expected to do the following: 393 o When a packet successfully matches match term/entry in a filter- 394 route, the corresponding rule-actions are applied. 396 o If a packet does not match the match term/entry in the filter 397 route, the filter route processing goes to the next term/entry in 398 the order, and looks for a match, within the current filter or 399 goes to the next filter in the list. This continues until either 400 a filter route match term/entry is successfully matched, or no 401 more filters in the list exists. 403 o If no match has been found within the FB-RIBs on the FB-RIB list, 404 then the packet will be forwarded using the Default-RIB specified 405 by the FB-RIB if one exists. If no Default-RIB is specified, the 406 packet will be discarded. 408 +-------------------------------+ 409 | routing instance | 410 +--|--------|---------------+---+ 411 | | | 412 | | | 413 +-----------+ +-------------+ +-----------+ 414 |interface* | |FB_RIB *list | | FB-Default| 415 | list | | | |-RIB | 416 +-----------+ +--|----------+ +---|-------+ 417 | RIB (RIB-info IM) 418 ^ 419 /|\ 420 +-----------^-----------+ 421 | FB RIB | 422 +-----------|-----------+ 423 | 424 | 425 +-----------------------+ 426 | FB FIB Ordered List | 427 | of filter rules | 428 +-----------|------------+ 429 | uses bnp generic filter-policy 430 +-----------|------------+ 431 | BNP-Rule-Group* | 432 +-----------|-----------+ 433 | 434 +-----------|--------------+ 435 | BNP-Rule* | 436 |(ordered list of rules of | 437 | the form match-action) | 438 +--------------------------+ 440 Figure 4: Routing instance with FB-RIB 442 4.1. FB-RIB entries 444 The FB-RIB entries associated with each FB-RIB in a routing instance 445 are: 447 instance-name (FB-FIB-instance-name) 449 Name of Routing instance 451 router-id (FB-RIB-router-id) 453 router id associated with the FB-RIB function of the Routing 454 instance 456 Interface_list(FB-RIB-interface) 458 A list of interfaces that all of the FB-RIB RIBs operate over. 459 This list must be a subset of the interface_list associated with 460 the routing instance. 462 Default RIB 464 A RIB contained in the same routing instance that can be used to 465 forward packets when the FIB entries in the FB-RIB list do not 466 match the packets. This Default-RIB forwards based on destination 467 based routing. 469 FB-RIB Order list of policy (FB-FIB-O-Filters 471 ordered list of filter rules of the form in 472 [I-D.hares-i2rs-bnp-info-model] 474 The Top-level Yang structure for the FB-RIB is: 476 module: FB-RIB 477 +--FB-RIB-module 478 +--rw FB-RIB-instance-name 479 +--rw RB-RIB-router-id uint32 480 +--rw FB-RIB-interface* 481 | +--rw FB-RIB-interface interface-ref-id 482 +--rw FB-Default-RIB rib-ref 483 +--rw FB-RIB 484 +--rw FB-RIB-Name 485 +--rw FB-RIB-AFI 486 +--rw FB-RIB-intf* 487 +--rw FB-FIB-status-info 488 | +--rw fb-rib-update-ref uint64 489 +--rw FB-RIB-Ordered-Filters 490 uses bnp-policy for filters 491 augments /nt:bnp-generic-rules/rule-group/ 493 Figure 4: FB RIB Yang Structure 495 4.2. FB-RIB Description 497 Each FB-RIB has the following: 499 o FB-RIB-Name - Name identifier for FB- RIB 501 o FB-RIB-AFI - AFI Supported by the FB-RIB 502 o FB-RIB-intf* - Interface FB-FIB operates on. Note that an 503 interface can be associated with at most one FB-RIB. For example 504 interfaces eth1 and eth2 can be associated to FB-RIB, but these 505 two interfaces cannot be connected to any other FB-RIB. 507 o FB-RIB-Status-info - status at RIB level which includes number of 508 times since reconfiguration this FB-RIB has been updated. 510 o FB-RIB-Ordered-Filters contains list of rule groups 512 * Each rule-group is indexed by group name contains: 514 + group-name (string) 516 + status-info which contains two elements: 518 - group status (installed, active or inactive). 520 - inactive reason (null, policy-conflict, unsupported). 522 - group-installer-identity (string) 524 + group order (unit16) 526 + ordered rule list 528 4.3. Rules on Order Rule 530 This section provides a short description of the generic filter 531 policy rule's condition-action from [I-D.hares-i2rs-bnp-info-model] 532 which is used by the FB-RIB. 534 +-----------------------+ 535 | Filter Rule | 536 | | 537 +--|-----------------|--+ 538 : : ....... 539 : : : : 540 +--------V-------+ +-------V-------+ : 541 |Filter Condition| | Filter Action |<... 542 +----------------+ +-+----------+--+ 543 /|\ /|\ 544 "extends"| | "extends" 545 +---+ +--------+ 546 | | 547 +-------^-------+ +-----^---------+ 548 | QoS Action | |Forward Action | 549 +---------------+ +---------------+ 550 : : : : : : 551 ....: : :..... .....: : :..... 552 : : : : : : 553 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V-----+ 554 |Set | |QoS | |QoS | |Forward ||Next Hop||Next Hop| 555 |Operator| |Variable| |Value | |Operator||Variable||Value | 556 +--------+ +--------+ +------+ +--------++--+-----++--------+ 557 /|\ 558 | "extends" 559 +---^----+ 560 |Next Hop| 561 |Type | 562 +--------+ 563 Figure 5: Filter Actions for FB-RIB 565 The policy/filter rule contains the following: 567 o rule-ref - ordered id number for the policy rule 569 o rule-status-info - status on the policy rule that contains the 570 following: 572 * rule-status - installed, active, or inactive. 574 * rule-inactive-reason - can be null, policy-conflict, i2rs-rule- 575 supersedes,unsupported) 577 * rule-installer - the entity that installed rule. 579 o match-filter - ordered match field for FB-RIB route entry which 580 contains: 582 * order- order number in match sequence 584 * match-term - contains matches for filters for different packets 585 based on L1, L2, L3, transport, or service level. 587 * rule-action* - An ordered list of policy actions that includes 588 the following: 590 + n-acts - number of actions 592 + Actions: set values in one or more of the following: 594 + forwarding-actions - which includes 596 - std-forwarding - (enumeration) forwarding packet 598 o Drop_Packet - drop packet 600 o Drop_Packet_ICMP - dropping packet with ICMP 601 unreachable sent 603 o Forward_Packet_specific - send to specific next hop 605 o Forward_Packet_default - forward based on FB-RIB 606 Default RIB 608 4.4. I2RS FB-RIB interaction with configured filter rules 610 The I2RS client-agent pair process within a routing process to add 611 ephemeral these changes to the filter State so that 613 FB-RIB-rules(running) = FB-RIB-config + FB-Rules-I2RS-ephemeral 615 The I2RS ephemeral state will not survive a reboot of the machine. 616 Upon a reboot, the I2RS client must reload the I2RS Agent with the 617 I2RS FB-RIB state lost in the reboot. 619 Writing I2RS FB-rules to permanent configuration may be desirable. 620 This has not been considered in this verison of this draft. 622 4.5. Relationship between RB-RIB Rule Model and RIB Information Model 624 The RIB in a router with I2RS is the following: 626 running RIB = configured-RIB + routes-installed-from-protocols + 627 I2RS-ephemeral-state 628 As described in [I-D.ietf-i2rs-rib-info-model], the I2RS ephemeral 629 RIB information in routing instance contains a collection of RIBs, 630 interfaces, and routing parameters including the following: 632 o The set of interfaces indicates which interfaces are associated 633 with this routing instance. 635 o The RIBs specify how incoming traffic is to be forwarded based on 636 destination (E.g. RIB and FB-RIB). 638 o The routing parameters control the information in the RIBs. 640 FB-RIB and RIB can not be used at the same time, which means: 642 o If a router doesn't support filter-based routing, a router MUST 643 use RIB and MUST not use FB-RIB. 645 o If a router supports filter-based routing: 647 * FB-RIB is used 649 * Multiple FB-RIBs may exist within a routing instance 651 * An interface can be associated with at most one FB-RIB 653 * The Default RIB for a FB-RIB is used if several criteria beyond 654 destination address is not matched. 656 5. L3 Match-Action Rules 658 Layer 3 match might contain the following: 660 o IPv4 header match with one or these fields: IPv4 source address, 661 IPv4 destination address, IPv4 Protocol, IPv4 TOS/DSCP field, IPv4 662 ICMP field, and the length of the packet. These matches can be 663 exact matches, longest prefix matches for addresses, or range 664 matches for values in TOS/DSCP field, ICMP field or length of 665 packet. 667 o IPv6 header match with one or more match of IPv6 source address, 668 IPv6 destination address, IPvs Traffic class (DSCP), IPv6 Flow 669 label, IPv6 payload length, IPv6 next-header, hop-limit. These 670 matches can be exact matches, longest prefix matches for 671 addresses, or range matches. 673 Layer 3 Actions might set values in: 675 o In IPv4 packets set values in any of the following fields: IPv4 676 source address, IPv4 destination address, IPv4 Protocol, IPv4 TOS/ 677 DSCP field, IPv4 ICMP field or the length of the packet. (Please 678 note that hardware data plane forwarders may only be able to set 679 TOS/DSCP while software data plane forwarders may be able set 680 additional fields.) 682 o In IPv6 packets set values in any of the following fields: IPv6 683 source address, IPv6 destination address, IPv6 Protocol value, 684 IPv6 Flow, or IPv6 packet length. 686 Layer 3 Forwarding can augment the basic to forward via tunnels. 688 6. Open issues 690 This section record the issues with the initials of the person who 691 recorded it. 693 Forwarding per interface (JMH) 695 - The authors believe the forwarding per interface is covered by 696 the attachment of a FB-RIB to interface-list. 698 Centralized or Distributed filter policy Strategy (JMH) 700 The authors believe this structure can be used by either 701 centralized or distributed forwarding for configuration or the 702 I2RS ephemeral data structure 704 policy database-enforcement points architecture (JMH) 706 The authors believe this yang modules describes the filters which 707 provides a specific enforcement of forwarding policy. The wider 708 constraints of how filter policy is stored as filter rules or 709 groups of filters rules can be done as the generic network policy 710 as described in [I-D.hares-i2rs-bnp-info-model] or other policy. 711 Other forms of policy rule filter sets can be used. 713 policy rule conflicts (JMH) 715 Detection of filter rule conflicts are done by the agent module 716 receiving the filters from configuration or ephemeral I2RS stream. 717 The filter can be reject or installed and rejected from active use 718 due to conflicts at either a group level or the filter rule level. 719 At the policy group level the group-policy-status-info contains a 720 status of installed, active, or installed-inactive. If the status 721 is inactive the group-policy-inactive-reason can indicate policy- 722 conflicts. The policy-rule has a similar status (policy-rule- 723 status-info with policy-rule-status and policy-rule-inactive- 724 reason). 726 7. IANA Considerations 728 This draft includes no request to IANA. 730 8. Security Considerations 732 TBD. 734 9. References 736 9.1. Normative References: 738 [I-D.hares-i2rs-bnp-info-model] 739 Hares, S. and Q. Wu, "An Information Model for Basic 740 Network Policy", draft-hares-i2rs-bnp-info-model-01 (work 741 in progress), October 2014. 743 [I-D.ietf-i2rs-architecture] 744 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 745 Nadeau, "An Architecture for the Interface to the Routing 746 System", draft-ietf-i2rs-architecture-09 (work in 747 progress), March 2015. 749 [I-D.ietf-i2rs-rib-info-model] 750 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 751 Information Base Info Model", draft-ietf-i2rs-rib-info- 752 model-05 (work in progress), January 2015. 754 [I-D.ietf-netmod-acl-model] 755 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 756 "Network Access Control List (ACL) YANG Data Model", 757 draft-ietf-netmod-acl-model-02 (work in progress), March 758 2015. 760 9.2. Informative References 762 [I-D.hares-i2rs-usecase-reqs-summary] 763 Hares, S. and M. Chen, "Summary of I2RS Use Case 764 Requirements", draft-hares-i2rs-usecase-reqs-summary-01 765 (work in progress), October 2014. 767 [I-D.shaikh-rtgwg-policy-model] 768 Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, 769 "Routing Policy Configuration Model for Service Provider 770 Networks", draft-shaikh-rtgwg-policy-model-00 (work in 771 progress), January 2015. 773 [I-D.yan-rtgwg-routing-policy-yang] 774 Yan, G. and S. Zhuang, "Yang Data Model for Routing 775 Policy", draft-yan-rtgwg-routing-policy-yang-00 (work in 776 progress), December 2014. 778 [I-D.zhdankin-idr-bgp-cfg] 779 Alex, A., Patel, K., Clemm, A., Hares, S., Jethanandani, 780 M., and X. Liu, "Yang Data Model for BGP Protocol", draft- 781 zhdankin-idr-bgp-cfg-00 (work in progress), January 2015. 783 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 784 August 1980. 786 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 787 1981. 789 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 790 RFC 792, September 1981. 792 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793 793, September 1981. 795 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 796 Requirement Levels", BCP 14, RFC 2119, March 1997. 798 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 799 (IPv6) Specification", RFC 2460, December 1998. 801 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, 802 "Policy Core Information Model -- Version 1 803 Specification", RFC 3060, February 2001. 805 [RFC3460] Moore, B., "Policy Core Information Model (PCIM) 806 Extensions", RFC 3460, January 2003. 808 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 809 Moore, "Policy Quality of Service (QoS) Information 810 Model", RFC 3644, November 2003. 812 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 813 4960, September 2007. 815 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 816 and D. McPherson, "Dissemination of Flow Specification 817 Rules", RFC 5575, August 2009. 819 Authors' Addresses 821 Sriganesh Kini 822 Ericsson 824 Email: sriganesh.kini@ericsson.com 826 Susan Hares 827 Huawei 828 7453 Hickory Hill 829 Saline, MI 48176 830 USA 832 Email: shares@ndzh.com 834 Anoop Ghanwani 835 Dell 837 Email: anoop@alumni.duke.edu 839 Ram Krishnan 840 Brocade 842 Email: ramk@Brocade.com 844 Qin Wu 845 Huawei 846 101 Software Avenue, Yuhua District 847 Nanjing, Jiangsu 210012 848 China 850 Email: bill.wu@huawei.com 852 Dean Bogdanovic 853 Juniper Networks 854 Westford, MA 856 Email: deanb@juniper.net 857 Jeff Tantsura 858 Ericsson 860 Email: Jeff Tantsura jeff.tantsura@ericsson.com 862 Russ White 863 Ericsson 865 Email: russw@riw.us