A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications
Extracted elements (28)
Only two generic RPC operations are defined (`continuity-check` and `path-discovery`) as base building blocks, corresponding to Ping and Traceroute semantics respectively. Technology-specific models (e.g., for IP, MPLS LSP Ping) are expected to augment these RPCs with protocol-specific parameters rather than defining new top-level operations.
The retrieval methods module is intentionally separated from the generic connectionless OAM data model (RFC 8532) to allow retrieval procedures to evolve independently and faster than the underlying data model. New procedures can be defined to retrieve the same RFC 8532 data without modifying it.
The use of `identityref` for `protocol-id`, `status-code`, `status-sub-code`, and `protocol-id-meta-data` rather than enumerations allows extensibility: technology-specific YANG modules can derive new identities without modifying this base module.
Appendix A demonstrates that the `ietf-connectionless-oam-methods` module can be extended with persistent data retrieval RPCs (e.g., `cc-get-persistent-id`, `cc-persistent-get-export-details`) using IPFIX (RFC 7011) or YANG-Push as export methods, showing that the on-demand RPCs in the base module are not the only retrieval mechanism.
For IP OAM, the `continuity-check` RPC maps to IP Ping (ICMP Echo, RFC 792 / RFC 4443) and the `path-discovery` RPC maps to IP Traceroute. For MPLS, it maps to LSP Ping (RFC 8029). Each technology extension MUST augment the base RPCs with its own required parameters.
The base module supports both nested OAM workflows (performing OAM at different levels via a unified interface) and interactive OAM workflows (performing OAM at the same level via a unified interface), accommodating heterogeneous multi-layer network management scenarios.
Both `protocol-id`, `status-code`, and `status-sub-code` output leaves in `response-info` (continuity-check) and each `response-list` entry (path-discovery) are marked `mandatory true`; implementations MUST populate these in every RPC response.
Both `source-interface` and `outbound-interface` leaves in the `rpc-input-parameters` grouping are marked `mandatory true`, so implementations MUST supply them in every RPC invocation of `continuity-check` and `path-discovery`.
The lowest NETCONF layer MUST use a secure transport, and the mandatory-to-implement secure transport is SSH (RFC 6242). For RESTCONF, the mandatory-to-implement secure transport is TLS (RFC 8446 — TLS 1.3).
When the `session-type` leaf is specified in a `continuity-check` or `path-discovery` RPC input, it MUST be set to `on-demand`, as both operations are inherently on-demand retrieval procedures.
The Appendix A example module defines an `export-method` identity with two derived values: `ipfix-export` (IPFIX-based, configured separately) and `yang-push-export` (YANG-Push subscription). Export details are retrieved via a persistent-id cookie obtained from a prior RPC call.
The `continuity-check` RPC input includes: `count` (uint32, default 5, range 0..4294967295 — number of probe packets), `ttl` (uint8, default 255 — packet lifetime), and `packet-size` (uint32, range 64..10000, default 64 octets — probe packet size).
The `continuity-check` RPC operation (gated by `cl-oam:continuity-check` feature) sends a Ping-like probe to a destination test point and returns a `response-info` container plus the `continuity-check-data` grouping from RFC 8532. It accepts `count`, `ttl`, and `packet-size` input parameters.
The `continuity-check` RPC output `response-info` container holds mandatory `protocol-id` and `status-code` leaves (both identityref), a mandatory `status-sub-code` leaf, and an optional `protocol-id-meta-data` leaf. It also reuses the `continuity-check-data` grouping from RFC 8532 for session statistics.
The `ietf-connectionless-oam-methods` YANG module defines RPC operations for connectionless OAM, with namespace `urn:ietf:params:xml:ns:yang:ietf-connectionless-oam-methods` and prefix `cloam-methods`. It imports `ietf-interfaces` and `ietf-connectionless-oam` (RFC 8532).
The `path-discovery` output includes a `path-verification` container with `flow-info` (string) and `session-path-verification-statistics` (verified-count and failed-count uint32 leaves), enabling verification that traffic follows the expected path.
The `path-discovery` RPC operation (gated by `cl-oam:path-discovery` feature) sends a Traceroute-like probe and returns a keyed `response-list` plus the `path-discovery-data` grouping from RFC 8532. The single hop-specific input parameter is `max-ttl` (default 255).
The `path-discovery` RPC output contains a keyed `response-list` (key: `response-index` uint32) where each entry carries mandatory `protocol-id`, `status-code`, and `status-sub-code` leaves. The output also reuses `path-discovery-data` from RFC 8532, which includes `path-trace-info` and path verification statistics.
The `path-trace-info` list in `path-discovery` output records per-hop information including test point location, router-id, ingress/egress interface names, `timestamp-type`, four alternative timestamp encodings (64-bit, 80-bit PTP, 32-bit NTP, 32-bit ICMP milliseconds), `queue-depth`, `transit-delay`, and `app-meta-data`.
The `protocol-id` base identity represents the protocol used in an OAM operation. Derived identities defined in this module include: `protocol-id-internet`, `protocol-id-proprietary`, `protocol-id-sfc`, `protocol-id-mpls`, `protocol-id-mpls-tp`, `protocol-id-twamp`, and `protocol-id-bier`.
The `protocol-id-meta-data` base identity carries optional metadata associated with a protocol-id. The only base-defined derived identity is `protocol-internet-number`, representing an IANA-assigned Internet Protocol number to aid protocol processing.
The `rpc-input-parameters` grouping provides common input fields shared by both RPCs: a `destination-tp` container (using `cl-oam:tp-address`), mandatory `source-interface` and `outbound-interface` leaves (type `if:interface-ref`), and an optional `vrf` leaf (type `cl-oam:routing-instance-ref`).
The `status-code` base identity represents the high-level outcome of an OAM RPC. Defined values are `success-reach` (destination reachable), `fail-reach` (destination unreachable), `success-path-verification`, and `fail-path-verification`, all referenced to RFC 7276.
The `status-sub-code` base identity provides detailed failure reasons beneath a `status-code`. Base-defined values are `invalid-cc` (invalid Continuity Check message) and `invalid-pd` (invalid path discovery message); technology-specific sub-codes may be defined in augmenting modules.
This document registers a URI in the IETF XML Registry (RFC 3688): `urn:ietf:params:xml:ns:yang:ietf-connectionless-oam-methods`, with registrant contact the IESG and XML type N/A (XML namespace).
This document registers the YANG module `ietf-connectionless-oam-methods` in the YANG Module Names registry (RFC 6020), with namespace `urn:ietf:params:xml:ns:yang:ietf-connectionless-oam-methods`, prefix `cloam-methods`, and reference RFC 8533.
Access to the `continuity-check` and `path-discovery` RPC operations MUST be controlled because unauthorized use of these operations can enable network reconnaissance or trigger denial-of-service attacks on the local device and the network. Implementations SHOULD use NACM (RFC 8341) to restrict which NETCONF/RESTCONF users can invoke these operations.
The Network Configuration Access Control Model (NACM, RFC 8341) provides the mechanism to restrict particular NETCONF or RESTCONF users to a preconfigured subset of available protocol operations and content, and should be applied to the OAM RPC operations defined in this module.