Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+   SearchTech-invite World Map Symbol

RFC 8431

Proposed STD
Pages: 71
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: I2RS

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

Part 1 of 3, p. 1 to 21
None       Next Section

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 Section