RFC 8531
Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols
Internet Engineering Task Force (IETF) D. Kumar Request for Comments: 8531 Cisco Category: Standards Track Q. Wu ISSN: 2070-1721 M. Wang Huawei April 2019 Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) ProtocolsAbstract
This document presents a base YANG data model for connection-oriented Operations, Administration, and Maintenance (OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology-specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface). The YANG data model in this document conforms to the Network Management Datastore Architecture. 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/rfc8531.
Copyright Notice Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 7 3. Architecture of Generic YANG Data Model for Connection- Oriented OAM . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Overview of the Connection-Oriented OAM YANG Data Model . . . 8 4.1. Maintenance Domain (MD) Configuration . . . . . . . . . . 9 4.2. Maintenance Association (MA) Configuration . . . . . . . 10 4.3. Maintenance End Point (MEP) Configuration . . . . . . . . 11 4.4. RPC Definitions . . . . . . . . . . . . . . . . . . . . . 11 4.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 14 4.6. Monitor Statistics . . . . . . . . . . . . . . . . . . . 14 4.7. OAM Data Hierarchy . . . . . . . . . . . . . . . . . . . 14 5. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19 6. Base Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.1. MEP Address . . . . . . . . . . . . . . . . . . . . . . . 42 6.2. MEP ID for Base Mode . . . . . . . . . . . . . . . . . . 42 6.3. Maintenance Association . . . . . . . . . . . . . . . . . 42 7. Connection-Oriented OAM YANG Data Model Applicability . . . . 43 7.1. Generic YANG Data Model Extension for TRILL OAM . . . . . 43 7.1.1. MD Configuration Extension . . . . . . . . . . . . . 43 7.1.2. MA Configuration Extension . . . . . . . . . . . . . 44 7.1.3. MEP Configuration Extension . . . . . . . . . . . . . 45 7.1.4. RPC Extension . . . . . . . . . . . . . . . . . . . . 46 7.2. Generic YANG Data Model Extension for MPLS-TP OAM . . . . 46 7.2.1. MD Configuration Extension . . . . . . . . . . . . . 47 7.2.2. MA Configuration Extension . . . . . . . . . . . . . 48 7.2.3. MEP Configuration Extension . . . . . . . . . . . . . 48 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 10.1. Normative References . . . . . . . . . . . . . . . . . . 50 10.2. Informative References . . . . . . . . . . . . . . . . . 51 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction
Operations, Administration, and Maintenance (OAM) are important networking functions that allow operators to: 1. monitor network communications (i.e., reachability verification and Continuity Check) 2. troubleshoot failures (i.e., fault verification and localization) 3. monitor service-level agreements and performance (i.e., performance management) An overview of OAM tools is presented in [RFC7276]. Over the years, many technologies have developed similar tools for fault and performance management. The different sets of OAM tools may support both connection-oriented technologies or connectionless technologies. In connection-oriented technologies, a connection is established prior to the transmission of data. After the connection is established, no additional control information such as signaling or operations and maintenance information is required to transmit the actual user data. In connectionless technologies, data is typically sent between communicating endpoints without prior arrangement, but control information is required to identify the destination (e.g., [G.800]). The YANG data model for OAM protocols using connectionless communications is specified in [RFC8532] and [IEEE802.1Q]. Connectivity Fault Management as specified in [IEEE802.1Q] is a well- established OAM standard that is widely adopted for Ethernet networks. ITU-T [G.8013], MEF Forum (MEF) Service OAM [MEF-17], MPLS Transport Profile (MPLS-TP) [RFC6371], and Transparent Interconnection of Lots of Links (TRILL) [RFC7455] all define OAM mechanisms based on the manageability framework of Connectivity Fault Management (CFM) [IEEE802.1Q]. Given the wide adoption of the underlying OAM concepts defined in CFM [IEEE802.1Q], it is a reasonable choice to develop the unified management framework for connection-oriented OAM based on those concepts. In this document, we take the CFM [IEEE802.1Q] model and extend it to a technology-independent framework and define the corresponding YANG data model accordingly. The YANG data model presented in this document is the base model for connection-oriented OAM protocols and supports generic continuity check, connectivity verification, and path discovery (traceroute). The generic YANG data model for connection-oriented OAM is designed to be extensible to other connection-oriented technologies. Technology-dependent nodes
and remote procedure call (RPC) commands are defined in technology- specific YANG data models, which use and extend the base model defined here. As an example, Virtual eXtensible Local Area Network (VXLAN) uses the source UDP port number for flow entropy, while TRILL uses either (a) MAC addresses, (b) the VLAN tag or Fine-Grained Label, and/or (c) IP addresses for flow entropy in the hashing for multipath selection. To capture this variation, corresponding YANG data models would define the applicable structures as augmentation to the generic base model presented here. This accomplishes three goals: First, it keeps each YANG data model smaller and more manageable. Second, it allows independent development of corresponding YANG data models. Third, implementations can limit support to only the applicable set of YANG data models (e.g., TRILL RBridge may only need to implement the generic model and the TRILL YANG data model). The YANG data model presented in this document is generated at the management layer. Encapsulations and state machines may differ according to each OAM protocol. A user who wishes to issue a Continuity Check command or a Loopback or initiate a performance monitoring session can do so in the same manner, regardless of the underlying protocol or technology or specific vendor implementation. As an example, consider a scenario where connectivity from device A loopback to device B fails. Between device A and B there are IEEE 802.1 bridges a, b, and c. Let's assume a, b, and c are using CFM [IEEE802.1Q]. A user, upon detecting the loopback failure, may decide to drill down to the lower level at different segments of the path and issue the corresponding fault verification (Loopback Message) and fault isolation (Looktrace Message) tools, using the same API. This ability to drill down to a lower layer of the protocol stack at a specific segment within a path for fault localization and troubleshooting is referred to as "nested OAM workflow". It is a useful concept that leads to efficient network troubleshooting and maintenance workflows. The connection-oriented OAM YANG data model presented in this document facilitates that without needing changes to the underlying protocols. The YANG data model in this document conforms to the Network Management Datastore Architecture defined in [RFC8342].2. Conventions Used in This Document
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.
Many of the terms used in this document (including those set out in Sections Section 2.1 and Section 2.2) are specific to the world of OAM. This document does not attempt to explain the terms but does assume that the reader is familiar with the concepts. For a good overview, read [IEEE802.1Q]. For an example of how these OAM terms appear in IETF work, see [RFC6371].2.1. Abbreviations
CCM - Continuity Check Message [IEEE802.1Q] ECMP - Equal-Cost Multipath LBM - Loopback Message [IEEE802.1Q] LTM - Linktrace Message [IEEE802.1Q] MP - Maintenance Point [IEEE802.1Q] MEP - Maintenance End Point [RFC7174] (also known as Maintenance association End Point [IEEE802.1Q] and MEG End Point [RFC6371]) MIP - Maintenance Intermediate Point [RFC7174] (also known as Maintenance domain Intermediate Point [IEEE802.1Q] and MEG Intermediate Point [RFC6371]) MA - Maintenance Association [IEEE802.1Q] [RFC7174] MD - Maintenance Domain [IEEE802.1Q] MEG - Maintenance Entity Group [RFC6371] MTV - Multi-destination Tree Verification Message OAM - Operations, Administration, and Maintenance [RFC6291] TRILL - Transparent Interconnection of Lots of Links [RFC6325] CFM - Connectivity Fault Management [RFC7174] [IEEE802.1Q] RPC - Remote Procedure Call CC - Continuity Check [RFC7276] CV - Connectivity Verification [RFC7276]
2.2. Terminology
Continuity Checks - Continuity Checks are used to verify that a destination is reachable and therefore also are referred to as "reachability verification". Connectivity Verification - Connectivity Verification is used to verify that a destination is connected. It is also referred to as "path verification" and used to verify not only that the two MPs are connected, but also that they are connected through the expected path, allowing detection of unexpected topology changes. Proactive OAM - Proactive OAM refers to OAM actions that are carried out continuously to permit proactive reporting of fault. A proactive OAM method requires persistent configuration. On-demand OAM - On-demand OAM refers to OAM actions that are initiated via manual intervention for a limited time to carry out diagnostics. An on-demand OAM method requires only transient configuration.2.3. Tree Diagrams
Tree diagrams used in this document follow the notation defined in [RFC8340].3. Architecture of Generic YANG Data Model for Connection-Oriented OAM
In this document, we define a generic YANG data model for connection- oriented OAM protocols. The YANG data model defined here is generic in a sense that other technologies can extend it for technology- specific needs. The generic YANG data model for connection-oriented OAM acts as the root for other OAM YANG data models. This allows users to traverse between different OAM protocols with ease through a uniform API set. This also enables a nested OAM workflow. Figure 1 depicts the relationship of different OAM YANG data models to the Generic YANG Data Model for connection-oriented OAM. The Generic YANG data model for connection-oriented OAM provides a framework where technology-specific YANG data models can inherit constructs from the base YANG data models without needing to redefine them within the sub-technology.
+-----------+ |Connection-| | Oriented | | generic | | OAM YANG | +-+-+-+-+-+-+ | | | +------------------------------------------+ | | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | TRILL | | MPLS-TP | . . .| foo | |OAM YANG | |OAM YANG | |OAM YANG | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | | | | | +-+-+-+-+-+ | | . . .| foo | | | |sub tech | | | +-+-+-+-+-+ | | | | | | +-------------------------------------------------------+ | Uniform API | +-------------------------------------------------------+ Figure 1: Relationship of OAM YANG Data Model to Generic (Base) YANG Data Model4. Overview of the Connection-Oriented OAM YANG Data Model
In this document, we adopt the concepts of the CFM [IEEE802.1Q] model and structure such that it can be adapted to different connection- oriented OAM protocols. At the top of the model is the Maintenance Domain. Each Maintenance Domain is associated with a Maintenance Name and a Domain Level. Under each Maintenance Domain, there is one or more Maintenance Associations (MAs). In TRILL, the MA can correspond to a Fine- Grained Label. Under each MA, there can be two or more MEPs (Maintenance End Points). MEPs are addressed by their respective technology-specific address identifiers. The YANG data model presented here provides flexibility to accommodate different addressing schemes.
Commands are presented in the management protocol, which is orthogonal to the Maintenance Domain. These are RPC commands, in YANG terms. They provide uniform APIs for Continuity Check, connectivity verification, path discovery (traceroute), and their equivalents, as well as other OAM commands. The OAM entities in the generic YANG data model defined here will be either explicitly or implicitly configured using any of the OAM tools. The OAM tools used here are limited to the OAM toolset specified in Section 5.1 of [RFC7276]. In order to facilitate a zero-touch experience, this document defines a default mode of OAM. The default mode of OAM is referred to as the "Base Mode" and specifies default values for each of the model's parameters, such as Maintenance Domain Level, Name of the Maintenance Association, Addresses of MEPs, and so on. The default values of these depend on the technology. Base Mode for TRILL is defined in [RFC7455]. Base Mode for other technologies and future extensions developed in IETF will be defined in their corresponding documents. It is important to note that no specific enhancements are needed in the YANG data model to support Base Mode. Implementations that comply with this document use, by default, the data nodes of the applicable technology. Data nodes of the Base Mode are read-only nodes.4.1. Maintenance Domain (MD) Configuration
The container "domains" is the top-level container within the "gen-oam" module. Within the container "domains", a separate list is maintained per MD. The MD list uses the key "md-name-string" for indexing. The "md-name-string" is a leaf and derived from type string. Additional name formats as defined in [IEEE802.1Q], or other standards, can be included by association of the "md-name-format" with an identity-ref. The "md-name-format" indicates the format of the augmented "md-name". The "md-name" is presented as choice/case construct. Thus, it is easily augmentable by derivative work.
module: ietf-connection-oriented-oam
+--rw domains
+--rw domain* [technology md-name-string]
+--rw technology identityref
+--rw md-name-string md-name-string
+--rw md-name-format? identityref
+--rw (md-name)?
| +--:(md-name-null)
| +--rw md-name-null? empty
+--rw md-level? md-level
Snippet of Data Hierarchy Related to OAM Domains
4.2. Maintenance Association (MA) Configuration
Within a given Maintenance Domain, there can be one or more
Maintenance Associations (MAs). MAs are represented as a list and
indexed by the "ma-name-string". Similar to "md-name" defined
previously, additional name formats can be added by augmenting the
name-format "identity-ref" and adding applicable case statements to
"ma-name".
module: ietf-connection-oriented-oam
+--rw domains
+--rw domain* [technology md-name-string]
.
.
+--rw mas
+--rw ma* [ma-name-string]
+--rw ma-name-string ma-name-string
+--rw ma-name-format? identityref
+--rw (ma-name)?
| +--:(ma-name-null)
| +--rw ma-name-null? empty
Snippet of Data Hierarchy Related to Maintenance Associations (MAs)
4.3. Maintenance End Point (MEP) Configuration
Within a given Maintenance Association (MA), there can be one or more Maintenance End Points (MEPs). MEPs are represented as a list within the data hierarchy and indexed by the key "mep-name". module: ietf-connection-oriented-oam +--rw domains +--rw domain* [technology md-name-string] +--rw technology identityref . . +--rw mas +--rw ma* [ma-name-string] . . +--rw mep* [mep-name] | +--rw mep-name mep-name | +--rw (mep-id)? | | +--:(mep-id-int) | | +--rw mep-id-int? int32 | +--rw mep-id-format? identityref | +--rw (mep-address)? | | +--:(mac-address) | | | +--rw mac-address? yang:mac-address | | +--:(ip-address) | | +--rw ip-address? inet:ip-address . . . . . . Snippet of Data Hierarchy Related to Maintenance End Point (MEP)4.4. RPC Definitions
The RPC model facilitates issuing commands to a "server" (in this case, to the device that need to execute the OAM command) and obtaining a response. The RPC model defined here abstracts OAM- specific commands in a technology-independent manner. There are several RPC commands defined for the purpose of OAM. In this section, we present a snippet of the Continuity Check command for illustration purposes. Please refer to Section 4.5 for the complete data hierarchy and Section 5 for the YANG module.
module: ietf-connection-oriented-oam
+--rw domains
+--rw domain* [technology md-name-string]
+--rw technology identityref
.
.
rpcs:
+---x continuity-check {continuity-check}?
| +---w input
| | +---w technology? identityref
| | +---w md-name-string -> /domains/domain/md-name-string
| | +---w md-level? -> /domains/domain/md-level
| | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
| | +---w cos-id? uint8
| | +---w ttl? uint8
| | +---w sub-type? identityref
| | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name
| | +---w destination-mep
| | | +---w (mep-address)?
| | | | +--:(mac-address)
| | | | | +---w mac-address? yang:mac-address
| | | | +--:(ip-address)
| | | | +---w ip-address? inet:ip-address
| | | +---w (mep-id)?
| | | | +--:(mep-id-int)
| | | | +---w mep-id-int? int32
| | | +---w mep-id-format? identityref
| | +---w count? uint32
| | +---w cc-transmit-interval? time-interval
| | +---w packet-size? uint32
| +--ro output
| +--ro (monitor-stats)?
| +--:(monitor-null)
| +--ro monitor-null? empty
+---x continuity-verification {connectivity-verification}?
| +---w input
| | +---w md-name-string -> /domains/domain/md-name-string
| | +---w md-level? -> /domains/domain/md-level
| | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
| | +---w cos-id? uint8
| | +---w ttl? uint8
| | +---w sub-type? identityref
| | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name
| | +---w destination-mep
| | | +---w (mep-address)?
| | | | +--:(mac-address)
| | | | | +---w mac-address? yang:mac-address
| | | | +--:(ip-address)
| | | | +---w ip-address? inet:ip-address
| | | +---w (mep-id)?
| | | | +--:(mep-id-int)
| | | | +---w mep-id-int? int32
| | | +---w mep-id-format? identityref
| | +---w count? uint32
| | +---w interval? time-interval
| | +---w packet-size? uint32
| +--ro output
| +--ro (monitor-stats)?
| +--:(monitor-null)
| +--ro monitor-null? empty
+---x traceroute {traceroute}?
+---w input
| +---w md-name-string -> /domains/domain/md-name-string
| +---w md-level? -> /domains/domain/md-level
| +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
| +---w cos-id? uint8
| +---w ttl? uint8
| +---w command-sub-type? identityref
| +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name
| +---w destination-mep
| | +---w (mep-address)?
| | | +--:(mac-address)
| | | | +---w mac-address? yang:mac-address
| | | +--:(ip-address)
| | | +---w ip-address? inet:ip-address
| | +---w (mep-id)?
| | | +--:(mep-id-int)
| | | +---w mep-id-int? int32
| | +---w mep-id-format? identityref
| +---w count? uint32
| +---w interval? time-interval
+--ro output
+--ro response* [response-index]
+--ro response-index uint8
+--ro ttl? uint8
+--ro destination-mep
| +--ro (mep-address)?
| | +--:(mac-address)
| | | +--ro mac-address? yang:mac-address
| | +--:(ip-address)
| | +--ro ip-address? inet:ip-address
| +--ro (mep-id)?
| | +--:(mep-id-int)
| | +--ro mep-id-int? int32
| +--ro mep-id-format? identityref
+--ro mip {mip}?
| +--ro interface? if:interface-ref
| +--ro (mip-address)?
| +--:(mac-address)
| | +--ro mac-address? yang:mac-address
| +--:(ip-address)
| +--ro ip-address? inet:ip-address
+--ro (monitor-stats)?
+--:(monitor-null)
+--ro monitor-null? empty
Snippet of Data Hierarchy Related to RPC Call Continuity-Check
4.5. Notifications
Notification is sent upon detecting a defect condition and upon
clearing a defect with a Maintenance Domain Name, MA Name, defect-
type (the currently active defects), generating-mepid, and defect-
message to indicate more details.
4.6. Monitor Statistics
Grouping for monitoring statistics is to be used by technology-
specific YANG modules that augment the generic YANG data model to
provide statistics due to proactive OAM-like Continuity Check
Messages -- for example, CCM transmit, CCM receive, CCM error, etc.
4.7. OAM Data Hierarchy
The complete data hierarchy related to the connection-oriented OAM
YANG data model is presented below.
module: ietf-connection-oriented-oam
+--rw domains
+--rw domain* [technology md-name-string]
+--rw technology identityref
+--rw md-name-string md-name-string
+--rw md-name-format? identityref
+--rw (md-name)?
| +--:(md-name-null)
| +--rw md-name-null? empty
+--rw md-level? md-level
+--rw mas
+--rw ma* [ma-name-string]
+--rw ma-name-string ma-name-string
+--rw ma-name-format? identityref
+--rw (ma-name)?
| +--:(ma-name-null)
| +--rw ma-name-null? empty
+--rw (connectivity-context)?
| +--:(context-null)
| +--rw context-null? empty
+--rw cos-id? uint8
+--rw cc-enable? boolean
+--rw mep* [mep-name]
| +--rw mep-name mep-name
| +--rw (mep-id)?
| | +--:(mep-id-int)
| | +--rw mep-id-int? int32
| +--rw mep-id-format? identityref
| +--rw (mep-address)?
| | +--:(mac-address)
| | | +--rw mac-address? yang:mac-address
| | +--:(ip-address)
| | +--rw ip-address? inet:ip-address
| +--rw cos-id? uint8
| +--rw cc-enable? boolean
| +--rw session* [session-cookie]
| +--rw session-cookie uint32
| +--rw destination-mep
| | +--rw (mep-id)?
| | | +--:(mep-id-int)
| | | +--rw mep-id-int? int32
| | +--rw mep-id-format? identityref
| +--rw destination-mep-address
| | +--rw (mep-address)?
| | +--:(mac-address)
| | | +--rw mac-address? yang:mac-address
| | +--:(ip-address)
| | +--rw ip-address? inet:ip-address
| +--rw cos-id? uint8
+--rw mip* [name] {mip}?
+--rw name string
+--rw interface? if:interface-ref
+--rw (mip-address)?
+--:(mac-address)
| +--rw mac-address? yang:mac-address
+--:(ip-address)
+--rw ip-address? inet:ip-address
rpcs:
+---x continuity-check {continuity-check}?
| +---w input
| | +---w technology? identityref
| | +---w md-name-string -> /domains/domain/md-name-string
| | +---w md-level? -> /domains/domain/md-level
| | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
| | +---w cos-id? uint8
| | +---w ttl? uint8
| | +---w sub-type? identityref
| | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name
| | +---w destination-mep
| | | +---w (mep-address)?
| | | | +--:(mac-address)
| | | | | +---w mac-address? yang:mac-address
| | | | +--:(ip-address)
| | | | +---w ip-address? inet:ip-address
| | | +---w (mep-id)?
| | | | +--:(mep-id-int)
| | | | +---w mep-id-int? int32
| | | +---w mep-id-format? identityref
| | +---w count? uint32
| | +---w cc-transmit-interval? time-interval
| | +---w packet-size? uint32
| +--ro output
| +--ro (monitor-stats)?
| +--:(monitor-null)
| +--ro monitor-null? empty
+---x continuity-verification {connectivity-verification}?
| +---w input
| | +---w md-name-string -> /domains/domain/md-name-string
| | +---w md-level? -> /domains/domain/md-level
| | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
| | +---w cos-id? uint8
| | +---w ttl? uint8
| | +---w sub-type? identityref
| | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name
| | +---w destination-mep
| | | +---w (mep-address)?
| | | | +--:(mac-address)
| | | | | +---w mac-address? yang:mac-address
| | | | +--:(ip-address)
| | | | +---w ip-address? inet:ip-address
| | | +---w (mep-id)?
| | | | +--:(mep-id-int)
| | | | +---w mep-id-int? int32
| | | +---w mep-id-format? identityref
| | +---w count? uint32
| | +---w interval? time-interval
| | +---w packet-size? uint32
| +--ro output
| +--ro (monitor-stats)?
| +--:(monitor-null)
| +--ro monitor-null? empty
+---x traceroute {traceroute}?
+---w input
| +---w md-name-string -> /domains/domain/md-name-string
| +---w md-level? -> /domains/domain/md-level
| +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
| +---w cos-id? uint8
| +---w ttl? uint8
| +---w command-sub-type? identityref
| +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name
| +---w destination-mep
| | +---w (mep-address)?
| | | +--:(mac-address)
| | | | +---w mac-address? yang:mac-address
| | | +--:(ip-address)
| | | +---w ip-address? inet:ip-address
| | +---w (mep-id)?
| | | +--:(mep-id-int)
| | | +---w mep-id-int? int32
| | +---w mep-id-format? identityref
| +---w count? uint32
| +---w interval? time-interval
+--ro output
+--ro response* [response-index]
+--ro response-index uint8
+--ro ttl? uint8
+--ro destination-mep
| +--ro (mep-address)?
| | +--:(mac-address)
| | | +--ro mac-address? yang:mac-address
| | +--:(ip-address)
| | +--ro ip-address? inet:ip-address
| +--ro (mep-id)?
| | +--:(mep-id-int)
| | +--ro mep-id-int? int32
| +--ro mep-id-format? identityref
+--ro mip {mip}?
| +--ro interface? if:interface-ref
| +--ro (mip-address)?
| +--:(mac-address)
| | +--ro mac-address? yang:mac-address
| +--:(ip-address)
| +--ro ip-address? inet:ip-address
+--ro (monitor-stats)?
+--:(monitor-null)
+--ro monitor-null? empty
notifications:
+---n defect-condition-notification
| +--ro technology? identityref
| +--ro md-name-string -> /domains/domain/md-name-string
| +--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string
| +--ro mep-name? -> /domains/domain/mas/ma/mep/mep-name
| +--ro defect-type? identityref
| +--ro generating-mepid
| | +--ro (mep-id)?
| | | +--:(mep-id-int)
| | | +--ro mep-id-int? int32
| | +--ro mep-id-format? identityref
| +--ro (defect)?
| +--:(defect-null)
| | +--ro defect-null? empty
| +--:(defect-code)
| +--ro defect-code? int32
+---n defect-cleared-notification
+--ro technology? identityref
+--ro md-name-string -> /domains/domain/md-name-string
+--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string
+--ro mep-name? -> /domains/domain/mas/ma/mep/mep-name
+--ro defect-type? identityref
+--ro generating-mepid
| +--ro (mep-id)?
| | +--:(mep-id-int)
| | +--ro mep-id-int? int32
| +--ro mep-id-format? identityref
+--ro (defect)?
+--:(defect-null)
| +--ro defect-null? empty
+--:(defect-code)
+--ro defect-code? int32
Data Hierarchy of OAM
(next page on part 2)
