A module defines a single data model. However, a module can reference definitions in other modules and submodules by using the import statement to import external modules or the include statement to include one or more submodules. A module can provide augmentations to another module by using the augment statement to define the placement of the new nodes in the data model hierarchy and the when statement to define the conditions under which the new nodes are valid. Prefix is used when referencing definitions in the imported module.

YANG models are available for configuring a feature and to get operational state (similar to show commands)

This is the configuration YANG model for AAA (denoted by - cfg)

(snippet)
module Cisco-IOS-XR-aaa-locald-cfg {

  /*** NAMESPACE / PREFIX DEFINITION ***/

  namespace "http://cisco.com/ns/yang/Cisco-IOS-XR-aaa-locald-cfg";


  prefix "aaa-locald-cfg";

  /*** LINKAGE (IMPORTS / INCLUDES) ***/

  import Cisco-IOS-XR-types { prefix "xr"; }

  import Cisco-IOS-XR-aaa-lib-cfg { prefix "a1"; }

  /*** META INFORMATION ***/

  organization "Cisco Systems, Inc.";
										.........................
										......................... (truncated)

This is the operational YANG model for AAA (denoted by -oper)

(snippet)
module Cisco-IOS-XR-aaa-locald-oper {

  /*** NAMESPACE / PREFIX DEFINITION ***/

  namespace "http://cisco.com/ns/yang/Cisco-IOS-XR-aaa-locald-oper";


  prefix "aaa-locald-oper";

  /*** LINKAGE (IMPORTS / INCLUDES) ***/

  import Cisco-IOS-XR-types { prefix "xr"; }

  include Cisco-IOS-XR-aaa-locald-oper-sub1 {
    revision-date 2015-01-07;
  }

  /*** META INFORMATION ***/

  organization "Cisco Systems, Inc.";
				........................
				........................ (truncated)

Note	A module may include any number of sub-modules, but each sub-module may belong to only one module. The names of all standard modules and sub-modules must be unique.

YANG data models can be represented in a hierarchical, tree-based structure with nodes, which makes them more easily understandable. YANG defines four nodes types. Each node has a name, and depending on the node type, the node might either define a value or contain a set of child nodes. The nodes types (for data modeling) are:

• leaf node - contains a single value of a specific type

• list node - contains a sequence of list entries, each of which is uniquely identified by one or more key leafs

• leaf-list node - contains a sequence of leaf nodes

• container node - contains a grouping of related nodes containing only child nodes, which can be any of the four node types

YANG defines data types for leaf values. These data types help the user in understanding the relevant input for a leaf.

Each feature has a defined YANG model that is synthesized from the schemas. A model in a tree format includes:

• Top level nodes and their subtrees

• Subtrees that augment nodes in other yang models

• Custom RPCs

The options available using the CLI are defined as leaf-nodes in data models. The defined data types, indicated corresponding to each leaf-node, help the user to understand the required inputs.

gRPC Network Operations Interface (gNOI) defines a set of gRPC-based microservices for executing operational commands on network devices. Extensible Manageability Services (EMS) gNOI is the Cisco IOS XR implementation of gNOI.

gNOI uses gRPC as the transport protocol and the configuration is same as that of gRPC.

From R24.4.10R24.4.1, EMS gNOI supports Bit Error Rate Testing (BERT) operations on NCS 1014 for the following remote procedure calls (RPCs):

• StartBERT

• StopBERT

• GetBERTResults

StartBERT

Starts a new BERT operation for a set of ports. Each BERT operation is uniquely identified by an ID, which is given by the caller. The caller can then use this ID (as well as the list of the ports) either to stop the BERT operation or get the BERT results, or can perform both BERT operations.

rpc StartBERT(StartBERTRequest) returns(StartBERTResponse) {}

Request and response messages

RPC to 10.127.60.184:57400
RPC start time: 13:59:45.488759
RPC start time: 13:59:45.488777
per_port_request for  startbert  is 
 interface {
  elem {
    name: "terminal-device"
  }
  elem {
    name: "logical-channels"
  }
  elem {
    name: "channel"
    key {
      key: "index"
      value: "4014"
    }
  }
}
prbs_polynomial: PRBS_POLYNOMIAL_PRBS31
test_duration_in_secs: 360

Diag.StartBert Response
test_bert3
[interface {
  elem {
    name: "terminal-device"
  }
  elem {
name: "logical-channels"
  }
  elem {
    name: "channel"
    key {
      key: "index"
      value: "4014"
    }
  }
}
status: BERT_STATUS_OK
]
RPC end time: 13:59:45.816653
RPC end time: 2024-11-05 08:29:45.816739

The supported values for prbs_polynomial on NCS1014:

• Trunk Ports — PRBS7, PRBS13, PRBS23, and PRBS31

• Client Ports — PRBS23 and PRBS31

The StartBERT RPC can return an error status in any one of the following scenarios:

The RPC returns an OK status when there is no error situation encountered.

Stops an already in-progress BERT operation on a set of ports. The caller uses the BERT operation ID it previously used when starting the operation to stop it.

StopBERT

rpc StopBERT(StopBERTRequest) returns(StopBERTResponse) {}

Request and response messages

message StopBERTRequest {
RPC to 10.127.60.184:57400
RPC start time: 13:59:27.642444
RPC start time: 13:59:27.642462
per_port_request for  stopbert  is 
 interface {
  elem {
    name: "terminal-device"
  }
  elem {
    name: "logical-channels"
  }
  elem {
    name: "channel"
    key {
      key: "index"
      value: "4014"
    }
  }
}

bert_operation_id: "test_bert3"
per_port_requests {
  interface {
    elem {
      name: "terminal-device"
    }
    elem {
      name: "logical-channels"
    }
    elem {
      name: "channel"
      key {
        key: "index"
        value: "4014"
      }
    }
  }
}

message StopBERTResponse {
  bert_operation_id: "test_bert3"
per_port_responses {
  interface {
    origin: "openconfig-terminal-device"
    elem {
      name: "terminal-device"
    }
    elem {
      name: "logical-channels"
    }
    elem {
      name: "channel"
      key {
        key: "index"
        value: "4014"
      }
    }
  }
  status: BERT_STATUS_OK
}

Diag.StopBert Response

test_bert3
[interface {
  origin: "openconfig-terminal-device"
  elem {
    name: "terminal-device"
  }
  elem {
    name: "logical-channels"
  }
  elem {
    name: "channel"
    key {
      key: "index"
      value: "4014"
    }
  }
}
status: BERT_STATUS_OK
]
RPC end time: 13:59:27.726083
RPC end time: 2024-11-05 08:29:27.726099

}

When the PerPortRequest field is not configured, then the device stops and deletes BERT sessions on all the ports associated with the BERT ID.

The RPC is expected to return an error status in any one of the following situations:

• When there is at least one BERT operation in progress on a port which cannot be stopped in the middle of the operation (either due to lack of support or internal problems).

• When no BERT operation, which matches the given BERT operation ID, is in progress or completed on any of the ports specified by the request.

The StopBERT RPC returns to an OK status when there is no error situation is encountered.

Note	The BERT operation is considered completed if the device has a record or history of it. Also note that you might receive a stop request for a port which has completed BERT, as long as the recorded BERT operation ID matches the one specified by the request.

Gets BERT results during the BERT operation or after the operation completes. The caller uses the BERT operation ID that it previously used when starting the operation to query it. The device stores results for the last BERT based on the required period of time.

GetBERTResults

rpc GetBERTResult(GetBERTResultRequest) returns(GetBERTResultResponse) {}

Request and response messages

message GetBERTResultRequest {
  RPC to 10.127.60.184:57400
RPC start time: 14:00:01.623902
RPC start time: 14:00:01.623919
per_port_request for  getbertresult  is 
 interface {
  elem {
    name: "terminal-device"
  }
  elem {
    name: "logical-channels"
  }
  elem {
    name: "channel"
    key {
      key: "index"
      value: "4014"
    }
  }
}

message GetBERTResultResponse {
  test_bert3
[interface {
  elem {
    name: "terminal-device"
  }
  elem {
    name: "logical-channels"
  }
  elem {
    name: "channel"
    key {
      key: "index"
      value: "4014"
    }
  }
}
status: BERT_STATUS_OK
]
RPC end time: 13:59:45.816653
RPC end time: 2024-11-05 08:29:45.816739

}

When the per_port_requests is ignored, then the device returns results and status for all the ports associated with the BERT ID.

The following table lists the descriptions of BERT results and status.

The GetBERTResults RPC can return error status in any one of the following scenarios:

• When no BERT operation, which matches the given BERT operation ID, is in-progress or completed on any of the ports specified by the request.

• When the BERT operation ID does not match the in progress or completed BERT operation on any of the ports specified by the request.

The RPC returns an OK status when none of these situations is encountered.

Note	The BERT operation is considered as completed only when the device has a record of it.