A YANG Data Model for the Routing
Information Base (RIB)Individualwang_little_star@sina.comHuaweimach.chen@huawei.comEricssondass.amit@gmail.comNetflixhari@netflix.comIndividualsriganeshkini@gmail.comUbernitin_bahadur@yahoo.comThis document defines a YANG data model for the Routing Information
Base (RIB) that aligns with the Interface to the Routing System (I2RS)
RIB information model.The Interface to the Routing System (I2RS)
provides read and write access to the information and state within the
routing process that exists inside the routing elements; this is
achieved via protocol message exchange between I2RS clients and I2RS
agents associated with the routing system. One of the functions of I2RS
is to read and write data of the Routing Information Base (RIB). introduces a set of RIB use cases. The RIB
information model is defined in .This document defines a YANG data model for the RIB that satisfies the RIB use cases
and aligns with the RIB information model.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 when,
and only when, they appear in all capitals, as shown here.RIB: Routing Information BaseFIB: Forwarding Information BaseRPC: Remote Procedure CallIM: Information Model. An abstract model of a conceptual domain,
which is independent of a specific implementation or data
representation.Tree diagrams used in this document follow the notation defined in
.The following figure shows an overview of the structure tree of the
ietf-i2rs-rib module. To give a whole view of the structure tree, some
details of the tree are omitted. The relevant details are introduced in
the subsequent subsections.RIB capability negotiation is very important because not all of the
hardware will be able to support all kinds of nexthops, and there
might be a limitation on how many levels of lookup can be practically
performed. Therefore, a RIB data model needs to specify a way for an
external entity to learn about the functional capabilities of a
network device.At the same time, nexthop chains can be used to specify multiple
headers over a packet before that particular packet is forwarded. Not
every network device will be able to support all kinds of nexthop
chains along with the arbitrary number of headers that are chained
together. The RIB data model needs a way to expose the nexthop
chaining capability supported by a given network device.This module uses the feature and if-feature statements to achieve
above capability advertisement.A routing instance, in the context of the RIB information model, is
a collection of RIBs, interfaces, and routing protocol parameters. A
routing instance creates a logical slice of the router and can allow
multiple different logical slices, across a set of routers, to
communicate with each other. The routing protocol parameters control
the information available in the RIBs. More details about a routing
instance can be found in Section 2.2 of .For a routing instance, there can be multiple RIBs. Therefore, this
model uses "list" to express the RIBs. The structure tree is shown
below:A route is essentially a match condition and an action following
that match. The match condition specifies the kind of route (e.g.,
IPv4, MPLS, Media Access Control (MAC), Interface, etc.) and the set
of fields to match on.A route MUST contain the ROUTE_PREFERENCE attribute (see Section
2.3 of ).In addition, a route MUST associate with the following status
attributes in responses to a RIB writing/reading operation:Active: Indicates whether a route has at least one fully
resolved nexthop and is therefore eligible for installation in the
FIB.Installed: Indicates whether the route got installed in the
FIB.Reason: Indicates the specific reason that caused the failure,
e.g., "Not authorized".In addition, a route can be associated with one or more optional
route-attributes (e.g., route-vendor-attributes).A RIB will have a number of routes, so the routes are expressed as
a list under a specific RIB. Each RIB has its own route list.A nexthop represents an object resulting from a route lookup. As
illustrated in Figure 4 of , to support
various use cases (e.g., load-balancing, protection, multicast, or a
combination of them), the nexthop is modeled as a multilevel structure
and supports recursion. The first level of the nexthop includes the
following four types:Base: The "base" nexthop is the foundation of all other nexthop
types. It includes the following basic nexthops:nexthop-idIPv4 addressIPv6 addressegress-interfaceegress-interface with IPv4 addressegress-interface with IPv6 addressegress-interface with MAC addresslogical-tunneltunnel-encapsulationtunnel-decapsulationrib-nameChain: The "chain" nexthop provides a way to perform multiple
operations on a packet by logically combining them.Load-Balance: The "load-balance" nexthop is designed for a
load-balance case where it normally will have multiple weighted
nexthops.Protection: The "protection" nexthop is designed for a
protection scenario where it normally will have primary and
standby nexthop.Replicate: The "replicate" nexthop is designed for multiple
destinations forwarding.The structure tree of nexthop is shown in the following
figures. (as shown below) is a subtree of nexthop.
It's under the nexthop base node and shows the structure of the "base"
nexthop.This module defines the following RPC operations:rib-add: Add a RIB to a routing instance.
The following are passed as the input parameters: the name of the RIB, the
address
family of the RIB, and (optionally) whether the RPF check is enabled.
The output is the result of the add operation:
true - successfalse - failed (when failed, the I2RS agent may return the
specific reason that caused the failure)rib-delete: Delete a RIB from a routing instance. When a RIB is
deleted, all routes installed in the RIB will be deleted. A
rib-name is passed as the input parameter. The output is the
result of the delete operation:true - successfalse - failed (when failed, the I2RS agent may return the
specific reason that caused the failure)route-add: Add a route or a set of routes to a RIB.
The following are passed as the input parameters: the name of the RIB, the route
prefix(es), the route-attributes, the route-vendor-attributes, the nexthop,
and the "whether to return failure details" indication.
Before calling
the route-add rpc, it is required to call the nh-add rpc to create
and/or return the nexthop identifier. However, in situations when
the nexthop already exists and the nexthop-id is known, this
action is not expected. The output is a combination of the route
operation states while querying the appropriate node in the data
tree, which includes:success-count: the number of routes that were successfully
added;failed-count: the number of the routes that failed to be
added; and,failure-detail: this shows the specific routes that failed
to be added.route-delete: Delete a route or a set of routes from a RIB.
The following are passed as the input parameters: the name of the RIB, the
route prefix(es), and the "whether to return failure details" indication.
The output is a
combination of route operation states, which includes:success-count: the number of routes that were successfully
deleted;failed-count: the number of the routes that failed to be
deleted; and,failure-detail: this shows the specific routes that failed
to be deleted.route-update: Update a route or a set of routes.
The following are passed as the input parameters: the name of the RIB, the
route
prefix(es), the route-attributes, the route-vendor-attributes, or the nexthop.
The match conditions
can be either route prefix(es), route-attributes, route-vendor-attributes, or
nexthops.
The update
actions include the following: update the nexthops, update the
route-attributes, and update the route-vendor-attributes. The
output is a combination of the route operation states, which
includes:success-count: the number of routes that were successfully
updated;failed-count: the number of the routes that failed to be
updated; and,failure-detail: this shows the specific routes that failed
to be updated.nh-add: Add a nexthop to a RIB.
The following are passed as the input parameters: the name of the RIB and
the nexthop.
The network node is required to
allocate a nexthop identifier to the nexthop. The outputs include
the result of the nexthop add operation.true - success (when success, a nexthop identifier will be
returned to the I2RS client)false - failed (when failed, the I2RS agent may return the
specific reason that caused the failure)nh-delete: Delete a nexthop from a RIB.
The following are passed as the input parameters: the name of the RIB and a
nexthop or nexthop identifier.
The output is the result of the delete operation:true - successfalse - failed (when failed, the I2RS agent may return the
specific reason that caused the failure)The structure tree of rpcs is shown in following figure.Asynchronous notifications are sent by the RIB manager of a network
device to an external entity when some event triggers on the network
device. An implementation of this RIB data model MUST support sending
two kinds of asynchronous notifications.1. Route change notification:o Installed (indicates whether the route got installed in the
FIB)o Active (indicates whether a route has at least one fully resolved
nexthop and is therefore eligible for installation in the FIB)o Reason (e.g., "Not authorized")2. Nexthop resolution status notificationNexthops can be fully resolved or unresolved.A resolved nexthop has an adequate level of information to send the
outgoing packet towards the destination by forwarding it on an
interface to a directly connected neighbor.An unresolved nexthop is something that requires the RIB manager to
determine the final resolved nexthop. In one example, a nexthop could
be an IP address. The RIB manager would resolve how to reach that IP
address, e.g., by checking if that particular IP address is 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 suitable candidate for installation in
the FIB.An implementation of this RIB data model MUST support sending
route-change notifications whenever a route transitions between the
following states:from the active state to the inactive statefrom the inactive state to the active statefrom the installed state to the uninstalled statefrom the uninstalled state to the installed stateA single notification MAY be used when a route transitions
from inactive/uninstalled to active/installed or in the other
direction.The structure tree of notifications is shown in the following
figure.This YANG module references , , , and .This document registers a URI in the "ns" registry within the "IETF
XML Registry" :This document registers a YANG module in the "YANG Module
Names" registry :The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such as
NETCONF or RESTCONF .
The lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS .The NETCONF access control model 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 YANG module defines information that can be configurable in
certain instances, for example, a RIB, a route, a nexthop can be created
or deleted by client applications; the YANG module also defines RPCs
that can be used by client applications to add/delete RIBs, routes, and
nexthops. In such cases, a malicious client could attempt to remove,
add, or update a RIB, a route, or a nexthop by creating or deleting
corresponding elements in the RIB, route, and nexthop lists,
respectively. Removing a RIB or a route could lead to disruption or
impact in performance of a service; updating a route may lead to
suboptimal path and degradation of service levels as well as possibly
disruption of service. For those reasons, it is important that the
NETCONF access control model is vigorously applied to prevent
misconfiguration by unauthorized clients.There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the default).
These data nodes may be considered sensitive or vulnerable in some
network environments. Write operations (e.g., edit-config) to these data
nodes without proper protection can have a negative effect on network
operations. These are the subtrees and data nodes and their
sensitivity/vulnerability:RIB: A malicious client could attempt to remove a RIB from a
routing instance, for example, in order to sabotage the services
provided by the RIB or to add a RIB to a routing instance (hence, to
inject unauthorized traffic into the nexthop).route: A malicious client could attempt to remove or add a route
from/to a RIB, for example, in order to sabotage the services
provided by the RIB.nexthop: A malicious client could attempt to remove or add a
nexthop from/to RIB, which may lead to a suboptimal path, a
degradation of service levels, and a possible disruption of
service.RIB Information ModelSummary of I2RS Use Case RequirementsThe I2RS Working Group (WG) has described a set of use cases
that the I2RS systems could fulfil. This document summarizes these
use cases. It is designed to provide requirements that will aid
the design of the I2RS architecture, Information Models, Data
Models, Security, and protocols.The authors would like to thank Chris Bowers, John Scudder, Tom
Petch, Mike McBride, and Ebben Aries for their review, suggestions, and
comments to this document.The following individuals also contributed to this document.Zekun He, Tencent Holdings Ltd.Sujian Lu, Tencent Holdings Ltd.Jeffery Zhang, Juniper Networks