From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8430.txt | 1571 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1571 insertions(+) create mode 100644 doc/rfc/rfc8430.txt (limited to 'doc/rfc/rfc8430.txt') diff --git a/doc/rfc/rfc8430.txt b/doc/rfc/rfc8430.txt new file mode 100644 index 0000000..32fccf4 --- /dev/null +++ b/doc/rfc/rfc8430.txt @@ -0,0 +1,1571 @@ + + + + + + +Internet Engineering Task Force (IETF) N. Bahadur, Ed. +Request for Comments: 8430 Uber +Category: Informational S. Kini, Ed. +ISSN: 2070-1721 + J. Medved + Cisco + September 2018 + + + RIB Information Model + +Abstract + + Routing and routing functions in enterprise and carrier networks are + typically performed by network devices (routers and switches) using a + Routing Information Base (RIB). Protocols and configurations push + data into the RIB, and the RIB manager installs state into the + hardware for packet forwarding. This document specifies an + information model for the RIB to enable defining a standardized data + model. The IETF's I2RS WG used this document to design the I2RS RIB + data model. This document is being published to record the higher- + level information model decisions for RIBs so that other developers + of RIBs may benefit from the design concepts. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8430. + + + + + + + + + + + + +Bahadur, et al. Informational [Page 1] + +RFC 8430 RIB Information Model September 2018 + + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bahadur, et al. Informational [Page 2] + +RFC 8430 RIB Information Model September 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Conventions Used in This Document . . . . . . . . . . . . 6 + 2. RIB Data . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1. RIB Definition . . . . . . . . . . . . . . . . . . . . . 7 + 2.2. Routing Instance . . . . . . . . . . . . . . . . . . . . 7 + 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 2.4.1. Base Nexthops . . . . . . . . . . . . . . . . . . . . 12 + 2.4.2. Derived Nexthops . . . . . . . . . . . . . . . . . . 14 + 2.4.3. Nexthop Indirection . . . . . . . . . . . . . . . . . 15 + 3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . 16 + 4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . 16 + 5. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6. RIB Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6.1. Nexthop Grammar Explained . . . . . . . . . . . . . . . . 20 + 7. Using the RIB Grammar . . . . . . . . . . . . . . . . . . . . 20 + 7.1. Using Route Preference . . . . . . . . . . . . . . . . . 20 + 7.2. Using Different Nexthop Types . . . . . . . . . . . . . . 20 + 7.2.1. Tunnel Nexthops . . . . . . . . . . . . . . . . . . . 21 + 7.2.2. Replication Lists . . . . . . . . . . . . . . . . . . 21 + 7.2.3. Weighted Lists . . . . . . . . . . . . . . . . . . . 21 + 7.2.4. Protection . . . . . . . . . . . . . . . . . . . . . 22 + 7.2.5. Nexthop Chains . . . . . . . . . . . . . . . . . . . 22 + 7.2.6. Lists of Lists . . . . . . . . . . . . . . . . . . . 23 + 7.3. Performing Multicast . . . . . . . . . . . . . . . . . . 24 + 8. RIB Operations at Scale . . . . . . . . . . . . . . . . . . . 25 + 8.1. RIB Reads . . . . . . . . . . . . . . . . . . . . . . . . 25 + 8.2. RIB Writes . . . . . . . . . . . . . . . . . . . . . . . 25 + 8.3. RIB Events and Notifications . . . . . . . . . . . . . . 25 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 11.2. Informative References . . . . . . . . . . . . . . . . . 27 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 + + + + + + + + + + + + + +Bahadur, et al. Informational [Page 3] + +RFC 8430 RIB Information Model September 2018 + + +1. Introduction + + Routing and routing functions in enterprise and carrier networks are + traditionally performed in network devices. Customarily, routers run + routing protocols, and the routing protocols (along with static + configuration information) populate the Routing Information Base + (RIB) of the router. The RIB is managed by the RIB manager, and the + RIB manager provides a northbound interface to its clients (i.e., the + routing protocols) to insert routes into the RIB. The RIB manager + consults the RIB and decides how to program the Forwarding + Information Base (FIB) of the hardware by interfacing with the FIB + manager. The relationship between these entities is shown in + Figure 1. + + +-------------+ +-------------+ + |RIB Client 1 | ...... |RIB Client N | + +-------------+ +-------------+ + ^ ^ + | | + +----------------------+ + | + V + +---------------------+ + | RIB Manager | + | | + | +--------+ | + | | RIB(s) | | + | +--------+ | + +---------------------+ + ^ + | + +---------------------------------+ + | | + V V + +----------------+ +----------------+ + | FIB Manager 1 | | FIB Manager M | + | +--------+ | .......... | +--------+ | + | | FIB(s) | | | | FIB(s) | | + | +--------+ | | +--------+ | + +----------------+ +----------------+ + + Figure 1: RIB Manager, RIB Clients, and FIB Managers + + Routing protocols are inherently distributed in nature, and each + router makes an independent decision based on the routing data + received from its peers. With the advent of newer deployment + paradigms and the need for specialized applications, there is an + emerging need to guide the router's routing function [RFC7920]. The + + + +Bahadur, et al. Informational [Page 4] + +RFC 8430 RIB Information Model September 2018 + + + traditional network-device RIB population that is protocol based + suffices for most use cases where distributed network control is + used. However, there are use cases that the network operators + currently address by configuring static routes, policies, and RIB + import/export rules on the routers. There is also a growing list of + use cases in which a network operator might want to program the RIB + based on data unrelated to just routing (within that network's + domain). Programming the RIB could be based on other information + (such as routing data in the adjacent domain or the load on storage + and compute) in the given domain. Or, it could simply be a + programmatic way of creating on-demand dynamic overlays (e.g., GRE + tunnels) between compute hosts (without requiring the hosts to run + traditional routing protocols). If there was a standardized, + publicly documented programmatic interface to a RIB, it would enable + further networking applications that address a variety of use cases + [RFC7920]. + + A programmatic interface to the RIB involves two types of operations: + reading from the RIB and writing (adding/modifying/deleting) to the + RIB. + + In order to understand what is in a router's RIB, methods like per- + protocol SNMP MIBs and screen scraping are used. These methods are + not scalable since they are client pull mechanisms and not proactive + push (from the router) mechanisms. Screen scraping is error prone + (since the output format can change) and is vendor dependent. + Building a RIB from per-protocol MIBs is error prone since the MIB + data represents protocol data and not the exact information that went + into the RIB. Thus, just getting read-only RIB information from a + router is a hard task. + + Adding content to the RIB from a RIB client can be done today using + static configuration mechanisms provided by router vendors. However, + the mix of what can be modified in the RIB varies from vendor to + vendor, and the method of configuring it is also vendor dependent. + This makes it hard for a RIB client to program a multi-vendor network + in a consistent and vendor-independent way. + + The purpose of this document is to specify an information model for + the RIB. Using the information model, one can build a detailed data + model for the RIB. That data model could then be used by a RIB + client to program a network device. One data model that has been + based on this document is the I2RS RIB data model [RFC8431]. + + The rest of this document is organized as follows. Section 2 goes + into the details of what constitutes and can be programmed in a RIB. + Guidelines for reading and writing the RIB are provided in Sections 3 + and 4, respectively. Section 5 provides a high-level view of the + + + +Bahadur, et al. Informational [Page 5] + +RFC 8430 RIB Information Model September 2018 + + + events and notifications going from a network device to a RIB client + to update the RIB client on asynchronous events. The RIB grammar is + specified in Section 6. Examples of using the RIB grammar are shown + in Section 7. Section 8 covers considerations for performing RIB + operations at scale. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. RIB Data + + This section describes the details of a RIB. It makes forward + references to objects in the RIB grammar (see Section 6). A high- + level description of the RIB contents is as shown in Figure 2. + Please note that for ease of representation in ASCII art, this + drawing shows a single routing instance, a single RIB, and a single + route. Subsections of this section describe the logical data nodes + that should be contained within a RIB. Sections 3 and 4 describe the + high-level read and write operations. + + network-device + | + | 0..N + | + routing instance(s) + | | + | | + 0..N | | 0..N + | | + interface(s) RIB(s) + | + | + | 0..N + | + route(s) + + Figure 2: RIB Information Model + + + + + + + + + +Bahadur, et al. Informational [Page 6] + +RFC 8430 RIB Information Model September 2018 + + +2.1. RIB Definition + + A RIB, in the context of the RIB information model, is an entity that + contains routes. It is identified by its name and is contained + within a routing instance (see Section 2.2). A network device MAY + contain routing instances, and each routing instance MAY contain + RIBs. The name MUST be unique within a routing instance. All routes + in a given RIB MUST be of the same address family (e.g., IPv4). Each + RIB MUST belong to a routing instance. + + A routing instance may contain two or more RIBs of the same address + family (e.g., IPv6). A typical case where this can be used is for + multi-topology routing [RFC4915] [RFC5120]. + + Each RIB MAY be associated with an ENABLE_IP_RPF_CHECK attribute that + enables Reverse Path Forwarding (RPF) checks on all IP routes in that + RIB. The RPF check is used to prevent spoofing and limit malicious + traffic. For IP packets, the IP source address is looked up and the + RPF interface(s) associated with the route for that IP source address + is found. If the incoming IP packet's interface matches one of the + RPF interfaces, then the IP packet is forwarded based on its IP + destination address; otherwise, the IP packet is discarded. + +2.2. Routing Instance + + A routing instance, in the context of the RIB information model, is a + collection of RIBs, interfaces, and routing parameters. A routing + instance creates a logical slice of the router. It allows different + logical slices across a set of routers to communicate with each + other. Layer 3 VPNs, Layer 2 VPNs (L2VPNs), and Virtual Private LAN + Service (VPLS) can be modeled as routing instances. Note that + modeling an L2VPN using a routing instance only models the Layer 3 + (RIB) aspect and does not model any Layer 2 information (like ARP) + that might be associated with the L2VPN. + + The set of interfaces indicates which interfaces are associated with + this routing instance. The RIBs specify how incoming traffic is to + be forwarded, and the routing parameters control the information in + the RIBs. The intersection set of interfaces of two routing + instances MUST be the null set. In other words, an interface MUST + NOT be present in two routing instances. Thus, a routing instance + describes the routing information and parameters across a set of + interfaces. + + + + + + + + +Bahadur, et al. Informational [Page 7] + +RFC 8430 RIB Information Model September 2018 + + + A routing instance MUST contain the following mandatory fields: + + o INSTANCE_NAME: A routing instance is identified by its name, + INSTANCE_NAME. This MUST be unique across all routing instances + in a given network device. + + o rib-list: This is the list of RIBs associated with this routing + instance. Each routing instance can have multiple RIBs to + represent routes of different types. For example, one would put + IPv4 routes in one RIB and MPLS routes in another RIB. The list + of RIBs can be an empty list. + + A routing instance MAY contain the following fields: + + o interface-list: This represents the list of interfaces associated + with this routing instance. The interface list helps constrain + the boundaries of packet forwarding. Packets coming in on these + interfaces are directly associated with the given routing + instance. The interface list contains a list of identifiers, with + each identifier uniquely identifying an interface. + + o ROUTER_ID: This field identifies the network device in control + plane interactions with other network devices. This field is to + be used if one wants to virtualize a physical router into multiple + virtual routers. Each virtual router MUST have a unique + ROUTER_ID. A ROUTER_ID MUST be unique across all network devices + in a given domain. + + A routing instance may be created purely for the purposes of packet + processing and may not have any interfaces associated with it. For + example, an incoming packet in routing instance A might have a + nexthop of routing instance B, and after packet processing in B, the + nexthop might be routing instance C. Thus, routing instance B is not + associated with any interface. And, given that this routing instance + does not do any control-plane interaction with other network devices, + a ROUTER_ID is also not needed. + +2.3. Route + + A route is essentially a match condition and an action following the + match. The match condition specifies the kind of route (IPv4, MPLS, + etc.) and the set of fields to match on. Figure 3 represents the + overall contents of a route. Please note that for ease of depiction + in ASCII art, only a single instance of the route-attribute, match + flags, and nexthop is depicted. + + + + + + +Bahadur, et al. Informational [Page 8] + +RFC 8430 RIB Information Model September 2018 + + + route + | | | + +---------+ | +----------+ + | | | + 0..N | | | + + route-attribute match nexthop + | + | + +-------+-------+-------+--------+ + | | | | | + | | | | | + + IPv4 IPv6 MPLS MAC Interface + + Figure 3: Route Model + + This document specifies the following match types: + + o IPv4: Match on destination and/or source IP address in the IPv4 + header + + o IPv6: Match on destination and/or source IP address in the IPv6 + header + + o MPLS: Match on an MPLS label at the top of the MPLS label stack + + o MAC: Match on Media Access Control (MAC) destination addresses in + the Ethernet header + + o Interface: Match on the incoming interface of the packet + + A route MAY be matched on one or more of these match types by policy + as either an "AND" (to restrict the number of routes) or an "OR" (to + combine two filters). + + Each route MUST have the following mandatory route-attributes + associated with it: + + o ROUTE_PREFERENCE: This is a numerical value that allows for + comparing routes from different protocols. Static configuration + is also considered a protocol for the purpose of this field. It + is also known as "administrative distance". The lower the value, + the higher the preference. For example, there can be an OSPF + route for 192.0.2.1/32 (or IPv6 2001:DB8::1/128) with a preference + of 5. If a controller programs a route for 192.0.2.1/32 (or IPv6 + 2001:DB8::1/128) with a preference of 2, then the controller's + route will be preferred by the RIB manager. Preference should be + + + +Bahadur, et al. Informational [Page 9] + +RFC 8430 RIB Information Model September 2018 + + + used to dictate behavior. For more examples of preference, see + Section 7.1. + + Each route can have one or more optional route-attributes associated + with it. + + o route-vendor-attributes: Vendors can specify vendor-specific + attributes using this. The details of this attribute are outside + the scope of this document. + + Each route has a nexthop associated with it. Nexthops are described + in Section 2.4. + + Additional features to match multicast packets were considered (e.g., + TTL of the packet to limit the range of a multicast group), but these + were not added to this information model. Future RIB information + models should investigate these multicast features. + +2.4. Nexthop + + A nexthop represents an object resulting from a route lookup. For + example, if a route lookup results in sending the packet out of a + given interface, then the nexthop represents that interface. + + Nexthops can be either fully resolved or unresolved. A resolved + nexthop has adequate information to send the outgoing packet to the + destination by forwarding it on an interface to a directly connected + neighbor. For example, a nexthop to a point-to-point interface or a + nexthop to an IP address on an Ethernet interface has the nexthop + resolved. An unresolved nexthop is something that requires the RIB + manager to determine the final resolved nexthop. For example, a + nexthop could be an IP address. The RIB manager would resolve how to + reach that IP address; for example, is the IP address reachable by + regular IP forwarding, by an MPLS tunnel, or by both? If the RIB + manager cannot resolve the nexthop, then the nexthop remains in an + unresolved state and is NOT a candidate for installation in the FIB. + Future RIB events can cause an unresolved nexthop to get resolved + (e.g., an IP address being advertised by an IGP neighbor). + Conversely, resolved nexthops can also become unresolved (e.g., in + the case of a tunnel going down); hence, they would no longer be + candidates to be installed in the FIB. + + When at least one of a route's nexthops is resolved, then the route + can be used to forward packets. Such a route is considered eligible + to be installed in the FIB and is henceforth referred to as a FIB- + eligible route. Conversely, when all the nexthops of a route are + unresolved, that route can no longer be used to forward packets. + Such a route is considered ineligible to be installed in the FIB and + + + +Bahadur, et al. Informational [Page 10] + +RFC 8430 RIB Information Model September 2018 + + + is henceforth referred to as a FIB-ineligible route. The RIB + information model allows a RIB client to program routes whose + nexthops may be unresolved initially. Whenever an unresolved nexthop + gets resolved, the RIB manager will send a notification of the same + (see Section 5). + + The overall structure and usage of a nexthop is as shown in the + figure below. For ease of description using ASCII art, only a single + instance of any component of the nexthop is shown in Figure 4. + + route + | + | 0..N + | + nexthop <-------------------------------+ + | | + +-------+----------------------------+-------------+ | + | | | | | | + | | | | | | + base load-balance protection replicate chain | + | | | | | | + | |2..N |2..N |2..N |1..N | + | | | | | | + | | V | | | + | +------------->+<------------+-------------+ | + | | | + | +-------------------------------------+ + | + +-------------------+ + | + | + | + | + +---------------+--------+--------+--------------+----------+ + | | | | | + | | | | | + nexthop-id egress-interface ip-address logical-tunnel | + | + | + +--------------------------------------+ + | + +----------------------+------------------+-------------+ + | | | | + | | | | + tunnel-encapsulation tunnel-decapsulation rib-name special-nexthop + + Figure 4: Nexthop Model + + + + +Bahadur, et al. Informational [Page 11] + +RFC 8430 RIB Information Model September 2018 + + + This document specifies a very generic, extensible, and recursive + grammar for nexthops. A nexthop can be a base nexthop or a derived + nexthop. Section 2.4.1 details base nexthops, and Section 2.4.2 + explains various kinds of derived nexthops. There are certain + special nexthops, and those are described in Section 2.4.1.1. + Lastly, Section 2.4.3 delves into nexthop indirection and its use. + Examples of when and how to use tunnel nexthops and derived nexthops + are shown in Section 7.2. + +2.4.1. Base Nexthops + + At the lowest level, a nexthop can be one of the following: + + o Identifier: This is an identifier returned by the network device + representing a nexthop. This can be used as a way of reusing a + nexthop when programming derived nexthops. + + o Interface nexthops: These are nexthops that are pointing to an + interface. Various attributes associated with these nexthops are: + + * Egress-interface: This represents a physical, logical, or + virtual interface on the network device. Address resolution + must not be required on this interface. This interface may + belong to any routing instance. + + * IP address: A route lookup on this IP address is done to + determine the egress-interface. Address resolution may be + required depending on the interface. + + + An optional rib-name can also be specified to indicate the + RIB in which the IP address is to be looked up. One can use + the rib-name field to direct the packet from one domain into + another domain. By default the RIB will be the same as the + one that route belongs to. + + These attributes can be used in combination as follows: + + * Egress-interface and IP address: This can be used in cases + where, e.g., the IP address is a link-local address. + + * Egress-interface and MAC address: The egress-interface must be + an Ethernet interface. Address resolution is not required for + this nexthop. + + + + + + + + +Bahadur, et al. Informational [Page 12] + +RFC 8430 RIB Information Model September 2018 + + + o Tunnel nexthops: These are nexthops that are pointing to a tunnel. + The types of tunnel nexthops are: + + * tunnel-encapsulation: This can be an encapsulation representing + an IP tunnel, MPLS tunnel, or others as defined in this + document. An optional egress-interface can be chained to the + tunnel-encapsulation to indicate which interface to send the + packet out on. The egress-interface is useful when the network + device contains Ethernet interfaces and one needs to perform + address resolution for the IP packet. + + * tunnel-decapsulation: This is to specify decapsulating a tunnel + header. After decapsulation, further lookup on the packet can + be done via chaining it with another nexthop. The packet can + also be sent out via an egress-interface directly. + + * logical-tunnel: This can be an MPLS Label Switched Path (LSP) + or a GRE tunnel (or others as defined in this document) that is + represented by a unique identifier (e.g., name). + + o rib-name: A nexthop pointing to a RIB. This indicates that the + route lookup needs to continue in the specified RIB. This is a + way to perform chained lookups. + + Tunnel nexthops allow a RIB client to program static tunnel headers. + There can be cases where the remote tunnel endpoint does not support + dynamic signaling (e.g., no LDP support on a host); in those cases, + the RIB client might want to program the tunnel header on both ends + of the tunnel. The tunnel nexthop is kept generic with + specifications provided for some commonly used tunnels. It is + expected that the data model will model these tunnel types with + complete accuracy. + +2.4.1.1. Special Nexthops + + Special nexthops are for performing specific well-defined functions + (e.g., DISCARD). The purpose of each of them is explained below: + + o DISCARD: This indicates that the network device should drop the + packet and increment a drop counter. + + o DISCARD_WITH_ERROR: This indicates that the network device should + drop the packet, increment a drop counter, and send back an + appropriate error message (like ICMP error). + + + + + + + +Bahadur, et al. Informational [Page 13] + +RFC 8430 RIB Information Model September 2018 + + + o RECEIVE: This indicates that the traffic is destined for the + network device, for example, protocol packets or Operations, + Administration, and Maintenance (OAM) packets. All locally + destined traffic SHOULD be throttled to avoid a denial-of-service + attack on the router's control plane. An optional rate limiter + can be specified to indicate how to throttle traffic destined for + the control plane. The description of the rate limiter is outside + the scope of this document. + +2.4.2. Derived Nexthops + + Derived nexthops can be: + + o weighted lists, which are used for load-balancing; + + o preference lists, which are used for protection using primary and + backup; + + o replication lists, which are lists of nexthops to which to + replicate a packet; + + o nexthop chains, which are for chaining multiple operations or + attaching multiple headers; or + + o lists of lists, which are a recursive application of the above. + + Nexthop chains (see Section 7.2.5 for usage) are a way to perform + multiple operations on a packet by logically combining them. For + example, one can chain together "decapsulate MPLS header" and "send + it out a specific egress-interface". Chains can be used to specify + multiple headers over a packet before a packet is forwarded. One + simple example is that of MPLS over GRE, wherein the packet has an + inner MPLS header followed by a GRE header followed by an IP header. + The outermost IP header is decided by the network device, whereas the + MPLS header or GRE header is specified by the controller. Not every + network device will be able to support all kinds of nexthop chains + and an arbitrary number of headers chained together. The RIB data + model SHOULD provide a way to expose a nexthop chaining capability + supported by a given network device. + + It is expected that all network devices will have a limit on how many + levels of lookup can be performed, and not all hardware will be able + to support all kinds of nexthops. RIB capability negotiation becomes + very important for this reason, and a RIB data model MUST specify a + way for a RIB client to learn about the network device's + capabilities. + + + + + +Bahadur, et al. Informational [Page 14] + +RFC 8430 RIB Information Model September 2018 + + +2.4.2.1. Nexthop List Attributes + + For nexthops that are of the form of a list(s), attributes can be + associated with each member of the list to indicate the role of an + individual member of the list. Two attributes are specified: + + o NEXTHOP_PREFERENCE: This is used for protection schemes. It is an + integer value between 1 and 99. A lower value indicates higher + preference. To download a primary/standby pair to the FIB, the + nexthops that are resolved and have the two highest preferences + are selected. Each should have a unique + value within a (see Section 6). + + o NEXTHOP_LB_WEIGHT: This is used for load-balancing. Each list + member MUST be assigned a weight between 1 and 99. The weight + determines the proportion of traffic to be sent over a nexthop + used for forwarding as a ratio of the weight of this nexthop + divided by the weights of all the nexthops of this route that are + used for forwarding. To perform equal load-balancing, one MAY + specify a weight of "0" for all the member nexthops. The value + "0" is reserved for equal load-balancing and, if applied, MUST be + applied to all member nexthops. Note that a weight of 0 is + special because of historical reasons. + +2.4.3. Nexthop Indirection + + Nexthops can be identified by an identifier to create a level of + indirection. The identifier is set by the RIB manager and returned + to the RIB client on request. + + One example of usage of indirection is a nexthop that points to + another network device (e.g., a BGP peer). The returned nexthop + identifier can then be used for programming routes to point to the + this nexthop. Given that the RIB manager has created an indirection + using the nexthop identifier, if the transport path to the network + device (BGP peer) changes, that change in path will be seamless to + the RIB client and all routes that point to that network device will + automatically start going over the new transport path. Nexthop + indirection using identifiers could be applied to not only unicast + nexthops but also nexthops that contain chains and nested nexthops. + See Section 2.4.2 for examples. + + + + + + + + + + +Bahadur, et al. Informational [Page 15] + +RFC 8430 RIB Information Model September 2018 + + +3. Reading from the RIB + + A RIB data model MUST allow a RIB client to read entries for RIBs + created by that entity. The network device administrator MAY allow + reading of other RIBs by a RIB client through access lists on the + network device. The details of access lists are outside the scope of + this document. + + The data model MUST support a full read of the RIB and subsequent + incremental reads of changes to the RIB. When sending data to a RIB + client, the RIB manager SHOULD try to send all dependencies of an + object prior to sending that object. + +4. Writing to the RIB + + A RIB data model MUST allow a RIB client to write entries for RIBs + created by that entity. The network device administrator MAY allow + writes to other RIBs by a RIB client through access lists on the + network device. The details of access lists are outside the scope of + this document. + + When writing an object to a RIB, the RIB client SHOULD try to write + all dependencies of the object prior to sending that object. The + data model SHOULD support requesting identifiers for nexthops and + collecting the identifiers back in the response. + + Route programming in the RIB MUST result in a return code that + contains the following attributes: + + o Installed: Yes/No (indicates whether the route got installed in + the FIB) + + o Active: Yes/No (indicates whether a route is fully resolved and is + a candidate for selection) + + o Reason: E.g., "Not authorized" + + The data model MUST specify which objects can be modified. An object + that can be modified is one whose contents can be changed without + having to change objects that depend on it and without affecting any + data forwarding. To change a non-modifiable object, one will need to + create a new object and delete the old one. For example, routes that + use a nexthop that is identified by a nexthop identifier should be + unaffected when the contents of that nexthop changes. + + + + + + + +Bahadur, et al. Informational [Page 16] + +RFC 8430 RIB Information Model September 2018 + + +5. Notifications + + Asynchronous notifications are sent by the network device's RIB + manager to a RIB client when some event occurs on the network device. + A RIB data model MUST support sending asynchronous notifications. A + brief list of suggested notifications is as below: + + o Route change notification (with a return code as specified in + Section 4) + + o Nexthop resolution status (resolved/unresolved) notification + +6. RIB Grammar + + This section specifies the RIB information model in Routing Backus- + Naur Form (rBNF) [RFC5511]. This grammar is intended to help the + reader better understand Section 2 in order to derive a data model. + + ::= + [] + [] + + + ::= ( ...) + + + ::= ( ...) + ::= + [ ... ] + [ENABLE_IP_RPF_CHECK] + ::= | | + | + + + ::= + [] + [] + + + ::= | | + | | + + ::= | | | | + + + + + + + + +Bahadur, et al. Informational [Page 17] + +RFC 8430 RIB Information Model September 2018 + + + ::= + ( | | + ( )) + ::= + ::= + ::= + + + ::= + ( | | + ( )) + ::= + ::= + ::= + ::= | | + + ::= [] + [] + + ::= | + | + + ::= <> + ::= <> + ::= <> + ::= <> + + + ::= | + ( ) | + ( ) | + ( ) | + + + ::= | + | + | + | | + ( + ( | )) | + ( ) | + | | + | + + + ::= + + + + + +Bahadur, et al. Informational [Page 18] + +RFC 8430 RIB Information Model September 2018 + + + ::= | | + ( []) + + + ::= + ( = + ( )... + + ::= ... + + + ::= ... + + + ::= + ::= | | | | | + + ::= ( ) | + ( ) | + ( ) | + ( ) | + ( ) | + ( ) + + ::= + [] [] + + ::= + [] + [] [] + + ::= ( ...) + ::= ( [] + [] []) | + ( + []) + + ::= [] + ::= ( | ) + [] + ::= ( | ) + + [] + + + + + +Bahadur, et al. Informational [Page 19] + +RFC 8430 RIB Information Model September 2018 + + + ::= (( []) | + ( []) | + ( [])) + + Figure 5: RIB rBNF Grammar + +6.1. Nexthop Grammar Explained + + A nexthop is used to specify the next network element to forward the + traffic to. It is also used to specify how the traffic should be + load-balanced, protected using preference, or multicast using + replication. This is explicitly specified in the grammar. The + nexthop has recursion built in to address complex use cases like the + one defined in Section 7.2.6. + +7. Using the RIB Grammar + + The RIB grammar is very generic and covers a variety of features. + This section provides examples on using objects in the RIB grammar + and examples to program certain use cases. + +7.1. Using Route Preference + + Using route preference, a client can preinstall alternate paths in + the network. For example, if OSPF has a route preference of 10, then + another client can install a route with a route preference of 20 to + the same destination. The OSPF route will get precedence and will + get installed in the FIB. When the OSPF route is withdrawn, the + alternate path will get installed in the FIB. + + Route preference can also be used to prevent denial-of-service + attacks by installing routes with the best preference, which either + drops the offending traffic or routes it to some monitoring/analysis + station. Since the routes are installed with the best preference, + they will supersede any route installed by any other protocol. + +7.2. Using Different Nexthop Types + + The RIB grammar allows one to create a variety of nexthops. This + section describes uses for certain types of nexthops. + + + + + + + + + + + +Bahadur, et al. Informational [Page 20] + +RFC 8430 RIB Information Model September 2018 + + +7.2.1. Tunnel Nexthops + + A tunnel nexthop points to a tunnel of some kind. Traffic that goes + over the tunnel gets encapsulated with the tunnel-encapsulation. + Tunnel nexthops are useful for abstracting out details of the network + by having the traffic seamlessly route between network edges. At the + end of a tunnel, the tunnel will get decapsulated. Thus, the grammar + supports two kinds of operations: one for encapsulation and another + for decapsulation. + +7.2.2. Replication Lists + + One can create a replication list for replicating traffic to multiple + destinations. The destinations, in turn, could be derived nexthops + in themselves (at a level supported by the network device); point to + multipoint and broadcast are examples that involve replication. + + A replication list (at the simplest level) can be represented as: + + ::= [ ... ] + + The above can be derived from the grammar as follows: + + ::= + ::= ... + +7.2.3. Weighted Lists + + A weighted list is used to load-balance traffic among a set of + nexthops. From a modeling perspective, a weighted list is very + similar to a replication list, with the difference that each member + nexthop MUST have a NEXTHOP_LB_WEIGHT associated with it. + + A weighted list (at the simplest level) can be represented as: + + ::= ( ) + [( )... ] + + The above can be derived from the grammar as follows: + + ::= + ::= + + ( ) ... + ::= ( ) + ( ) ... + + + + + +Bahadur, et al. Informational [Page 21] + +RFC 8430 RIB Information Model September 2018 + + +7.2.4. Protection + + A primary/backup protection can be represented as: + + ::= <1> + <2> ) + + The above can be derived from the grammar as follows: + + ::= + ::= ( + ( )...) + ::= ( + ( )) + ::= (( + ( )) + ::= (<1> + (<2> )) + + Traffic can be load-balanced among multiple primary nexthops and a + single backup. In such a case, the nexthop will look like: + + ::= (<1> + ( + ( + ( ) ...)) + <2> ) + + A backup can also have another backup. In such a case, the list will + look like: + + ::= (<1> + <2> (<1> <2> )) + +7.2.5. Nexthop Chains + + A nexthop chain is a way to perform multiple operations on a packet + by logically combining them. For example, when a VPN packet comes on + the WAN interface and has to be forwarded to the correct VPN + interface, one needs to pop the VPN label before sending the packet + out. Using a nexthop chain, one can chain together "pop MPLS header" + and "send it out a specific egress-interface". + + + + + + + + + +Bahadur, et al. Informational [Page 22] + +RFC 8430 RIB Information Model September 2018 + + + The above example can be derived from the grammar as follows: + + ::= + ::= + ::= + ::= ( ) + + Elements in a nexthop chain are evaluated left to right. + + A nexthop chain can also be used to put one or more headers on an + outgoing packet. One example is a pseudowire, which is MPLS over + some transport (MPLS or GRE, for instance). Another example is + Virtual eXtensible Local Area Network (VXLAN) over IP. A nexthop + chain thus allows a RIB client to break up the programming of the + nexthop into independent pieces (one per encapsulation). + + A simple example of MPLS over GRE can be represented as follows: + + ::= ( ) ( ) + + + The above can be derived from the grammar as follows: + + ::= + ::= + ::= + + ::= ( ) ( ) + + +7.2.6. Lists of Lists + + Lists of lists is a derived construct. One example of usage of such + a construct is to replicate traffic to multiple destinations with + load-balancing. In other words, for each branch of the replication + tree, there are multiple interfaces on which traffic needs to be + load-balanced. So, the outer list is a replication list for + multicast and the inner lists are weighted lists for load-balancing. + Let's take an example of a network element that has to replicate + traffic to two other network elements. Traffic to the first network + element should be load-balanced equally over two interfaces: + outgoing-1-1 and outgoing-1-2. Traffic to the second network element + should be load-balanced over three interfaces: outgoing-2-1, + outgoing-2-2, and outgoing-2-3 (in the ratio 20:20:60). + + + + + + + +Bahadur, et al. Informational [Page 23] + +RFC 8430 RIB Information Model September 2018 + + + This can be derived from the grammar as follows: + + ::= + ::= ( ...) + ::= ( ) + ::= (( ) + ( )) + ::= (( + ( + ( ) ...)) + (( + ( + ( ) ...)) + ::= (( + ( + ( ))) + (( + ( + ( ) + ( ))) + ::= (( + ( ) + ( ))) + (( + ( ) + ( ) + ( ))) + ::= + (( + (50 ) + (50 ))) + (( + (20 ) + (20 ) + (60 ))) + +7.3. Performing Multicast + + IP multicast involves matching a packet on (S,G) or (*,G), where both + S (Source) and G (Group) are IP prefixes. Following the match, the + packet is replicated to one or more recipients. How the recipients + subscribe to the multicast group is outside the scope of this + document. + + In PIM-based multicast, the packets are IP forwarded on an IP + multicast tree. The downstream nodes on each point in the multicast + tree are one or more IP addresses. These can be represented as a + replication list (see Section 7.2.2). + + + +Bahadur, et al. Informational [Page 24] + +RFC 8430 RIB Information Model September 2018 + + + In MPLS-based multicast, the packets are forwarded on a Point-to- + Multipoint (P2MP) LSP. The nexthop for a P2MP LSP can be represented + in the nexthop grammar as a (P2MP LSP identifier) or + a replication list (see Section 7.2.2) of , + with each tunnel-encapsulation representing a single MPLS downstream + nexthop. + +8. RIB Operations at Scale + + This section discusses the scale requirements for a RIB data model. + The RIB data model should be able to handle a large scale of + operations to enable deployment of RIB applications in large + networks. + +8.1. RIB Reads + + Bulking (grouping of multiple objects in a single message) MUST be + supported when a network device sends RIB data to a RIB client. + Similarly, the data model MUST enable a RIB client to request data in + bulk from a network device. + +8.2. RIB Writes + + Bulking (grouping of multiple write operations in a single message) + MUST be supported when a RIB client wants to write to the RIB. The + response from the network device MUST include a return-code for each + write operation in the bulk message. + +8.3. RIB Events and Notifications + + There can be cases where a single network event results in multiple + events and/or notifications from the network device to a RIB client. + On the other hand, due to timing of multiple things happening at the + same time, a network device might have to send multiple events and/or + notifications to a RIB client. The network-device-originated event/ + notification message MUST support the bulking of multiple events and + notifications in a single message. + +9. Security Considerations + + The information model specified in this document defines a schema for + data models that are designed to be accessed via network management + protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The + lowest NETCONF layer is the secure transport layer, and the + mandatory-to-implement secure transport is Secure Shell (SSH) + [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- + implement secure transport is TLS [RFC8446]. + + + + +Bahadur, et al. Informational [Page 25] + +RFC 8430 RIB Information Model September 2018 + + + The NETCONF access control model [RFC8341] provides the means to + restrict access for particular NETCONF or RESTCONF users to a + preconfigured subset of all available NETCONF or RESTCONF protocol + operations and content. + + The RIB information model specifies read and write operations to + network devices. These network devices might be considered sensitive + or vulnerable in some network environments. Write operations to + these network devices without proper protection can have a negative + effect on network operations. Due to this factor, it is recommended + that data models also consider the following in their design: + + o Require utilization of the authentication and authorization + features of the NETCONF or RESTCONF suite of protocols. + + o Augment the limits on how much data can be written or updated by a + remote entity built to include enough protection for a RIB data + model. + + o Expose the specific RIB data model implemented via NETCONF/ + RESTCONF data models. + +10. IANA Considerations + + This document has no IANA actions. + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + . + + [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure + Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, + . + + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . + + + + +Bahadur, et al. Informational [Page 26] + +RFC 8430 RIB Information Model September 2018 + + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration + Access Control Model", STD 91, RFC 8341, + DOI 10.17487/RFC8341, March 2018, + . + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + +11.2. Informative References + + [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. + Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", + RFC 4915, DOI 10.17487/RFC4915, June 2007, + . + + [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi + Topology (MT) Routing in Intermediate System to + Intermediate Systems (IS-ISs)", RFC 5120, + DOI 10.17487/RFC5120, February 2008, + . + + [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax + Used to Form Encoding Rules in Various Routing Protocol + Specifications", RFC 5511, DOI 10.17487/RFC5511, April + 2009, . + + [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem + Statement for the Interface to the Routing System", + RFC 7920, DOI 10.17487/RFC7920, June 2016, + . + + [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, + S., and N. Bahadur, "A YANG Data Model for the Routing + Information Base (RIB)", RFC 8431, DOI 10.17487/RFC8431, + September 2018, . + + + + + + + + + + + +Bahadur, et al. Informational [Page 27] + +RFC 8430 RIB Information Model September 2018 + + +Acknowledgements + + The authors would like to thank Ron Folkes, Jeffrey Zhang, the WG + co-Chairs, and reviewers for their comments and suggestions on this + document. The following people contributed to the design of the RIB + information model as part of the I2RS Interim meeting in April 2013: + + Wes George, Chris Liljenstolpe, Jeff Tantsura, Susan Hares, and + Fabian Schneider. + +Authors' Addresses + + Nitin Bahadur (editor) + Uber + 900 Arastradero Rd + Palo Alto, CA 94304 + United States of America + + Email: nitin_bahadur@yahoo.com + + + Sriganesh Kini (editor) + + Email: sriganeshkini@gmail.com + + + Jan Medved + Cisco + + Email: jmedved@cisco.com + + + + + + + + + + + + + + + + + + + + + +Bahadur, et al. Informational [Page 28] + -- cgit v1.2.3