RFC 8431
A YANG Data Model for the Routing Information Base (RIB)
Internet Engineering Task Force (IETF) L. Wang Request for Comments: 8431 Individual Category: Standards Track M. Chen ISSN: 2070-1721 Huawei A. Dass Ericsson H. Ananthakrishnan Netflix S. Kini Individual N. Bahadur Uber September 2018 A YANG Data Model for the Routing Information Base (RIB)Abstract
This 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. Status of This Memo This is an Internet Standards Track document. 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). Further information on Internet Standards is available in 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/rfc8431.
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.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Definitions and Abbreviations . . . . . . . . . . . . . . 3 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 2. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . 8 2.2. Routing Instance and RIB . . . . . . . . . . . . . . . . 8 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 15 2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 20 3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 22 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 68 6.2. Informative References . . . . . . . . . . . . . . . . . 69 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 70 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71
1. Introduction
The Interface to the Routing System (I2RS) [RFC7921] 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). [I2RS-REQS] introduces a set of RIB use cases. The RIB information model is defined in [RFC8430]. This document defines a YANG data model [RFC7950] [RFC6991] for the RIB that satisfies the RIB use cases and aligns with the RIB information model.1.1. Requirements Language
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.1.2. Definitions and Abbreviations
RIB: Routing Information Base FIB: Forwarding Information Base RPC: Remote Procedure Call IM: Information Model. An abstract model of a conceptual domain, which is independent of a specific implementation or data representation.1.3. Tree Diagrams
Tree diagrams used in this document follow the notation defined in [RFC8340].2. Model Structure
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.
module: ietf-i2rs-rib
+--rw routing-instance
+--rw name string
+--rw interface-list* [name]
| +--rw name if:interface-ref
+--rw router-id? yang:dotted-quad
+--rw lookup-limit? uint8
+--rw rib-list* [name]
+--rw name string
+--rw address-family address-family-definition
+--rw ip-rpf-check? boolean
+--rw route-list* [route-index]
| +--rw route-index uint64
| +--rw match
| | +--rw (route-type)?
| | +--:(ipv4)
| | | ...
| | +--:(ipv6)
| | | ...
| | +--:(mpls-route)
| | | ...
| | +--:(mac-route)
| | | ...
| | +--:(interface-route)
| | ...
| +--rw nexthop
| | +--rw nexthop-id? uint32
| | +--rw sharing-flag? boolean
| | +--rw (nexthop-type)?
| | +--:(nexthop-base)
| | | ...
| | +--:(nexthop-chain) {nexthop-chain}?
| | | ...
| | +--:(nexthop-replicate) {nexthop-replicate}?
| | | ...
| | +--:(nexthop-protection) {nexthop-protection}?
| | | ...
| | +--:(nexthop-load-balance) {nexthop-load-balance}?
| | ...
| +--rw route-status
| | ...
| +--rw route-attributes
| | ...
| +--rw route-vendor-attributes
+--rw nexthop-list* [nexthop-member-id]
+--rw nexthop-member-id uint32
rpcs:
+---x rib-add
| +---w input
| | +---w name string
| | +---w address-family address-family-definition
| | +---w ip-rpf-check? boolean
| +--ro output
| +--ro result boolean
| +--ro reason? string
+---x rib-delete
| +---w input
| | +---w name string
| +--ro output
| +--ro result boolean
| +--ro reason? string
+---x route-add
| +---w input
| | +---w return-failure-detail? boolean
| | +---w rib-name string
| | +---w routes
| | +---w route-list* [route-index]
| | ...
| +--ro output
| +--ro success-count uint32
| +--ro failed-count uint32
| +--ro failure-detail
| +--ro failed-routes* [route-index]
| +--ro route-index uint32
| +--ro error-code? uint32
+---x route-delete
| +---w input
| | +---w return-failure-detail? boolean
| | +---w rib-name string
| | +---w routes
| | +---w route-list* [route-index]
| | ...
| +--ro output
| +--ro success-count uint32
| +--ro failed-count uint32
| +--ro failure-detail
| +--ro failed-routes* [route-index]
| +--ro route-index uint32
| +--ro error-code? uint32
+---x route-update
| +---w input
| | +---w return-failure-detail? boolean
| | +---w rib-name string
| | +---w (match-options)?
| | +--:(match-route-prefix)
| | | ...
| | +--:(match-route-attributes)
| | | ...
| | +--:(match-route-vendor-attributes) {...}?
| | | ...
| | +--:(match-nexthop)
| | ...
| +--ro output
| +--ro success-count uint32
| +--ro failed-count uint32
| +--ro failure-detail
| +--ro failed-routes* [route-index]
| +--ro route-index uint32
| +--ro error-code? uint32
+---x nh-add
| +---w input
| | +---w rib-name string
| | +---w nexthop-id? uint32
| | +---w sharing-flag? boolean
| | +---w (nexthop-type)?
| | +--:(nexthop-base)
| | | ...
| | +--:(nexthop-chain) {nexthop-chain}?
| | | ...
| | +--:(nexthop-replicate) {nexthop-replicate}?
| | | ...
| | +--:(nexthop-protection) {nexthop-protection}?
| | | ...
| | +--:(nexthop-load-balance) {nexthop-load-balance}?
| | ...
| +--ro output
| +--ro result boolean
| +--ro reason? string
| +--ro nexthop-id? uint32
+---x nh-delete
+---w input
| +---w rib-name string
| +---w nexthop-id? uint32
| +---w sharing-flag? boolean
| +---w (nexthop-type)?
| +--:(nexthop-base)
| | ...
| +--:(nexthop-chain) {nexthop-chain}?
| | ...
| +--:(nexthop-replicate) {nexthop-replicate}?
| | ...
| +--:(nexthop-protection) {nexthop-protection}? | | ... | +--:(nexthop-load-balance) {nexthop-load-balance}? | ... +--ro output +--ro result boolean +--ro reason? string notifications: +---n nexthop-resolution-status-change | +--ro nexthop | | +--ro nexthop-id? uint32 | | +--ro sharing-flag? boolean | | +--ro (nexthop-type)? | | +--:(nexthop-base) | | | ... | | +--:(nexthop-chain) {nexthop-chain}? | | | ... | | +--:(nexthop-replicate) {nexthop-replicate}? | | | ... | | +--:(nexthop-protection) {nexthop-protection}? | | | ... | | +--:(nexthop-load-balance) {nexthop-load-balance}? | | ... | +--ro nexthop-state nexthop-state-definition +---n route-change +--ro rib-name string +--ro address-family address-family-definition +--ro route-index uint64 +--ro match | +--ro (route-type)? | +--:(ipv4) | | ... | +--:(ipv6) | | ... | +--:(mpls-route) | | ... | +--:(mac-route) | | ... | +--:(interface-route) | ... +--ro route-installed-state route-installed-state-definition +--ro route-state route-state-definition +--ro route-change-reasons* [route-change-reason] +--ro route-change-reason route-change-reason-definition Figure 1: Overview of I2RS RIB Module Structure
2.1. RIB Capability
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.2.2. Routing Instance and RIB
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 [RFC8430]. For a routing instance, there can be multiple RIBs. Therefore, this model uses "list" to express the RIBs. The structure tree is shown below: +--rw routing-instance +--rw name string +--rw interface-list* [name] | +--rw name if:interface-ref +--rw router-id? yang:dotted-quad +--rw lookup-limit? uint8 +--rw rib-list* [name] +--rw name string +--rw address-family address-family-definition +--rw ip-rpf-check? boolean +--rw route-list* [route-index] ... // refer to Section 2.3 Figure 2: Routing Instance Structure
2.3. Route
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 [RFC8430]). In addition, a route MUST associate with the following status attributes in responses to a RIB writing/reading operation: o Active: Indicates whether a route has at least one fully resolved nexthop and is therefore eligible for installation in the FIB. o Installed: Indicates whether the route got installed in the FIB. o 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.
+--rw route-list* [route-index] +--rw route-index uint64 +--rw match | +--rw (route-type)? | +--:(ipv4) | | +--rw ipv4 | | +--rw (ip-route-match-type)? | | +--:(dest-ipv4-address) | | | ... | | +--:(src-ipv4-address) | | | ... | | +--:(dest-src-ipv4-address) | | ... | +--:(ipv6) | | +--rw ipv6 | | +--rw (ip-route-match-type)? | | +--:(dest-ipv6-address) | | | ... | | +--:(src-ipv6-address) | | | ... | | +--:(dest-src-ipv6-address) | | ... | +--:(mpls-route) | | +--rw mpls-label uint32 | +--:(mac-route) | | +--rw mac-address uint32 | +--:(interface-route) | +--rw interface-identifier if:interface-ref +--rw nexthop | ...(refer to Section 2.4) Figure 3: Routes Structure
2.4. Nexthop
A nexthop represents an object resulting from a route lookup. As illustrated in Figure 4 of [RFC8430], 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: o Base: The "base" nexthop is the foundation of all other nexthop types. It includes the following basic nexthops: * nexthop-id * IPv4 address * IPv6 address * egress-interface * egress-interface with IPv4 address * egress-interface with IPv6 address * egress-interface with MAC address * logical-tunnel * tunnel-encapsulation * tunnel-decapsulation * rib-name o Chain: The "chain" nexthop provides a way to perform multiple operations on a packet by logically combining them. o Load-Balance: The "load-balance" nexthop is designed for a load- balance case where it normally will have multiple weighted nexthops. o Protection: The "protection" nexthop is designed for a protection scenario where it normally will have primary and standby nexthop. o Replicate: The "replicate" nexthop is designed for multiple destinations forwarding.
The structure tree of nexthop is shown in the following figures. +--rw nexthop | +--rw nexthop-id? uint32 | +--rw sharing-flag? boolean | +--rw (nexthop-type)? | +--:(nexthop-base) | | ...(refer to Figure 5) | +--:(nexthop-chain) {nexthop-chain}? | | +--rw nexthop-chain | | +--rw nexthop-list* [nexthop-member-id] | | +--rw nexthop-member-id uint32 | +--:(nexthop-replicate) {nexthop-replicate}? | | +--rw nexthop-replicate | | +--rw nexthop-list* [nexthop-member-id] | | +--rw nexthop-member-id uint32 | +--:(nexthop-protection) {nexthop-protection}? | | +--rw nexthop-protection | | +--rw nexthop-list* [nexthop-member-id] | | +--rw nexthop-member-id uint32 | | +--rw nexthop-preference nexthop-preference-definition | +--:(nexthop-load-balance) {nexthop-load-balance}? | +--rw nexthop-lb | +--rw nexthop-list* [nexthop-member-id] | +--rw nexthop-member-id uint32 | +--rw nexthop-lb-weight nexthop-lb-weight-definition Figure 4: Nexthop Structure Figure 5 (as shown below) is a subtree of nexthop. It's under the nexthop base node and shows the structure of the "base" nexthop. +--:(nexthop-base) | +--rw nexthop-base | +--rw (nexthop-base-type)? | +--:(special-nexthop) | | +--rw special? special-nexthop-definition | +--:(egress-interface-nexthop) | | +--rw outgoing-interface if:interface-ref | +--:(ipv4-address-nexthop) | | +--rw ipv4-address inet:ipv4-address | +--:(ipv6-address-nexthop) | | +--rw ipv6-address inet:ipv6-address | +--:(egress-interface-ipv4-nexthop) | | +--rw egress-interface-ipv4-address | | +--rw outgoing-interface if:interface-ref | | +--rw ipv4-address inet:ipv4-address
| +--:(egress-interface-ipv6-nexthop)
| | +--rw egress-interface-ipv6-address
| | +--rw outgoing-interface if:interface-ref
| | +--rw ipv6-address inet:ipv6-address
| +--:(egress-interface-mac-nexthop)
| | +--rw egress-interface-mac-address
| | +--rw outgoing-interface if:interface-ref
| | +--rw ieee-mac-address yang:mac-address
| +--:(tunnel-encapsulation-nexthop) {nexthop-tunnel}?
| | +--rw tunnel-encapsulation
| | +--rw (tunnel-type)?
| | +--:(ipv4) {ipv4-tunnel}?
| | | +--rw ipv4-header
| | | +--rw src-ipv4-address inet:ipv4-address
| | | +--rw dest-ipv4-address inet:ipv4-address
| | | +--rw protocol uint8
| | | +--rw ttl? uint8
| | | +--rw dscp? uint8
| | +--:(ipv6) {ipv6-tunnel}?
| | | +--rw ipv6-header
| | | +--rw src-ipv6-address inet:ipv6-address
| | | +--rw dest-ipv6-address inet:ipv6-address
| | | +--rw next-header uint8
| | | +--rw traffic-class? uint8
| | | +--rw flow-label?
| | | inet:ipv6-flow-label
| | | +--rw hop-limit? uint8
| | +--:(mpls) {mpls-tunnel}?
| | | +--rw mpls-header
| | | +--rw label-operations* [label-oper-id]
| | | +--rw label-oper-id uint32
| | | +--rw (label-actions)?
| | | +--:(label-push)
| | | | +--rw label-push
| | | | +--rw label uint32
| | | | +--rw s-bit? boolean
| | | | +--rw tc-value? uint8
| | | | +--rw ttl-value? uint8
| | | +--:(label-swap)
| | | +--rw label-swap
| | | +--rw out-label uint32
| | | +--rw ttl-action?
| | | ttl-action-definition
| | +--:(gre) {gre-tunnel}?
| | | +--rw gre-header
| | | +--rw (dest-address-type)?
| | | | +--:(ipv4)
| | | | | +--rw ipv4-dest inet:ipv4-address
| | | | +--:(ipv6)
| | | | +--rw ipv6-dest inet:ipv6-address
| | | +--rw protocol-type uint16
| | | +--rw key? uint64
| | +--:(nvgre) {nvgre-tunnel}?
| | | +--rw nvgre-header
| | | +--rw (nvgre-type)?
| | | | +--:(ipv4)
| | | | | +--rw src-ipv4-address inet:ipv4-address
| | | | | +--rw dest-ipv4-address inet:ipv4-address
| | | | | +--rw protocol uint8
| | | | | +--rw ttl? uint8
| | | | | +--rw dscp? uint8
| | | | +--:(ipv6)
| | | | +--rw src-ipv6-address inet:ipv6-address
| | | | +--rw dest-ipv6-address inet:ipv6-address
| | | | +--rw next-header uint8
| | | | +--rw traffic-class? uint8
| | | | +--rw flow-label?
| | | | inet:ipv6-flow-label
| | | | +--rw hop-limit? uint8
| | | +--rw virtual-subnet-id uint32
| | | +--rw flow-id? uint8
| | +--:(vxlan) {vxlan-tunnel}?
| | +--rw vxlan-header
| | +--rw (vxlan-type)?
| | | +--:(ipv4)
| | | | +--rw src-ipv4-address inet:ipv4-address
| | | | +--rw dest-ipv4-address inet:ipv4-address
| | | | +--rw protocol uint8
| | | | +--rw ttl? uint8
| | | | +--rw dscp? uint8
| | | +--:(ipv6)
| | | +--rw src-ipv6-address inet:ipv6-address
| | | +--rw dest-ipv6-address inet:ipv6-address
| | | +--rw next-header uint8
| | | +--rw traffic-class? uint8
| | | +--rw flow-label? inet:ipv6-flow-label
| | | +--rw hop-limit? uint8
| | +--rw vxlan-identifier uint32
| +--:(tunnel-decapsulation-nexthop) {nexthop-tunnel}?
| | +--rw tunnel-decapsulation
| | +--rw (tunnel-type)?
| | +--:(ipv4) {ipv4-tunnel}? | | | +--rw ipv4-decapsulation | | | +--rw ipv4-decapsulation | | | tunnel-decapsulation-action-definition | | | +--rw ttl-action? ttl-action-definition | | +--:(ipv6) {ipv6-tunnel}? | | | +--rw ipv6-decapsulation | | | +--rw ipv6-decapsulation | | | tunnel-decapsulation-action-definition | | | +--rw hop-limit-action? | | | hop-limit-action-definition | | +--:(mpls) {mpls-tunnel}? | | +--rw label-pop | | +--rw label-pop mpls-label-action-definition | | +--rw ttl-action? ttl-action-definition | +--:(logical-tunnel-nexthop) {nexthop-tunnel}? | | +--rw logical-tunnel | | +--rw tunnel-type tunnel-type-definition | | +--rw tunnel-name string | +--:(rib-name-nexthop) | | +--rw rib-name? string | +--:(nexthop-identifier) | +--rw nexthop-ref nexthop-ref Figure 5: Nexthop Base Structure2.5. RPC Operations
This module defines the following RPC operations: o 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 - success * false - failed (when failed, the I2RS agent may return the specific reason that caused the failure)
o 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 - success
* false - failed (when failed, the I2RS agent may return the
specific reason that caused the failure)
o 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.
o 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.
o 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.
o 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)
o 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 - success
* false - 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. rpcs: +---x rib-add | +---w input | | +---w rib-name string | | +---w address-family address-family-definition | | +---w ip-rpf-check? boolean | +--ro output | +--ro result uint32 | +--ro reason? string +---x rib-delete | +---w input | | +---w rib-name string | +--ro output | +--ro result uint32 | +--ro reason? string +---x route-add | +---w input | | +---w return-failure-detail? boolean | | +---w rib-name string | | +---w routes | | +---w route-list* [route-index] | | ... | +--ro output | +--ro success-count uint32 | +--ro failed-count uint32 | +--ro failure-detail | +--ro failed-routes* [route-index] | +--ro route-index uint32 | +--ro error-code? uint32 +---x route-delete | +---w input | | +---w return-failure-detail? boolean | | +---w rib-name string | | +---w routes | | +---w route-list* [route-index] | | ... | +--ro output | +--ro success-count uint32 | +--ro failed-count uint32 | +--ro failure-detail | +--ro failed-routes* [route-index] | +--ro route-index uint32 | +--ro error-code? uint32
+---x route-update | +---w input | | +---w return-failure-detail? boolean | | +---w rib-name string | | +---w (match-options)? | | +--:(match-route-prefix) | | | ... | | +--:(match-route-attributes) | | | ... | | +--:(match-route-vendor-attributes) {...}? | | | ... | | +--:(match-nexthop) | | ... | +--ro output | +--ro success-count uint32 | +--ro failed-count uint32 | +--ro failure-detail | +--ro failed-routes* [route-index] | +--ro route-index uint32 | +--ro error-code? uint32 +---x nh-add | +---w input | | +---w rib-name string | | +---w nexthop-id? uint32 | | +---w sharing-flag? boolean | | +---w (nexthop-type)? | | ... | +--ro output | +--ro result uint32 | +--ro reason? string | +--ro nexthop-id? uint32 +---x nh-delete +---w input | +---w rib-name string | +---w nexthop-id? uint32 | +---w sharing-flag? boolean | +---w (nexthop-type)? | ... +--ro output +--ro result uint32 +--ro reason? string Figure 6: RPCs Structure
2.6. Notifications
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 notification Nexthops 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: o from the active state to the inactive state o from the inactive state to the active state o from the installed state to the uninstalled state o from the uninstalled state to the installed state A 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. notifications: +---n nexthop-resolution-status-change | +--ro nexthop | | +--ro nexthop-id uint32 | | +--ro sharing-flag boolean | | +--ro (nexthop-type)? | | +--:(nexthop-base) | | | ... | | +--:(nexthop-chain) {nexthop-chain}? | | | ... | | +--:(nexthop-replicate) {nexthop-replicate}? | | | ... | | +--:(nexthop-protection) {nexthop-protection}? | | | ... | | +--:(nexthop-load-balance) {nexthop-load-balance}? | | ... | +--ro nexthop-state nexthop-state-definition +---n route-change +--ro rib-name string +--ro address-family address-family-definition +--ro route-index uint64 +--ro match | +--ro (route-type)? | +--:(ipv4) | | ... | +--:(ipv6) | | ... | +--:(mpls-route) | | ... | +--:(mac-route) | | ... | +--:(interface-route) | ... +--ro route-installed-state route-installed-state-definition +--ro route-state route-state-definition +--ro route-change-reason route-change-reason-definition Figure 7: Notifications Structure
(next page on part 2)
