Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8431

A YANG Data Model for the Routing Information Base (RIB)

Pages: 71
Proposed Standard
Part 1 of 3 – Pages 1 to 21
None   None   Next

Top   ToC   RFC8431 - Page 1
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.
Top   ToC   RFC8431 - Page 2
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
Top   ToC   RFC8431 - Page 3

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.
Top   ToC   RFC8431 - Page 4
   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
Top   ToC   RFC8431 - Page 5
   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
Top   ToC   RFC8431 - Page 6
      |  |  +---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}?
         |     |  ...
Top   ToC   RFC8431 - Page 7
         |     +--:(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
Top   ToC   RFC8431 - Page 8

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
Top   ToC   RFC8431 - Page 9

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.
Top   ToC   RFC8431 - Page 10
   +--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
Top   ToC   RFC8431 - Page 11

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.
Top   ToC   RFC8431 - Page 12
   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
Top   ToC   RFC8431 - Page 13
|        +--:(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)?
Top   ToC   RFC8431 - Page 14
|        |        |     |  +--:(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)?
Top   ToC   RFC8431 - Page 15
|        |        +--:(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 Structure

2.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)
Top   ToC   RFC8431 - Page 16
   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.
Top   ToC   RFC8431 - Page 17
   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)
Top   ToC   RFC8431 - Page 18
   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
Top   ToC   RFC8431 - Page 19
      +---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
Top   ToC   RFC8431 - Page 20

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.
Top   ToC   RFC8431 - Page 21
   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)

Next Section