idnits 2.17.1 draft-dunbar-i2rs-discover-traffic-rules-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 are 13 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 427 has weird spacing: '... size eve...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 24, 2015) is 3318 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.penno-sfc-yang-13' is mentioned on line 781, but not defined == Unused Reference: 'RFC2119' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: 'I-D.hares-i2rs-info-model-policy' is defined on line 1028, but no explicit reference was found in the text == Unused Reference: 'I-D.hares-i2rs-info-model-service-topo' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'I-D.medved-i2rs-topology-requirements' is defined on line 1070, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-09 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-06 == Outdated reference: A later version (-03) exists of draft-ietf-i2rs-usecase-reqs-summary-00 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-02 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-07 == Outdated reference: A later version (-15) exists of draft-penno-sfc-yang-13 == Outdated reference: A later version (-05) exists of draft-xia-sfc-yang-oam-02 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS Working Group L. Dunbar 3 Internet-Draft S. Hares 4 Intended status: Informational Huawei 5 Expires: September 25, 2015 J. Tantsura 6 Ericsson 7 March 24, 2015 9 An Information Model for Filter Rules for Discovery and Traffic for I2RS 10 Filter-Based RIB 11 draft-dunbar-i2rs-discover-traffic-rules-00 13 Abstract 15 This draft describes an I2RS Filter RIB information model for 16 managing routers to steer traffic to their designated service 17 functions or service function instances via the I2RS interface. The 18 purpose of these filters is to guide the specific flows traversing 19 their assigned Service Function Chains in the network. 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 September 25, 2015. 38 Copyright Notice 40 Copyright (c) 2015 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 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Informational Model Background- SFC . . . . . . . . . . . . . 5 70 3.1. Service Function Chaining . . . . . . . . . . . . . . . . 6 71 3.2. Installing Service Function Chain steering filters using 72 I2RS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.3. SFC Service Layer Steering Policies . . . . . . . . . . . 10 74 3.4. Service Function Instances Discovery . . . . . . . . . . 10 75 3.5. I2RS Use Case Requirements for Service Flow Filtering . . 11 76 3.6. I2RS Use Case Requirements Related to Service Discovery 77 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.7. I2RS Use Case Requirements Related to SFF SHIM function . 12 79 4. Filter-Based RIB Background . . . . . . . . . . . . . . . . . 14 80 5. Information Model for Traffic steering rules . . . . . . . . 15 81 5.1. 5.1 Existing FB-RIB information in RBNF Form . . . . . . 16 82 5.2. 5.2. SFF Filters in RBNF Form . . . . . . . . . . . . . . 17 83 6. 6. Information Model for Interested Service Function 84 Instances . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 6.1. RPC Information Model for Reporting Directly Attached 86 Instances . . . . . . . . . . . . . . . . . . . . . . . . 19 87 6.2. RBNF for Reporting Directly Attached Instances . . . . . 20 88 7. Service Function Forwarder Nodes I2RS Information . . . . . . 20 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 94 11.2. Informative References . . . . . . . . . . . . . . . . . 23 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 97 1. Introduction 99 This draft describes an I2RS Filter RIB information model for 100 managing routers to steer traffic to their designated service 101 functions or service function instances via the I2RS interface. The 102 purpose of these filters is to guide the specific flows traversing 103 along their assigned Service Function Chains in the network. 105 The I2RS Filter-Based RIB (FB-RIB) is described in 106 [I-D.kini-i2rs-fb-fib-info-model]. I2RS FB-RIBs are protocol 107 independent RIBs. 109 An I2RS Filter-Based RIB (FB-RIB) is an entity that contains an 110 ordered set of filters (match/action conditions) and a default RIB of 111 the form found in [I-D.ietf-i2rs-rib-info-model] An ordered set of 112 filters implies that the insertion of a filter router into a FB-RIB 113 must allow for the insertion of a filter-route at a specific position 114 and the deletion of a filter at a specific position. The ability to 115 change a route combines these two functions (deleting existing filter 116 route rule and adding a new policy route). Each I2RS FB-RIB is 117 contained within a routing instance, but one routing instance can 118 contain multiple FB-RIBs. Each routing instance is associated with a 119 set of interface, a router-id, a default RIB. 121 [I-D.kini-i2rs-fb-fib-info-model] describes a generic filter form 122 which has specific filters for L1, L2, L3, and Service level RIBs. 123 This document describes the FB-RIB filters for the following types of 124 service level data forwarding: 126 o a) Traffic flow steering rules on a router for specific Service, 127 Function Path (SFP) or Rendered Service Path (RSP). 129 o b) service function instance discovery traffic (E.g. ARP, ND, or 130 other broadcast/multicast data). 132 I2RS dynamic interface augments the service function configuration, 133 status, and OAM information. This augments yang data models proposed 134 in [I-D.penno-sfc-yang] and [I-D.xia-sfc-yang-oam]. These SFC yang 135 module documents have not been adopted by the SFC WG, but the best 136 indication of this work. 138 Section 3 of this document provides Service-chaining related 139 background for this Information model. This includes background on 140 service function chaining, deployment of service chaining, 141 requirements for I2RS in service chaining. 143 Section 4 provides background on the generic I2rs Filter-Based RIBS, 144 an how these service level traffic filters fit into that generic 145 model. 147 Section 5 contains the description Information Model and Yang data 148 model for traffic flow steering rules. 150 Section 6 contains the description of the Information Model for 151 service function instance discovery traffic and Yang data model for 152 service function instance filters. 154 Section 7 contains the description of the I2RS SFC yang components 155 the traffic features depend on. These service features are being 156 worked on by the SFC WG so shared definitions are necessary. 158 Section 8 contains the security considerations for use of a data 159 model that may arise from this information model. This Information 160 Model is only an intermediate step on the pathway to a deployable 161 yang data model. 163 2. Terminology 165 FB-RIB: Filter-Based Routing Information Base 167 The I2RS protocol independent RIBs operate on a set of interfaces, 168 and contain a ordered list of filter rules (match-condition 169 rules). 171 NFV: Network Function Virtualization 173 [NFV-Terminology]. 175 RSP: Rendered SErvice Function Path (RSP) 177 [I-D.ietf-sfc-architecture] 179 Service Chain 181 [I-D.bitar-i2rs-service-chaining] defines a service chain as an 182 ordered set of services applied to a packet of flow. An example 183 of this is a sequence of service function such as Chain#1 {s1, s4, 184 s6} or Chain#2{s4, s7} at functional level. Also see the 185 definition of Service Function Chain in 186 [I-D.bitar-i2rs-service-chaining] 188 Service Chain Instance Path 189 The actual Service Function Instance Components selected for a 190 service chain. 192 SF: Service Function 194 [I-D.ietf-sfc-problem-statement]. 196 SFF: Service Function Forwarder 198 SFFN: Service Function Forwarder Node 200 [I-D.bitar-i2rs-service-chaining]states service function can run: 201 a) natively within a router (or routing system), b) on a virtual 202 machine on a server or service engine, or in a dedicated 203 standalone hardware appliance. 205 SFFaddr: Service Node Address 207 [I-D.ietf-sfc-problem-statement] states this address should be IP 208 Address, or tuple of (SFFaddr, host system IP address) or tuple of 209 (host system IP address, system internal ID for service engine). 211 Service Type 213 [I-D.ietf-sfc-problem-statement]. 215 VNF: Virtualized Network Function 217 [NFV-Terminology] 219 Virtual Network Instance Identifier 221 Virtual Network Instance ID 223 3. Informational Model Background- SFC 225 Section 3.1 provides the background on service function chaining 226 (SFC), and section 3.2 provides the I2RS use case requirements for 227 the basic service chaining. Section 3.3 provides the overview of how 228 filter rules for traffic flow for specific service function paths 229 (SFPs) and rendered service paths (RSPs). Section 3.4 provides the 230 background on service function instance discovery traffic and how the 231 need for traffic filters. 233 Sections 3.5 provides information on SFC-USE-REQ01 from 234 [I-D.ietf-i2rs-usecase-reqs-summary] which specifies requirements 235 related to the filtering of service chaining traffic flows. 237 Section 3.6 provides information on SFC-USE-REQ02 use case from the 238 same document. SFC-USE-REQ02 is related to handling service- 239 discovery traffic flows. 241 Section 3.7 describes Section 3.7 describes the following I2RS use 242 case requirements: SFC-Use-REQ03, SFC-USE-REQ04, SFC-USE-REQ05, and 243 SFC-USE-REQ06. These use case requirements define SF and SFF 244 information which may be necessary for the I2RS Client to process 245 data related to the SFF traffic filters or service discovery traffic. 247 3.1. Service Function Chaining 249 The Service Function Chain (SFC) [I-D.ietf-sfc-architecture] is 250 defined as an ordered set of abstract service functions (SFs) that 251 must be applied to packets and/or flows that meet certain criteria. 253 The criteria of assigning packets to a service function chain can 254 vary, some can be based on L3/L2 header fields, some can be based on 255 L4 header, and some can be based on L5-L7 header, packet size, 256 special events, or combination of all above. A match filter can be 257 created either by long-term configuration or by the I2RS dynamic 258 interface. 260 For Service Chain with matching criteria that are beyond L2/L3 261 header, such as L4-L7 header or other events, it is more economical 262 to have some specialized nodes with DPI capability to inspect the 263 packets and associate an identifier in the L2/L3 header to the 264 packets that match the SFC criteria. By doing so, the subsequent 265 routers/switches only need to forward based on the identifier (a.k.a. 266 Service Chain identifier). Again, Filters that examine service chain 267 identifiers prior to forwarding traffic can be configured or 268 dynamically created in the I2RS FB-RIB. 270 |1 ----- |n |21 ---- |2m 271 +---+---+ +---+---+ +-+---+ +--+-----+ 272 | SF#1 | |SF#n | |SF#i1| |SF#im | 273 | | | | | | | | 274 +---+---+ +---+---+ +--+--+ +--+--+--+ 275 : : : : : 276 : : : : : 277 \ / \ / 278 +--------------+ +--------+ +---------+ 279 -- >| Chain | | SFF | ------ | SFF | ----> 280 |classifier | |Node-1 | | Node-i | 281 +--------------+ +----+---+ +----+--+-+ 282 \ | / 283 \ | SFC Encapsulation / 284 \ | / 285 ,. ......................................._ 286 ,-' `-. 287 / `. 288 | Network | 289 `. / 290 `.__.................................. _,-' 292 Figure 1 Framework of Service Chain 294 IETF SFC WG has been chartered to create a new Service Chain Header 295 that can carry Service Chain ID plus metadata or/and the actual 296 service function path in the header. However, not every service 297 chain implementation requires the newly created service chain header. 298 BESS WG is working on service function chains using existing MPLS/BGP 299 as the tunnel and/or chain control. 301 [I-D.boucadair-sfc-design-analysis] describes several Service 302 Function Chain mechanisms that do not use new Service Chain Header. 304 This draft describes an I2RS information model for 306 managing Chain Classifier node to assign specific identifier to 307 the packets that match specific criteria via the I2RS interface, 309 managing routers to steer traffic to their designated service 310 functions or service function instances via the I2RS interface, 311 and 313 retrieving SF connectivity to SFF via the I2RS interface for 314 Topology Discovery. 316 A service chain path identifies the exact SFF nodes and SF sequence 317 visited by each SFF node for a specific service function chain. 319 3.2. Installing Service Function Chain steering filters using I2RS 321 It is assumed that there is an external service function chain 322 manager or an orchestration system that computes the Service Function 323 Path including the sequence of SFF nodes and the sequence of service 324 functions for flows to traverse within each SFF node. A service 325 chain path identifies the exact SFF nodes and SF sequence visited by 326 each SFF node for a specific service function chain. 328 It is beyond the scope of I2RS and this draft on how the Service 329 Function Chain orchestration system computes the path. 331 This Service Chain Orchestration System behaves as an I2RS client and 332 uses I2RS interface to instruct routers what filter rules to 333 dynamically install to guide traffic to and along service chain paths 334 as shown in figure 2. The I2RS filter rules include filter 335 classification rules (match rules) and action upon matches forwarding 336 rules, encapsulation rules to next-hop service function, or next-hop 337 SFF nodes). 339 The SFF Shim in the diagram below groups the additional work needed 340 to for Service Functions and pass the steering policies to FB-RIB 341 Manager described in [I-D.kini-i2rs-fb-fib-info-model]. Here is the 342 extra work needed by SFF agent: 344 o Managing the mapping between Service Function Chain identifier 345 (SFC-identifier) and the local identifier on the link to service 346 functions. Some service functions do not terminate the Service 347 Chain ID carried by the packets; some service functions need a 348 different identifier, such as VLAN to differentiate flows. 350 o Managing reachability to directly attached service functions, 352 o Managing balancing among multiple ports that connected to 353 different instances of the same service function type. 355 The SFF Shim can be implemented as part of the orchestrator or as 356 part of an I2RS broker. This document focuses on the I2RS Client-1 357 to I2RS Agent-2 communication which may need to query or modify the 358 above functions. 360 +------------------------------------------------+ 361 |Service Function Chain Manager or Orchestration | 362 | Shim - SFF | 363 | | 364 | I2RS client 2 | 365 +-----------------+------------------------------+ 366 | 367 V 368 +----------+----------+ 369 | I2RS Agent 1 | 370 | +-------+ +-----+ | 371 | |FB-RIB | | RIB | | 372 | +-------+ +-----+ | 373 +---------------------+ 374 | Routing System | 375 +---------------------+ 376 ^ 377 | 378 +---------------------------------+ 379 | | 380 V V 381 +-------------+ +-------------+ 382 |FIB manager 1| |FIB manager M| 383 | +-----+ | .......... | +-----+ | 384 | | FIB | | | | FIB | | 385 | +-----+ | | +-----+ | 386 +-------------+ +-------------+ 387 Figure 2 SFF Shim Layer in relation to RIB Manager 389 The SFF client must be able to instruct the I2RS Agent to 391 o Add/Modify/Delete the filter routes in the FB-RIB based on SFF 392 reachability and SF reachability (locally attached Service 393 functions), 395 o Add/Modify/Delete filter routes in the FB-FIB that direct load 396 balancing for SFF reachability or SF reachability, 398 o Allow FB-RIB filter routes that match a service function 399 identifier to have a forwarding action via interfaces, local- 400 links, tunnels or L3 nexthops or Service layer next-hops. (These 401 type of features are utilized in the I2RS RIB Model 402 ([I-D.ietf-i2rs-rib-info-model] and 403 [I-D.wang-i2rs-rib-data-model]). 405 3.3. SFC Service Layer Steering Policies 407 The SFF nodes are interconnected by tunnels (e.g. GRE or VxLAN) and 408 the SF are attached to a SFF node via Ethernet link or other link 409 types. Therefore, the steering policies to a SFF node for service 410 function chain depends on if the packet comes from previous SFF or 411 comes from a specific SF. Due to this fact, the SFC Service Layer 412 Steering filter routes need to be able to specify the ingress port/ 413 interface in the filter match. 415 There are multiple different steering policies for one flow within 416 one SFF and each set of steering policies is specific for an ingress 417 port/interface. 419 figure 3 421 Ingress Port match 422 | 423 | 424 +-------+--------+--+------+-------+-------+-------+-------+ 425 | | | | | | | | 426 | | | | | | | | 427 L3Header L2header L4 header VLAN VN ID size event .. 429 The action has to be egress port specific. 431 3.4. Service Function Instances Discovery 433 Service Function Instance Discovery is not required to have Service 434 chain forwarding, but this function may provide a useful service in 435 many networks. 437 A Service function instance can be either attached to a router via a 438 physical interface or instantiated on a virtual machine that is 439 attached to a router. However, not every attached host to a router 440 is a service functions. 442 It is assumed that the Service Function Chain Manager or 443 Orchestration can get all the IP addresses or IP prefix of the 444 service function instances from an external authoritative entity, 445 such as a database or provisioning system. However, the SFC 446 orchestration may not know how/where the service function instances 447 are attached to the network, especially in an environment where 448 virtualized hosts can be moved easily. 450 Here is the procedure for Service Chain Orchestration system to 451 discover how/where service function instances are attached in the 452 network: 454 1) The Service Chain Manager or orchestration can passed the 455 Service function addresses or prefix to the relevant SFFs. The 456 SFFs can send ARP/ND broadcast/multicast messages to all the 457 attached nodes. 459 2) Service function instances will respond to ARP (IPv4)/ND (IPv6) 460 requests from its L2/L3 boundary router. 462 3) SFF nodes can report the directly reachable Service function 463 instances to the Service Chain Manager/Controller. 465 Service Chain Manager/Controller 466 ^ | 467 | | A: Set filter for 468 B: | | the interested service 469 Router reports the | | function instances 470 Directly attached | | 471 Service Function | | 472 Instances | V 473 +------+---+-------------+ 474 | Router | 475 ++-----+----------+------+ 476 / | | \ 477 / | | \ 478 +-+-+ +-+-+ +-+-+ +-+-+ 479 | |... | | | | ... | | 480 +---+ +---+ +---+ +---+ Server racks 481 | |... | | | | ... | | for hosting 482 +---+ +---+ +---+ +---+ Service 483 | |... | | | | ... | | Function 484 +---+ +---+ +---+ +---+ Instances 486 Figure 1: Service Function Instances 488 3.5. I2RS Use Case Requirements for Service Flow Filtering 490 This section reviews the requirements for Flow Filtering Policies for 491 SFFNs within the SFC domain. 493 Inherent in the [I-D.ietf-sfc-problem-statement] is the need for 494 policies that establish and filter data flows on the SFFs along the 495 Service Function Chain path. The SFC use case 497 [I-D.bitar-i2rs-service-chaining] and the 498 [I-D.ietf-i2rs-usecase-reqs-summary] suggest the SFF resources that 499 must be on each SFF Node (SFFN). The SFFN resources include the 500 following elements that the I2RS Client-I2RS Agent protocol can 501 utilize in filters: 503 SFC-Use-REQ01:Address (R) 505 has the following address requirements: 507 * IP address 509 * service-node tuple (service node IP address, Host system 510 address) 512 * host-node tuple (hosting system IP-address, system internal 513 identifier) 515 3.6. I2RS Use Case Requirements Related to Service Discovery Traffic 517 The following I2RS Use Case Requirement specifies the following 518 additional information which may be used by the SFF SHIM layer 519 (figure 2) 521 SFC-Use-REQ02:Supported Service Types (R/W) 523 abstract service function type, or can be vendor specific service 524 function types. 526 Note: The current SFC WG suggest hat the SFF does not need to know 527 the SF type on the node in order to steer the data to their 528 designated service function. However, the information can help is 529 the service discovery. 531 3.7. I2RS Use Case Requirements Related to SFF SHIM function 533 The I2RS Use Case Requirements specify the following additional 534 information that this draft suggest may be used by the SFF SHIM layer 535 (figure 2) to calculate flow filters. These features are the 536 following: 538 SFC-Use-REQ03:Virtual contexts (R/W)SHOULD include: 540 * Maximum Number of virtual contexts supported 542 * Current number of virtual contexts in use 543 * Number of virtual contexts available 545 * Supported Context (VRF) 547 SFC-Use-REQ04: Customers currently on node (R) 549 SFC-Use-REQ05: Customer Support Table (per customer ID) (R) 551 with the following contents per entry: 553 * Customer-id 555 * List of supported Virtual Contexts 557 SFC-Use-REQ06: Service Resource Table (R/W) 559 which includes: 561 * index: Comprised of service node, virtual context, service type 563 * service bandwidth capacity 565 * supported packet rate (packets/second) 567 * supported bandwidth (kps) 569 * IP Forwarding support: specified as routing-instance(s), RIBs, 570 Address-families supported 572 * Maximum RIB-size 574 * Maximum Forward Data Base size 576 * Maximum Number of 64 bit statistics counters for policy 577 accounting 579 * Maximum number of supported flows for services 581 SFC-Use-REQ07: Virtual Network Topology (VNT) (R) 583 which includes: 585 * topology of access points 587 4. Filter-Based RIB Background 589 Filter based (FB) routing matches fields in the IP header plus other 590 higher layer packet information. Filters with a match-action pair 591 allow the filters to impact the forwarding of packets. Actions may 592 impact forwarding or set something in the packet that will impact 593 forwarding. 595 A Filter-Based RIB (Routing Information Base) contains a list of 596 filters (match-action conditions) and a default RIB of the form found 597 in [I-D.ietf-i2rs-rib-info-model] The default RIB routes any packet 598 not matched by the order list of filter rules. An order set of 599 filters implies that the I2RS agent must be able to insert a filter 600 route at a specific position and delete a filter route at a specific 601 position. Changing a route is simply a combination of the two 602 (delete a route and add a new route). 604 The Filter-Based RIB found in [I-D.kini-i2rs-fb-fib-info-model] 605 allows for a generic filter that supports L1, L2, L3, and Service 606 matches in the match-condition, or a more specific match-condition 607 filter (E.g. ACL filters found in [I-D.ietf-netmod-acl-model]. 609 Each Filter-Based RIB (FB-RIB)is contained within a routing instance, 610 but one routing instance may contain multiple RB-FIBs. In I2RS 611 Models, each routing instance is associated with a set of interfaces, 612 a router-id, a list of I2RS RIBs, and a list of FB-RIBs. Only some 613 of the interfaces within the routing instance may be associated with 614 a FB-RIB. Each FB-RIB also designates a default destination-based 615 RIB (FB-RIB Default RIB) that forward traffic not matched by the 616 filters. Any traffic not match by the FB-RIB filters or the FB-RIB 617 Default RIB is dropped. 619 Packets arriving on an interface associated with an FB-RIB will be 620 forwarded based on a match to the filters in a FB-RIB associated with 621 that interface. The processing of the packet does the following: 623 o if a packet successfully matches, the rule-actions are applied. 625 o If a packet does not successful match a filter, the filter route 626 processing goes to the next filter in the list. This continues 627 until all filter routes are matched. 629 o If no match has been found within the FB-RIBs on the FB-RIB list, 630 then the packet will be forward to the FB-RIB Default RIB 631 specified by the FB-RIB. If non-exists, then the packet will be 632 discarded. 634 o If no match is found in the FB-RIB Default RIB, the packet will be 635 discarded. 637 5. Information Model for Traffic steering rules 639 The semantics of traffic steering rules is "Match" and "Action". 640 This draft uses the generic match-action filters described in 641 [I-D.kini-i2rs-fb-fib-info-model] which provides filters at L1, L2, 642 L3, L4, Service packets 644 The match filters for SFF need to support the fields in a packet and 645 packet meta-data: 647 o Layer 2: ingress port, destination MAC, source MAC, VLAN ID, GRE 648 Keys, and L2 packet size; 650 o Layer 3:MPLS label, destination IP, source IP, VN-ID, layer 3 651 packet size, 653 o Layer 4: TCP port and UDP port, 655 o Service Chain Identifier (Service-level) 657 The generic match-action filters provide a generic filter format for 658 match actions for packets that examine these L1-L4, and service layer 659 fields. 661 A SFF node may not support some of the matching criteria listed 662 above. It is important that Service Function Chain Orchestration 663 System can retrieve the type of FB-RIB filters supported matching 664 criteria by I2RS agent in the SFF nodes. 666 The Actions for traffic steering could be to steer traffic to the 667 attached service function via a specific port with specific VLAN-ID 668 added, or forward traffic to the next SFF node(s) with specific VxLAN 669 header. 671 When steering to the attached service function, the action may 672 include such things as: 674 o adding VLAN-ID tags, 676 o removing service header fields of a packet have to be removed if 677 packets with a certain header are not supported by the attached 678 service functions; 680 o Forwarding traffic out a particular interface or tunnel. 682 5.1. 5.1 Existing FB-RIB information in RBNF Form 684 ::= [ 685 ] | 686 [] 688 ::= 689 691 :: = 692 693 694 695 696 698 ::= 699 700 702 ::= 703 704 705 706 708 :: 709 ::= [ []] | 710 [] 712 ::= 714 # Generic interface filter from RIB and FB-FIB 715 # Assumed from generic filtering yang document 717 :: = 718 :: = [ . . . ] 719 ::== [ . . . ] 721 :: = [ . . .] 722 ]::=[ ] 723 [ ] 724 [] 725 [ ] 726 [ ] 727 [] 729 ::= [ ...] 731 ::= [