The router internally bundles multiple gNMI Update messages into a single gNMI Notification message within a gNMI SubscribeResponse message. This approach reduces the number of bytes sent over the gNMI interface. IOS-XR software release Release 7.8.1 supports gNMI bundling size up to 65536 bytes.

Bundling instances of the client

This table shows how the router handles bundling instances for the same or different clients.

Data under the container of the client path cannot be split into different bundles.

Timestamp assignment in gNMI notification messages

The gNMI Notification message contains a timestamp indicating when an event occurred or a sample was taken. The bundling process assigns a single timestamp for all bundled Update values, which is the timestamp of the first message in the bundle.

Exceptions to gNMI bundling size enforcement

The ON-CHANGE subscription mode does not support gNMI bundling.

The router does not enforce the bundling size in these scenarios:

• At the end of (N-1) message processing, if the notification message size is less than the configured bundling size, the router allows one extra instance, which could result in exceeding the bundling size.

• Data of a single instance exceeding the bundling size.

• The XPath network-instances/network-instance/afts does not support bundling.

The replace operation either includes all the path elements which are defined under the root or only a few of them. If the omitted path elements are configured with default values, they are reverted to their default values during the replace operation. If the omitted path elements are not configured with default values, they are deleted from the data tree during the replace operation and returned to their original unconfigured state.

gNMI replace operation in data tree schema

root +
     |
     + a --+
     |     |
     |     +-- b
     |     |
     |     +-- c
     |
     |
     + d --+
           +-- e
           |
           +-- f

In this data tree schema, b has a default value of true and c has no default value. Both b and c are set as False.

When a replace operation is performed with e and f as set, and all other elements are omitted, b is reverted to its default setting true, and c is deleted from the tree, and returned to its original unconfigured state.

gNMI replace example

This example shows the gNMI replace request and response messages.

Request Message:
replace: <
  path: <
    elem: <
      name: "system"
    >
    elem: <
      name: "config"
    >
    elem: <
      name: "hostname"
    >
  >
  val: <
    json_ietf_val: "\"testing123\""
  >
>

Response Message:
  path: <
    elem: <
      name: "system"
    >
    elem: <
      name: "config"
    >
    elem: <
      name: "hostname"
    >
  >
  op: REPLACE
>
message: <
>
timestamp: 1662873319202107537

The router securely receives the initial pathz policy either through Secure Zero Touch Provisioning (sZTP) or a secure bootstrapping protocol like bootz when booting up. The policy includes the user or group name and a list of rules defining XPaths and their associated access permissions. The policy is enforced before processing any gNMI requests.

Authorization by the gNSI pathz policy is granted or denied based on user or group credentials, permitting or declining the gNMI SetRequest accordingly.

gNMI authorization using gNSI pathz policy

Starting from release 24.2.11, you can perform gNMI XPath-based authorization using gNSI pathz policies.

The gnsi-pathz YANG model defines these counters and timestamps for each configured rule READ, WRITE, PERMIT, and DENY:

• access-rejects: 64-bit

• last-access-reject: timestamp

• access-accepts: 64-bit

• last-access-accept: timestamp

The counters get incremented per accepted or rejected XPath (e.g., per gNMI request).

Define Authorization Policy for a gNSI Pathz

The authorization policy for gNSI Pathz consists of three components.

The table lists the gNSI authorization policy components.

How Authorization Policy Matching Rules Work

Policy evaluation results with a single best match rule for the provided {user, path, or mode}. If multiple best matches emerge, an error is logged, and the evaluation fails.

If no matching rule is found, an implicit DENY is applied and detailed in a log entry.

The authorization evaluation process results in a PERMIT or DENY decision, along with the version of the policy and the identifier of the rule applied.

Scenario for Authorization Policy Rules

For user Bob, these authorization ruless apply:

• READ or WRITE (gNMI request) access to the XPath /interfaces/interface[FourHundredGigE0/0/0/0] is granted under rules 1 and 2.

• READ access to the XPath /interfaces/interface[FourHundredGigE1/1/1/1] is granted under rule 5 due to the longest match criterion, which specifies READ mode. WRITE access to this path is denied by rule 3.

• WRITE access to the XPath /interfaces/interface[FourHundredGigE2/2/2/2] is granted being a member of the Admins group as specified by rule 4. Without the Admin membership, access is denied by the default deny all rule.

• READ access to the XPath /interfaces/interface[FourHundredGigE2/2/2/2] is granted under rule 5, independent of group affiliation.

For user Jim, these authorization rules apply:

• Access to the XPath /interfaces/interface[FourHundredGigE0/0/0/0] is controlled by a policy that favors personal user permissions over group permissions. As a result, although the admins group is allowed access, Jim is individually denied access because the policy emphasizes user-specific rules.

Using he external client application, programatically you can add, edit, or remove the routing entries in the routing table. The client can be local to the router or hosted externally in the network management station.

gRIBI and OpenConfig protobuf files

All messages within the gRPC service definition are defined as protocol buffer (.proto) files. gRIBI OpenConfig proto file gribi.proto is located in the Github repository.

gRIBI's use of OpenConfig AFT for RIB management

The OpenConfig Abstract Forwarding Table (openconfig-aft.yang) data model defines a common abstraction of the RIB information and describes the forwarding entries installed on a network element. The AFT definitions are auto-generated from the OpenConfig AFT YANG schema. The protocol buffer (protobuf) representation of the OpenConfig AFT schema is available as the gribi_aft.proto file in the Github repository. gRIBI leverages this data model and the proto file to manage the RIB entries. This data model supports streaming Event-driven telemetry (EDT) data to check the installed routes in the Forwarding Information Base (FIB).

Routing preference hierarchy in gRIBI

The routes configured using static configuration have the highest preference, followed by routes configured using gRIBI, and then those configured using other protocols such as BGP or ISIS.

gRIBI RPCs

gRIBI supports these remote procedure calls (RPCs) to manage the routes in the RIB:

• Modify Operation: Provides a bidirectional streaming RPC that is used to issue modifications to the AFT in the form of a ModifyRequest message. The network element responds asynchronously with a ModifyResponse message based on each request.

  Messages:

  Supports route modifications on IPv4Entry, next hop group (NHG), next hop (NH) key objects. The traffic engineering controller ensures that specific ordering of gRIBI transactions is met—NH and NHG entries are sent before IPv4Entries. The NHGs and NHs are sent in a single ModifyRequest as repeated AFTOperation messages. The controller expects that the NHG or NH transactions are acknowledged before programming the corresponding IPv4Entry transactions. In the next hop entries, decapsulate_header, encapsulate_header, interface_ref, ip_address, ip_in_ip and network_instance attributes are supported.

  Note	IP forwarding, encapsulation and decapsulation operations are supported. MPLS operations are not supported.

  SessionParameters:

  • For client redundancy, only SINGLE_PRIMARY is supported. The primary client is designated based on the client with the highest election ID. Each AFTOperation carries an election ID. The server processes the AFTOperation if the election ID is the last advertised ID and is the highest ID on the server. If the election ID is less than the current election ID, the ID is ignored. If the election ID is equal, the client sending the message is accepted as a new master.

    For client persistence, only the PRESERVE option is supported, wherein the network device preserves the routes programmed by the gRIBI server's RIB, the system RIB, and the system FIB when the primary client disconnects.

    When gRIBI restarts, the configuration in the gRIBI server’s cache are sent to the router to reprogram the RIB. The election ID is reset to 0 upon restart.

  The table shows the request and response messages exchanged between the client and server for the Modify RPCs.

  Table 20. Request and Response Messages of Client-Server Exchange for Modify RPCs

  Operation	Request (Client to Server)	Response (Server to Client)
  Session setup	Message ModifyResponse { SessionParameters }	Message ModifyResponse{ SessionParametersResult }
  Election ID	Message Modify Request { election_id (int128) }	Message Modify Request { election_id (int128) }
  AFTOperation	Message ModifyResponse { repeated AFTOperation operation }	Message ModifyResponse{ repeated AFTResult result }

• Get Operation: Retrieves the content of the installed AFTs from the gRIBI daemon. The client requests for information using a GetRequest message, and the server responds with the set of currently installed entries via the GetResponse message. Once all entries have been sent, the server closes the RPC.

  Supports all operations defined in the gribi.proto file.

  Note	IPv4Entry.metdata is supported only in Get RPC, and not in AFT telemetry.

  The table shows the request and response messages exchanged between the client and server for the Get RPCs.

  Table 21. Request and Response Messages of Client-Server Exchange for Get RPCs

  Operation	Request (Client to Server)	Response (Server to Client)
  Get entries	Message GetRequest { network_instance name [string] all AFTType aft }	Message GetResponse { repeated AFTEntry entry }

• Flush Operation: Removes all AFT entries that are currently installed on the server using gRIBI RPCs. The client sends a FlushRequest message to remove all the entries, and the server responds with a FlushResponse message after the operation is complete.

  Supports all operations defined in the gribi.proto file.

  The table shows the request and response exchanged between the client and server for the Flush RPCs.

  Table 22. Request and Response Messages of Client-Server Exchange for Flush RPCs

  Operation	Request (Client to Server)	Response (Server to Client)
  Flush entries	Message FlushRequest { election id [uint 128] override [bool] network_instance name [string] all }	Message FlushResponse { timestamp [int64] }

A P4Runtime to manage traffic operations is a control plane specification to manage the data plane elements of a device. It defines the navigation and management of packets through data plane blocks using P4Runtime APIs. These data plane blocks can be managed to perform a set of traffic operations between the P4Runtime controller and the router:

• Send or receive packets using PacketOut and PacketIn I/O messages—StreamMessageRequest, StreamMessageResponse and StreamError messages.

• Elect the primary controller using the MasterArbitrationUpdate message.

• Read and write forwarding table entries, protocol headers, counters, and other P4 entities.

For more information about how controllers can connect to the router and program P4-defined functionalities, see P4RT specification.

Starting from IOS XR software release 24.3.1, you can log gRPC AAA accounting data through gNSI accounting (Acctz). The gNSI Acctz data is logged, stored in accounting records, and send to gNSI client for monitoring purposes. These gNSI Acctz accounting records contain

• users' login or logout times,

• network access resources such as interface IP and port, and

• duration of each session.

The gNSI Acctz logging can be done using the RecordSubscribe() gRPC request to a router. For more information on the RecordSubscribe() RPC, see the GitHub repository.

gNSI Acctz Logging Stream Capacity

The gNSI Acctz logs are recorded in a queue, maintaining a history of the 10 most recent records. When the accounting queue is full and no gNSI Acctz collectors are connected, the stream drops the records. Besides the 10 records stored for streaming, up to 512 additional records are stored during processing. As new records arrive, the data stream continues until the gNSI session ends or an error occurs, such as a client disconnection due to network issues or the server going down. If the server's output buffer remains full for an extended period, new records are dropped until the collector starts receiving them.

When the queue reaches its full capacity, the system automatically replaces the oldest records with the newest ones. The router then transmits this logged information through gNSI to gNSI client for real-time monitoring purposes. You can configure the queue size using the grpc aaa accounting queue-size command.

Supported Records for gNSI Acctz Logging

gNSI Acctz logging system supports Command and gRPC service records.

Default Behavior and Verification of gNSI Acctz Logging

By default, gNSI Acctz records are logged when the configuration is enabled. You can verify the gNSI Acctz using show gnsi state , show gnsi acctz statistics , and show aaa accounting statistics commands.