Filter-Based RIB Information Model

The Interface to the Routing System (I2RS) architecture provides dynamic read and write access to the information and state within the routing elements. The I2RS client interacts with the I2RS agent in one or more network routing systems. This document provides a generic information model for a I2RS filter based RIB (FB-RIB) and describes the I2RS interaction with routing filters within a routing element. Filter based (FB) routing matches fields in the IP header plus other higher layer packet information. Filters with a match-action pair allow the filters to impact the forwarding of packets. Actions may impact forwarding or set something in the packet that will impact forwarding. A Filter-Based RIB (Routing Information Base) contains a list of filters (match-action conditions) and a default RIB of the form found in . The default RIB routes any packet not matched by the order list of filter rules. If any packet does not match filter, it is dropped. Some drafts which provide models for match filters are the following: Access lists (ACLs) (Note: This filter provides match-action filters), routing filter policy based on filters for IP prefixes (IPv4, IPv6) (E.g. ) or ordered prefix lists (e.g. ), generic match-policy filters that support QOS filters (E.g. ). routing filters that include BGP originated routes tracked by BGP attribute(asPath, BGP community, extended BGP community, RDs) or peer (), Filters passed in BGP for flows (E.g. )) This generic model for filters aligns with the generic model for topology in providing a simple model that can be utilize for other filters. The abstract filter model utilizes a generic filter based model that can be applied for specific filters at each level. The default RIB specification for the FB-RIB uses the I2RS RIB Model.

+------------------------+ | | | Abstract Network Model | | | +------------------------+ | +-------+-------+-- | | V V +---------------+ +------------+ +-----------+ | Abstract | | Abstract | | I2RS | | Filter-Based | | Topology | | RIB | | (FB)RIB Model | | Model | | Model | +---------------+ +------------+ +-----------+ | augments | +-------------+-------------+-----------+ | | | | V V V V ............ ............ ............ ........... : L1 : : L2 : : L3 : : Service : : FB-RIB : : FB-RIB : : FB-RIB : : FB-RIB : : Model : : Model : : Model : : Model : '''''''''''' '''''''''''' '''''''''''' ''''''''''' Figure 1: The network model structure

Command Line Interface The FB Default RIB is the default Routing Information Based use based for forwarding traffic for routes which do not match any FB-RIB Rule. Filter-Based Routing Information Base IGP is an Interior Gateway Protocol Policy Core Information Model directly and indirectly the work of the PCIM Working Group. The PCIM framework defines a policy rule is often represented by "if Condition then action". The action may have set, modify, or notify actions. This draft uses the filters in , but policy can be used from a variety of filters. The PCIM Framework defines policy groups as a group of policy rules into ordered and prioritized groups of policy. The PCIM framework defines a the Policy set (specifically the PolicySetComponent) as an aggregation class that allows aggregation of Policy Groups and the nesting of Policy Groups under Policy set rules. The PolicySet rules include nesting policies and matching strategies (all-matching or first-match), priorities between rules, and roles. One of the roles that must be conditionally matched is the models denotation of "read-only" or "read-write" policy rules into ordered and prioritized groups of policy. The suggests that non-nested policy groups may be sufficient for I2RS status and configuration work. RIB Informational Model (RIB IM) Routing Code often has the ability to spin up multiple copies of itself into virtual machines. Each Routing code instance or each protocol instance is denoted as N_INSTANCE in the text below.

Filter based routing is a technique used to make packet routing decisions based on filter policies set by the network administrator. Routing decisions in a Filter-Based RIB (FB-RIB) are based on several criteria beyond destination address, such as application, IP protocol used, identity of the end system, and even packet size. Policy actions are typically applied before applying QoS constraints since policy actions may override QoS constraint. The Filter-Based routing may provide many benefits, including better resource allocation, load balancing and QoS. The I2RS use cases which benefit from Filter-Based Routing are: Protocol independent Use cases and large flow use cases described in . The Filter-based policies are specified in most routers/switches as an ordered set of rules. Each policy rule has a set of match conditions, and a set of actions which may include forwarding actions and QoS actions. This draft uses a generic description of filters rules described in , but other policy models could be used if they have the same characteristics. (Note: Antecedents of this generic structure for filter/policy rules can be found in the IETF PCIM work (, , and ).)

A Filter-Based RIB (FB-RIB) information model can be considered in either a top-down view examining the filter policy which controls the RIBs or from a bottom-up view which considers the data plane. A top-down view considers how the I2RS client provides filters for what can be added to a FB-RIB. This draft takes a bottom-up approach and looks at just the routes being installed in the FB-RIB. The bottoms-up view considers how routes link to forwarding data planes that must be supported. In this view, the match filters must consider IP [both IPv4 and IPv6], but may also consider MPLS and encapsulated protocols such as TCP , UDP , STCP , ICMP . This draft takes the bottoms-up viewpoint which looks at how the FB-RIB controls the data plane. This provides a generic FB-FIB description in section 4, and provide FB-FIB extension to cover the L3 IP filter covering IPv4 and IPV6 ) in section 5.

Generic filter rules are described in . The filter rules are included as list of groups of rules which in turn contain rules. This grouping hierarchy allows the ordering of all rules, and a logical group of filter rules based on a logical group (E.g. customers). Within a particular order (E.g. Order 2), priority will establish the filter sequence within the order. If two priorities match, it is assumed the ordering of the filters do not impact the level Each Rule within the Rule list has a rule-action match condition which is based on type. Type can be the "generic filter match-actions" or match actions specific to another type of policy (e.g. ACL rule match-action). For the generic filter match-actions has match field (bnp-term-match), action field (bnp-action), and a forwarding field (bnp-generic forwarding) as figure 1 shows.

+-----------------+ | group of rules | +-----------------+ | +-----------------+ | list of rules | +-----------------+ | +-----------------+ | Rule | +-------|---------+ | +-------------------+ | Rule Match action | +------|------------+ +----|---------------+ +-----|---------+ +-------|-----+ | Generic Rule | | ACL Rule | | match-action | | match-action | +-----------|--+ +--------------+ | +-----------|----|-----------|------------------+ | | | +--------V------+ +----V--------+ +-------V-----+ | bnp term-match| | bnp-action | | bnp-generic | | Condition | | action | | forwarding | | | | | | actions | +--------|------+ +-------|-----+ +-------------+ | | (drop, forward) | | +-------|------|-|-------+ +-|-|-----|------|--------|-+ | | | | | | | | V V V V V V V V ....... ....... ....... .......... ........ ..... ...... ......... :L1 : :L2 : :L3 : : Service: : L1 : :L2 : :L3 : :Service: :match: :match: :match: : match : :action: :act.: :act.: :action : ''''''' ''''''' ''''''' '''''''''' '''''''' ''''' ''''' ''''''''' Figure 2 An example of this hierarchy is shown in figure 2:

Group Name: internal-nets Scope: L3-FB-RIB, R/W group-installer: v-netops rule-list rule-1; name: v-netops-lan order: 1 installer: v-netops status ro-status: active ro-rule-inactive-reason null ro-iule-installer: v-netops priority 1 rule-match-act case:BNP-GENERIC-MATCH-ACTION Case:L3-Header term-match DEST-Header 192.200.1.*/24 term-action: n-acts: 0 term-forward: drop rule-2 name:ICMP packets order: 2 installer: v-netops status: ro-status: inactive ro-rule-inactive-reason: admin-inactive ro-installer-active-filter: (null) priority 3 rule-match-act: Case:BNP-GENERIC_MATCH-ACTION Case:L3-Header term-match: ICMP-Type term-action: n-acts: 0 term-forward: drop Figure 3: Example structure

A Filter-Based RIB (FB-RIB) is an entity that contains an ordered set of filters (match/action conditions) and a default RIB of the form found in . An ordered set of filters implies that the insertion of a filter route into a FB-RIB MUST provide the ability to insert a filter route at any specific position and delete of a filter-based route at a specific position. The ability to change a filter route at a specific position combines these two functions (delete an existing filter route rule and add a new policy rule). Each FB-RIB is contained within a routing instance, but one routing instance (named by an INSTANCE_NAME) can contain multiple FB-RIBs. Each routing instance is associated with a set of interfaces, a router-id, a FB default-RIB, and list of FB-RIBs. Only some of the interfaces associated with a routing instance may be associated with a FB-RIB. Each interface can be associated with at most one FB RIB. Packets arriving on an interface associated with a FB-RIB will be forwarded based on filters in a FB-RIB or the FB-RIB Default RIB (if no matches occur). The processing within the FB-RIB process within the routing system is expected to do the following: When a packet successfully matches match term/entry in a filter-route, the corresponding rule-actions are applied. If a packet does not match the match term/entry in the filter route, the filter route processing goes to the next term/entry in the order, and looks for a match, within the current filter or goes to the next filter in the list. This continues until either a filter route match term/entry is successfully matched, or no more filters in the list exists. If no match has been found within the FB-RIBs on the FB-RIB list, then the packet will be forwarded using the Default-RIB specified by the FB-RIB if one exists. If no Default-RIB is specified, the packet will be discarded.

+-------------------------------+ | routing instance | +--|--------|---------------+---+ | | | | | | +-----------+ +-------------+ +-----------+ |interface* | |FB_RIB *list | | FB-Default| | list | | | |-RIB | +-----------+ +--|----------+ +---|-------+ | RIB (RIB-info IM) ^ /|\ +-----------^-----------+ | FB RIB | +-----------|-----------+ | | +-----------------------+ | FB FIB Ordered List | | of filter rules | +-----------|------------+ | uses bnp generic filter-policy +-----------|------------+ | BNP-Rule-Group* | +-----------|-----------+ | +-----------|--------------+ | BNP-Rule* | |(ordered list of rules of | | the form match-action) | +--------------------------+ Figure 4: Routing instance with FB-RIB

The FB-RIB entries associated with each FB-RIB in a routing instance are: Name of Routing instance router id associated with the FB-RIB function of the Routing instance A list of interfaces that all of the FB-RIB RIBs operate over. This list must be a subset of the interface_list associated with the routing instance. A RIB contained in the same routing instance that can be used to forward packets when the FIB entries in the FB-RIB list do not match the packets. This Default-RIB forwards based on destination based routing. ordered list of filter rules of the form in The Top-level Yang structure for the FB-RIB is:

module: FB-RIB +--FB-RIB-module +--rw FB-RIB-instance-name +--rw RB-RIB-router-id uint32 +--rw FB-RIB-interface* | +--rw FB-RIB-interface interface-ref-id +--rw FB-Default-RIB rib-ref +--rw FB-RIB +--rw FB-RIB-Name +--rw FB-RIB-AFI +--rw FB-RIB-intf* +--rw FB-FIB-status-info | +--rw fb-rib-update-ref uint64 +--rw FB-RIB-Ordered-Filters uses bnp-policy for filters augments /nt:bnp-generic-rules/rule-group/ Figure 4: FB RIB Yang Structure

Each FB-RIB has the following: FB-RIB-Name - Name identifier for FB- RIB FB-RIB-AFI - AFI Supported by the FB-RIB FB-RIB-intf* - Interface FB-FIB operates on. Note that an interface can be associated with at most one FB-RIB. For example interfaces eth1 and eth2 can be associated to FB-RIB, but these two interfaces cannot be connected to any other FB-RIB. FB-RIB-Status-info - status at RIB level which includes number of times since reconfiguration this FB-RIB has been updated. FB-RIB-Ordered-Filters contains list of rule groups Each rule-group is indexed by group name contains: group-name (string) status-info which contains two elements: group status (installed, active or inactive). inactive reason (null, policy-conflict, unsupported). group-installer-identity (string) group order (unit16) ordered rule list

This section provides a short description of the generic filter policy rule's condition-action from which is used by the FB-RIB.

+-----------------------+ | Filter Rule | | | +--|-----------------|--+ : : ....... : : : : +--------V-------+ +-------V-------+ : |Filter Condition| | Filter Action |<... +----------------+ +-+----------+--+ /|\ /|\ "extends"| | "extends" +---+ +--------+ | | +-------^-------+ +-----^---------+ | QoS Action | |Forward Action | +---------------+ +---------------+ : : : : : : ....: : :..... .....: : :..... : : : : : : +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V-----+ |Set | |QoS | |QoS | |Forward ||Next Hop||Next Hop| |Operator| |Variable| |Value | |Operator||Variable||Value | +--------+ +--------+ +------+ +--------++--+-----++--------+ /|\ | "extends" +---^----+ |Next Hop| |Type | +--------+ Figure 5: Filter Actions for FB-RIB The policy/filter rule contains the following: rule-ref - ordered id number for the policy rule rule-status-info - status on the policy rule that contains the following: rule-status - installed, active, or inactive. rule-inactive-reason - can be null, policy-conflict, i2rs-rule-supersedes,unsupported) rule-installer - the entity that installed rule. match-filter - ordered match field for FB-RIB route entry which contains: order- order number in match sequence match-term - contains matches for filters for different packets based on L1, L2, L3, transport, or service level. rule-action* - An ordered list of policy actions that includes the following: n-acts - number of actions Actions: set values in one or more of the following: forwarding-actions - which includes std-forwarding - (enumeration) forwarding packet Drop_Packet - drop packet Drop_Packet_ICMP - dropping packet with ICMP unreachable sent Forward_Packet_specific - send to specific next hop Forward_Packet_default - forward based on FB-RIB Default RIB

The I2RS client-agent pair process within a routing process to add ephemeral these changes to the filter State so that FB-RIB-rules(running) = FB-RIB-config + FB-Rules-I2RS-ephemeral The I2RS ephemeral state will not survive a reboot of the machine. Upon a reboot, the I2RS client must reload the I2RS Agent with the I2RS FB-RIB state lost in the reboot. Writing I2RS FB-rules to permanent configuration may be desirable. This has not been considered in this verison of this draft.

The RIB in a router with I2RS is the following: running RIB = configured-RIB + routes-installed-from-protocols + I2RS-ephemeral-state As described in , the I2RS ephemeral RIB information in routing instance contains a collection of RIBs, interfaces, and routing parameters including the following: The set of interfaces indicates which interfaces are associated with this routing instance. The RIBs specify how incoming traffic is to be forwarded based on destination (E.g. RIB and FB-RIB). The routing parameters control the information in the RIBs. FB-RIB and RIB can not be used at the same time, which means: If a router doesn’t support filter-based routing, a router MUST use RIB and MUST not use FB-RIB. If a router supports filter-based routing: FB-RIB is used Multiple FB-RIBs may exist within a routing instance An interface can be associated with at most one FB-RIB The Default RIB for a FB-RIB is used if several criteria beyond destination address is not matched.

Layer 3 match might contain the following: IPv4 header match with one or these fields: IPv4 source address, IPv4 destination address, IPv4 Protocol, IPv4 TOS/DSCP field, IPv4 ICMP field, and the length of the packet. These matches can be exact matches, longest prefix matches for addresses, or range matches for values in TOS/DSCP field, ICMP field or length of packet. IPv6 header match with one or more match of IPv6 source address, IPv6 destination address, IPvs Traffic class (DSCP), IPv6 Flow label, IPv6 payload length, IPv6 next-header, hop-limit. These matches can be exact matches, longest prefix matches for addresses, or range matches. Layer 3 Actions might set values in: In IPv4 packets set values in any of the following fields: IPv4 source address, IPv4 destination address, IPv4 Protocol, IPv4 TOS/DSCP field, IPv4 ICMP field or the length of the packet. (Please note that hardware data plane forwarders may only be able to set TOS/DSCP while software data plane forwarders may be able set additional fields.) In IPv6 packets set values in any of the following fields: IPv6 source address, IPv6 destination address, IPv6 Protocol value, IPv6 Flow, or IPv6 packet length. Layer 3 Forwarding can augment the basic to forward via tunnels.

This section record the issues with the initials of the person who recorded it. - The authors believe the forwarding per interface is covered by the attachment of a FB-RIB to interface-list. The authors believe this structure can be used by either centralized or distributed forwarding for configuration or the I2RS ephemeral data structure The authors believe this yang modules describes the filters which provides a specific enforcement of forwarding policy. The wider constraints of how filter policy is stored as filter rules or groups of filters rules can be done as the generic network policy as described in or other policy. Other forms of policy rule filter sets can be used. Detection of filter rule conflicts are done by the agent module receiving the filters from configuration or ephemeral I2RS stream. The filter can be reject or installed and rejected from active use due to conflicts at either a group level or the filter rule level. At the policy group level the group-policy-status-info contains a status of installed, active, or installed-inactive. If the status is inactive the group-policy-inactive-reason can indicate policy-conflicts. The policy-rule has a similar status (policy-rule-status-info with policy-rule-status and policy-rule-inactive-reason).

This draft includes no request to IANA.

TBD.