Tech-invite  3GPPspecsRELsGlossariesSIPRFCs
8887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 8531

Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols

Pages: 54
Proposed Standard
Errata
Part 1 of 3 – Pages 1 to 18
None   None   Next

Top   ToC   RFC8531 - Page 1
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)
                               Protocols

Abstract

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.
Top   ToC   RFC8531 - Page 2
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.
Top   ToC   RFC8531 - Page 3

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
Top   ToC   RFC8531 - Page 4

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
Top   ToC   RFC8531 - Page 5
   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.
Top   ToC   RFC8531 - Page 6
   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]
Top   ToC   RFC8531 - Page 7

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.
Top   ToC   RFC8531 - Page 8
                            +-----------+
                            |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 Model

4. 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.
Top   ToC   RFC8531 - Page 9
   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.
Top   ToC   RFC8531 - Page 10
       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)
Top   ToC   RFC8531 - Page 11

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.
Top   ToC   RFC8531 - Page 12
   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)
Top   ToC   RFC8531 - Page 13
     |  |  |  |     +---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}?
Top   ToC   RFC8531 - Page 14
              |  +--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
Top   ToC   RFC8531 - Page 15
                 +--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
Top   ToC   RFC8531 - Page 16
     |  |  +---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}?
Top   ToC   RFC8531 - Page 17
        +---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
Top   ToC   RFC8531 - Page 18
   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)

Next Section