A YANG Data Model for Routing Information Base
(RIB)Individualwang_little_star@sina.comHuaweimach.chen@huawei.comEricssonamit.dass@ericsson.comPacket Designhari@packetdesign.comIndividualsriganeshkini@gmail.comBracket Computingnitin_bahadur@yahoo.comThis document defines a YANG data model for Routing Information Base
(RIB) that aligns with the I2RS RIB information model.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.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 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.RIB: Routing Information BaseInformation Model (IM): An abstract model of a conceptual domain,
independent of a specific implementation or data representation.
YANG tree diagrams provide a concise representation of a YANG
module, and SHOULD be included to help readers understand
YANG module structure. Guidelines on tree diagrams can be
found in Section 3 of .
The following figure shows an overview of 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 sub-sections.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 MUST 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 which are chained
together. The RIB data model MUST provide 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 detail about 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, MAC, Interface etc.) and the set of fields to match
on.According to the definition in , a route MUST associate with
the following attributes:ROUTE_PREFERENCE: See Section 2.3 of .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.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 Section 2.4 of , to support various use cases
(e.g., load balance, protection, multicast or a combination of them),
the nexthop is modeled as a multi-level 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 follow basic nexthops:nexthop-idIPv4 addressIPv6 addressegress-interfaceegress-interface with IPv4 addressegress-interface with IPv6 addressegress-interface with MAC addresslogical-tunneltunnel-encapsulationtunnel-decapsulationrib-nameChain: Provide a way to perform multiple operations on a packet
by logically combining them.Load-balance: Designed for load-balance case where it normally
will have multiple weighted nexthops.Protection: Designed for protection scenario where it normally
will have primary and standby nexthop.Replicate: Designed for multiple destinations forwarding.The structure tree of nexthop is shown in the following
figures.Figure 5 (as shown blow) is a sub-tree of nexthop, it's under the
nexthop base node and shows that structure of the "base" nexthop.This module defines the following RPC operations:rib-add: Add a RIB to a routing instance. A name of the RIB,
address family of the RIB and (optionally) whether the RPF check
is enabled are passed as the input parameters. The output is the
result of the add operation: true - success;false - failed; when failed, the i2rs agent may return the
specific reason that causes 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 name
of the RIB is passed as the input parameter. The output is the
result of the delete operation:true - success;false - failed; when failed, the i2rs agent may return the
specific reason that causes the failure.route-add: Add a route or a set of routes to a RIB. A RIB name,
the route prefix(es), route attributes, route vendor attributes,
nexthop and whether return failure detail are passed as the input
parameters. Before calling the route-add rpc, it is required to
call the nh-add rpc to create and/or return the nexthop
identifier but during 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 that include:success-count: the number of routes that were successfully
added;failed-count: the number of the routes that failed to be
added;failure-detail: shows the specific routes that failed to be
added.route-delete: Delete a route or a set of routes from a RIB. A
name of the RIB, the route prefix(es) and whether to return
failure detail are passed as the input parameters. The output is a
combination of route operation states that include:success-count: the number of routes that were successfully
deleted;failed-count: the number of the routes that failed to be
deleted;failure-detail: shows the specific routes that failed to be
deleted.route-update: Update a route or a set of routes. A RIB name,
the route prefix(es), or route attributes, or route vendor
attributes, or nexthop are passed as the input parameters. The
match conditions can be either route prefix(es), or route
attributes, or route vendor attributes, or nexthop. The update
actions include: update the nexthop, update the route attributes,
update the route vendor attributes. The output is combination of
the route operation states that include:success-count: the number of routes that were successfully
updated;failed-count: the number of the routes that failed to be
updated;failure-detail: shows the specific routes that failed to be
updated.nh-add: Add a nexthop to a RIB. A name of the RIB and a nexthop
are passed as the input parameters. 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 causes the failure.nh-delete: Delete a nexthop from a RIB. A name of a RIB and a
nexthop or nexthop identifier are passed as the input parameters.
The output is the result of the delete operation:true - success;false - failed; when failed, the i2rs agent may return the
specific reason that causes 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 authorized2. Nexthop resolution status notificationNexthops can be fully resolved or an 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 or by a 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 document registers a URI in the "ns" registry with
the "IETF XML registry" :This document requests to register 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 modules define 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 modules also define 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, 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 in the ietf-i2rs-rib module:
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 suboptimal path and
degradation of service levels as well as possibly disruption of
service.The following individuals also contribute to this document.Zekun He, Tencent Holdings LtdSujian Lu, Tencent Holdings LtdJeffery Zhang, Juniper NetworksThe authors would like to thank Chris Bowers and John Scudder for his
review, suggestion and comments to this document.YANG Tree Diagrams
This document captures the current syntax used in YANG module Tree Diagrams. The purpose of the document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.