Network Working Group
Internet Engineering Task Force (IETF)                          D. Kumar
Internet-Draft
Request for Comments: 8531                                         Cisco
Intended status:
Category: Standards Track                                          Q. Wu
Expires: August 29, 2018
ISSN: 2070-1721                                                  M. Wang
                                                                  Huawei
                                                       February 25, 2018
                                                              March 2019

      Generic YANG Data Model for Connection Oriented Connection-Oriented Operations,
            Administration, and Maintenance(OAM) protocols
         draft-ietf-lime-yang-connection-oriented-oam-model-07 Maintenance (OAM) Protocols

Abstract

   This document presents a base YANG Data data model for connection-oriented
   Operations, Administration, and Maintenance(OAM) 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 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum 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 six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 29, 2018.
   https://www.rfc-editor.org/info/rfc8531.

Copyright Notice

   Copyright (c) 2018 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  . . . . . . . . . . . . . . . . . . . . . . . .   3   4
   2.  Conventions used Used in this document This Document . . . . . . . . . . . . . .   4   5
     2.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   6   7
   3.  Architecture of Generic YANG Data Model for connection-oriented Connection-
       Oriented OAM  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6   7
   4.  Overview of the Connection-Oriented OAM YANG Data Model . . . . .   7   8
     4.1.  Maintenance Domain (MD) configuration Configuration . . . . . . . . . .   8   9
     4.2.  Maintenance Association (MA) configuration Configuration  . . . . . . .   9  10
     4.3.  Maintenance Endpoint End Point (MEP) configuration Configuration . . . . . . . .   9  11
     4.4.  RPC definitions Definitions . . . . . . . . . . . . . . . . . . . . .  10  11
     4.5.  Notifications . . . . . . . . . . . . . . . . . . . . . .  13  14
     4.6.  Monitor statistics Statistics  . . . . . . . . . . . . . . . . . . .  13  14
     4.7.  OAM data hierarchy Data Hierarchy  . . . . . . . . . . . . . . . . . . .  13  14
   5.  OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . .  17  19
   6.  Base Mode . . . . . . . . . . . . . . . . . . . . . . . . . .  41  42
     6.1.  MEP Address . . . . . . . . . . . . . . . . . . . . . . .  41  42
     6.2.  MEP ID for Base Mode  . . . . . . . . . . . . . . . . . .  41  42
     6.3.  Maintenance Association . . . . . . . . . . . . . . . . .  41  42
   7.  Connection-oriented  Connection-Oriented OAM YANG model applicability  . . Data Model Applicability . . . .  42  43
     7.1.  Generic YANG Data Model extension Extension for TRILL OAM . . . . . . .  42  43
       7.1.1.  MD Configuration Extension  . . . . . . . . . . . . .  42  43
       7.1.2.  MA Configuration Extension  . . . . . . . . . . . . .  43  44
       7.1.3.  MEP Configuration Extension . . . . . . . . . . . . .  44  45
       7.1.4.  RPC extension Extension . . . . . . . . . . . . . . . . . . . .  44  46
     7.2.  Generic YANG Data Model extension Extension for MPLS-TP OAM . . . . . .  45  46
       7.2.1.  MD Configuration Extension  . . . . . . . . . . . . .  45  47
       7.2.2.  MA Configuration Extension  . . . . . . . . . . . . .  47  48
       7.2.3.  MEP Configuration Extension . . . . . . . . . . . . .  47  48
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  48  49
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  49  50
   10. Acknowledgments References  . . . . . . . . . . . . . . . . . . . . . . .  49
   11. . .  50
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  50
     10.2.  Informative References . . . . . . .  49
     11.1.  Normative References . . . . . . . . . .  51
   Acknowledgments . . . . . . . .  49
     11.2.  Informative References . . . . . . . . . . . . . . . . .  51
   Appendix A.  Contributors' Addresses  53
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  52  53
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  53  54

1.  Introduction

   Operations, Administration, and Maintenance (OAM) are important
   networking functions that allow operators to:

   1.  Monitor  monitor network connections (Connectivity Verification, communications (i.e., reachability verification
       and Continuity Check). Check)

   2.  Troubleshoot  troubleshoot failures (Fault (i.e., fault verification and localization). localization)

   3.  Monitor Performance

   An overview of  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 end points endpoints without prior arrangement, but control
   information is required to identify the destination (e.g., [G.800] ). [G.800]).
   The YANG Data data model for OAM protocols using connectionless
   communications is specified in
   [I-D.ietf-lime-yang-connectionless-oam].

   [IEEE802.1Q] [RFC8532] and [IEEE802.1Q].

   Connectivity Fault Management as specified in [IEEE802.1Q] is a well-established well-
   established OAM standard that is widely adopted for Ethernet
   networks.  ITU-T [G.8013], MEF Forum (MEF) Service OAM [MEF-17], MPLS-TP [RFC6371]and TRILL MPLS
   Transport Profile (MPLS-TP) [RFC6371], and Transparent
   Interconnection of Lots of Links (TRILL) [RFC7455] all define OAM
   mechanisms based on the manageability frame
   work framework of CFM 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 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
   verification, and path discovery (traceroute).  The generic YANG data
   model for connection-
   oriented connection-oriented OAM is designed to be extensible to
   other connection-
   oriented connection-oriented technologies.  Technology dependent  Technology-dependent nodes
   and remote process procedure call (RPC) commands are defined in technology technology-
   specific YANG data models, which use and extend the base model
   defined here.  As an example,
   VXLAN 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 grain label, 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 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
   models. (e.g. data models (e.g., TRILL
   RBridge may only need to implement Generic 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 issues issue a
   Continuity Check command or a Loopback or initiate a performance
   monitoring session can do so in the same manner 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 b, and c.  Let's assume a,b a, b, and c are using CFM
   [IEEE802.1Q].  A user 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 (LBM) (Loopback
   Message) and fault isolation (LTM) (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
   [I-D.ietf-netmod-revised-datastores]. [RFC8342].

2.  Conventions used Used in this document This Document

   The keywords 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
   BCP14, [RFC2119],
   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, 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]. [IEEE802.1Q]

   ECMP  - Equal Cost Multipath. Equal-Cost Multipath

   LBM   - Loopback Message [IEEE802.1Q]. [IEEE802.1Q]

   LTM   - Linktrace Message [IEEE802.1Q]. [IEEE802.1Q]

   MP    - Maintenance Point [IEEE802.1Q]. [IEEE802.1Q]

   MEP   - Maintenance End Point [RFC7174] (Maintenance (also known as Maintenance
         association End Point [IEEE802.1Q], [IEEE802.1Q] and MEG End Points [RFC6371]). Point [RFC6371])

   MIP   - Maintenance Intermediate Point [RFC7174] (Maintenance (also known as
         Maintenance domain Intermediate Point [IEEE802.1Q], [IEEE802.1Q] and MEG
         Intermediate Point
         [RFC6371]). [RFC6371])

   MA    - Maintenance Association [IEEE802.1Q] [RFC7174]. [RFC7174]

   MD    - Maintenance Domain [IEEE802.1Q]

   MEG   - Maintenance Entity Group [RFC6371]

   MTV   - Multi-destination Tree Verification Message. Message

   OAM   - Operations, Administration, and Maintenance [RFC6291]. [RFC6291]

   TRILL - Transparent Interconnection of Lots of Links [RFC6325]. [RFC6325]

   CFM   - Connectivity Fault Management [RFC7174] [IEEE802.1Q]. [IEEE802.1Q]

   RPC   - Remote Process Call. Procedure Call

   CC    - Continuity Check [RFC7276]. [RFC7276]

   CV    - Connectivity Verification [RFC7276]. [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.
      "reachability verification".

   Connectivity Verification  - Connectivity Verification is used to
      verify that a destination is connected.  It is also referred to as
      path verification
      "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  - The proactive Proactive OAM refers to OAM actions which that are carried
      out continuously to permit proactive reporting of fault.
      Proactive  A
      proactive OAM method requires persistent configuration.

   On-demand OAM  - The on-demand On-demand OAM refers to OAM actions which that are
      initiated via manual intervention for a limited time to carry out
      diagnostics.  The  An on-demand OAM method requires only transient
      configuration.

2.3.  Tree Diagrams

   Tree diagrams used in this document follow the notation defined in
   [I-D.ietf-netmod-yang-tree-diagrams].
   [RFC8340].

3.  Architecture of Generic YANG Data Model for connection-oriented Connection-Oriented OAM

   In this document 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 technology-
   specific needs.  The Generic 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 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|

                            +-----------+
                            |Connection-|
                            | Oriented  |
                            |  gen  generic  |
                            |
                            |OAM OAM YANG  |
                            +-+-+-+-+-++
                            +-+-+-+-+-+-+
                                 |
                                 |
                                 |
         +------------------------------------------+
         |                       |                  |
     +-+-+-+-+-+          +-+-+-+-+-+          +-+-+-+-+-+
     | TRILL   |          | MPLS-TP |     . . .|  foo    |
     |OAM YANG |          |OAM YANG |          |OAM YANG |
     +-+-+-+-+-+          +-+-+-+-+-+          +-+-+-+-+-+
           |                    |                  |
           |                    |              +-+-+-+-+-+
           |                    |         . . .|  foo    |
           |                    |              |sub tech |
           |                    |              +-+-+-+-+-+
           |                    |                  |
           |                    |                  |
    +-------------------------------------------------------+
    |                      Uniform API                      |
    +-------------------------------------------------------+

   Figure 1: Relationship of OAM YANG model Data Model to generic (base) Generic (Base) YANG model
                                Data Model

4.  Overview of the Connection-Oriented OAM YANG Data Model

   In this document document, we adopt the concepts of the CFM [IEEE802.1Q] model
   and structure it such that it can be adapted to different connection-
   oriented OAM protocols.

   At the top of the Model model is the Maintenance Domain.  Each Maintenance
   Domain is associated with a Maintenance Name and a Domain Level.

   Under each Maintenance Domain Domain, there is one or more Maintenance
   Associations (MA). (MAs).  In TRILL, the MA can correspond to Fine-Grained 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 technology-specific
   address identifiers.  The YANG data model presented here provides
   flexibility to accommodate different addressing schemes.

   In

   Commands are presented in the management protocol direction protocol, which is
   orthogonal to the Maintenance
   Domain, presented Domain.  These are the commands.  Those, RPC commands, in
   YANG terms, are the
   RPC commands.  These RPC commands terms.  They provide uniform APIs for continuity
   check, Continuity Check,
   connectivity verification, path discovery(traceroute) discovery (traceroute), and their equivalents
   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 Section 5.1 of [RFC7276].  In order to facilitate zero-
   touch a
   zero-touch experience, this document defines a default mode of OAM.
   The default mode of OAM is referred to as the Base Mode "Base Mode" and
   specifies default values for each of model the model's parameters, such as
   Maintenance Domain Level, Name of the Maintenance Association,
   Addresses of MEPs MEPs, and so on.  The default values of these depend on
   the technology.  Base Mode for TRILL is defined in [RFC7455].  Base mode
   Mode for other technologies and future extensions developed in IETF
   will be defined in their corresponding documents.

   It is important to note that, that no specific enhancements are needed in
   the YANG data model to support Base Mode.  Implementations that
   comply with this document, document use, by default implement default, the data nodes of the
   applicable technology.  Data nodes of the Base Mode are read-only
   nodes.

4.1.  Maintenance Domain (MD) configuration Configuration

   The container "domains" is the top level top-level container within the gen-oam "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] [IEEE802.1Q], or other
   standards
   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 Data Hierarchy Related to OAM domains Domains

4.2.  Maintenance Association (MA) configuration Configuration

   Within a given Maintenance Domain Domain, there can be one or more
   Maintenance Associations (MA(s)). (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 "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 Data Hierarchy Related to Maintenance Associations (MA) (MAs)

4.3.  Maintenance Endpoint End Point (MEP) configuration Configuration

   Within a given Maintenance Association (MA), there can be one or more
   Maintenance End Points (MEP). (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 Data Hierarchy Related to Maintenance Endpoint End Point (MEP)

4.4.  RPC definitions Definitions

   The RPC model facilitates issuing commands to a "server" (in this
   case
   case, to the device that need to execute the OAM command) and
   obtaining a response.  The RPC model defined here abstracts OAM OAM-
   specific commands in a technology independent technology-independent manner.

   There are several RPC commands defined for the purpose of OAM.  In
   this section section, we present a snippet of the continuity check Continuity Check command
   for illustration purposes.  Please refer to Section 4.5 for the
   complete data hierarchy and Section 5 for the YANG model. 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 Data Hierarchy Related to RPC call continuity-check Call Continuity-Check

4.5.  Notifications

   Notification is sent on upon detecting a defect condition and on upon
   clearing a defect with a Maintenance Domain Name, MA Name, defect-type (The defect-
   type (the currently active defects), generating-mepid, and defect-message defect-
   message to indicate more details.

4.6.  Monitor statistics Statistics

   Grouping for monitoring statistics is to be used by technology technology-
   specific YANG modules which Augment Generic that augment the generic YANG Model data model to
   provide statistics due to pro-active OAM like CCM Messages.  For example proactive OAM-like Continuity Check
   Messages -- for example, CCM
   Transmit, transmit, CCM Receive, receive, CCM Errors, error, etc.

4.7.  OAM data hierarchy 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

                           Data Hierarchy of OAM

5.  OAM YANG Module

   This module imports typedefs from [RFC6991] and [I-D.ietf-netmod-
   rfc7223bis], [RFC8343], and it
   references [RFC6371],[RFC6905], [RFC7276].

   RFC Ed.: update the date below with the date of RFC publication [RFC6371], [RFC6905], and
   remove this note. [RFC7276].

   <CODE BEGINS> file "ietf-connection-oriented-oam@2018-02-07.yang" "ietf-connection-oriented-oam@2019-03-11.yang"

module ietf-connection-oriented-oam {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam";
  prefix co-oam;

  import ietf-yang-types {
    prefix yang;
  }
  import ietf-inet-types {
    prefix inet;
  }
  import ietf-interfaces {
    prefix if;
  }

  organization
    "IETF LIME Working Group";
  contact
    "WG Web:    http://tools.ietf.org/wg/lime    http://datatracker.ietf.org/wg/lime
     WG List:   mailto:lime@ietf.org   <mailto:lime@ietf.org>
     Editor:    Deepak Kumar dekumar@cisco.com <dekumar@cisco.com>
     Editor:    Qin Wu bill.wu@huawei.com <bill.wu@huawei.com>
     Editor:    Zitao    Michael Wang wangzitao@huawei.com"; <wangzitao@huawei.com>";
  description
    "This YANG module defines the generic configuration,
     statistics and rpc RPC for connection oriented connection-oriented OAM
     to be used within IETF in a protocol independent protocol-independent manner.
     Functional level
     Functional-level abstraction is independent
     with YANG modeling. It is assumed that each protocol
     maps corresponding abstracts to its native format.
     Each protocol may extend the YANG data model defined
     here to include protocol specific protocol-specific extensions

     Copyright (c) 2018 2019 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; 8531; see
     the RFC itself for full legal notices.";

  revision 2018-02-07 2019-03-11 {
    description
      "Initial revision.";
    reference
      "RFC xxxx: 8531: Generic YANG Data Model for Connection Connection-
       Oriented OAM protocols"; Operations, Administration, and Maintenance (OAM)
       Protocols";
  }

  feature connectivity-verification {
    description
      "This feature indicates that the server supports
       executing a connectivity verification OAM command and
       returning a response.  Servers that do not advertise
       this feature will not support executing a
       connectivity verification command or rpc RPC model for a
       connectivity verification command.";
  }

  feature continuity-check {
    description
      "This feature indicates that the server supports
       executing continuity check a Continuity Check OAM command and
       returning a response.  Servers that do not advertise
       this feature will not support executing
       continuity check a
       Continuity Check command or rpc RPC model for
       continuity check a
       Continuity Check command.";
  }

  feature traceroute {
    description
      "This feature indicates that the server supports
       executing a traceroute OAM command and
       returning a response.  Servers that do not advertise
       this feature will not support executing a
       traceroute command or rpc RPC model for a
       traceroute command.";
  }

  feature mip {
    description
      "This feature indicates that the Maintenance
       Intermediate Point(MIP) Point (MIP) needs to be explicit explicitly configured";
  }

  identity technology-types {
    description
      "This is the base identity of technology types which that are
       TRILL, MPLS-TP, etc"; etc.";
  }

  identity command-sub-type {
    description
      "Defines different rpc RPC command subtypes,
       e.g rfc6905 trill OAM,
       e.g., TRILL OAM as specified in RFC 6905; this is
       optional for most cases"; cases.";
    reference
      "RFC 6905: Requirements for OAM in Transparent
       Interconnection of Lots of Links (TRILL)";
  }

  identity on-demand {
    base command-sub-type;
    description
      "On demand
      "On-demand activation - indicates that the tool is activated
       manually to detect a specific anomaly.
       On-demand
       An on-demand OAM method requires only transient configuration.";
    reference
      "RFC 7276: An Overview of Operations, Administration, and
       Maintenance (OAM) Tools";
  }

  identity proactive {
    base command-sub-type;
    description
      "Proactive activation - indicates that the tool is activated on a
       continual basis, where messages are sent periodically, and errors
       are detected when a certain number of expected messages are not
       received. Proactive  A proactive OAM method requires persistent
       configuration.";
    reference
      "RFC 7276: An Overview of Operations, Administration, and
       Maintenance (OAM) Tools";
  }

  identity name-format {
    description
      "This defines the name format, IEEE 8021ag CFM (IEEE 802.1Q) defines varying
       styles of names.  It is expected that name format as is an identity ref
       reference to be extended with new types.";
  }
  identity name-format-null {
    base name-format;
    description
      "Defines name format as null"; null.";
  }

  identity identifier-format {
    description
      "Identifier-format identity can be augmented to define other
       format identifiers used in MEP-ID etc"; MEP-ID, etc.";
  }

  identity identifier-format-integer {
    base identifier-format;
    description
      "Defines identifier-format to be integer"; integer.";
  }

  identity defect-types {
    description
      "Defines different defect types, e.g. e.g.,
       Remote Defect Indication (rdi), (RDI), loss of continuity"; continuity.";
  }

  identity rdi {
    base defect-types;
    description
      "The Remote Defect Indication (rdi) RDI indicates the
       aggregate health of the remote Maintenance End Points (MEPs).";
  }

  identity remote-mep-defect {
    base defect-types;
    description
      "Indicates that one or more of the remote
       Maintenance End Points(MEPs)is MEPs are
       reporting a failure "; failure.";
  }

  identity loss-of-continuity {
    base defect-types;
    description
      "Indicate
      "Indicates that there is are no proactive Continuity Check (CC)
       OAM packets from the source Maintenance End Point
       (MEP) MEP (and in the case of
       Connectivity
       Verification , Verification, this includes the requirement to have
       the expected unique,
       technology dependent technology-dependent source MEP identifier)
       received within the interval.";
    reference
      "RFC 6371: Operations, Administration, and Maintenance
       Framework for MPLS-Based Transport Networks";
  }

  identity cv-defect {
    base defect-types;
    description
      "This function should support monitoring between the Maintenance End Points (MEPs) MEPs
       and, in addition, between a MEP and Maintenance Intermediate
       Point (MIP). MIP.  When performing
       Connectivity Verification, the need for the Continuity Check and
       Connectivity Verification (CC-V) messages need to include
       unique identification of the MEG that is being monitored and
       the MEP that originated the message.";
    reference
      "RFC 6371: Operations, Administration, and Maintenance
       Framework for MPLS-Based Transport Networks";
  }

  identity invalid-oam-defect {
    base defect-types;
    description
      "Indicates that one or more invalid OAM messages has have been
       received and that 3.5 times that OAM message transmission
       interval has not yet expired.";
  }

  identity cross-connect-defect {
    base defect-types;
    description
      "Indicates that one or more cross-connect defect
       (for example, a service ID does not match the VLAN.) VLAN)
       messages has have been received and that 3.5 times that OAM message
       transmission interval has not yet expired.";
  }

  typedef mep-name {
    type string;
    description
      "Generic administrative name for a Maintenance End Point
       (MEP)."; MEP.";
  }

  typedef time-interval {
    type decimal64 {
      fraction-digits 2;
    }
    units "milliseconds";
    description
      "Time interval between packets in milliseconds.
       Time interval should not be less than 0.

       0 means no packets are sent.";
  }

  typedef md-name-string {
    type string;
    description
      "Generic administrative name for Maintenance Domain (MD).";
  }

  typedef ma-name-string {
    type string;
    description
      "Generic administrative name for a
       Maintenance Association (MA).";
  }

  typedef oam-counter32 {
    type yang:zero-based-counter32;
    description
      "Define 32 bit 32-bit counter for OAM.";
  }

  typedef md-level {
    type uint32 {
      range "0..255";
    }
    description
      "Maintenance Domain level. Level.  The level may be restricted in
       certain protocols (e.g., protocol in layer 0 to layer 7).";
  }

  grouping maintenance-domain-reference {
    description
      "This grouping uniquely identifies a maintenance domain."; Maintenance Domain.";
    leaf maintenance-domain {
      type leafref {
        path "/co-oam:domains/co-oam:domain/co-oam:md-name-string";
      }
      description
        "A reference to a specific Maintenance Domain.";
    }
  }

  grouping maintenance-association-reference {
    description
      "This grouping uniquely identifies a
       maintenance association.
       Maintenance Association.  It consists
       of a maintence-domain-reference maintenance-domain-reference and
       a maintenance-association leafref"; leafref.";
    uses maintenance-domain-reference;
    leaf maintenance-association {
      type leafref {
        path "/co-oam:domains/co-oam:domain[co-oam:md-name-string "
        +"=
           + "= current()/../maintenance-domain]/co-oam:mas"
        +"/co-oam:ma/co-oam:ma-name-string";
           + "/co-oam:ma/co-oam:ma-name-string";
      }
      description
        "A reference to a specific Maintenance Association.";
    }
  }

  grouping maintenance-association-end-point-reference {
    description
      "This grouping uniquely identifies
       a maintenance association. Maintenance Association.  It consists
       of a maintence-association-reference maintenance-association-reference and
       a maintenance-association-end-point leafref"; leafref.";
    uses maintenance-association-reference;
    leaf maintenance-association-end-point {
      type leafref {
        path "/co-oam:domains/co-oam:domain[co-oam:md-name-string "
        +"=
           + "= current()/../maintenance-domain]/co-oam:mas"
        +"/co-oam:ma[co-oam:ma-name-string
           + "/co-oam:ma[co-oam:ma-name-string = "
        +"current()/../maintenance-association]"
        +"/co-oam:mep/co-oam:mep-name";
           + "current()/../maintenance-association]"
           + "/co-oam:mep/co-oam:mep-name";
      }
      description
        "A reference to a specific Maintenance
         association End Point.";
    }
  }

  grouping time-to-live {
    leaf ttl {
      type uint8;
      description
        "Time to Live.";
    }
    description
      "Time to Live grouping.";
  }

  grouping defect-message {
    choice defect {
      case defect-null {
        description
          "This is a placeholder when no defect status is needed"; needed.";
        leaf defect-null {
          type empty;
          description
            "There is no defect to be defined, defined; it will be defined in
             technology specific
             a technology-specific model.";
        }
      }
      case defect-code {
        description
          "This is a placeholder to display defect code.";
        leaf defect-code {
          type int32;
          description
            "Defect code is integer value specific to a technology.";
        }
      }
      description
        "Defect Message choices.";
    }
    description
      "Defect Message.";
  }

  grouping mep-address {
    choice mep-address {
      default ip-address; "ip-address";
      case mac-address {
        leaf mac-address {
          type yang:mac-address;
          description
            "MAC Address.";
        }
        description
          "MAC Address based Maintenance End Point (MEP) MEP Addressing.";
      }
      case ip-address {
        leaf ip-address {
          type inet:ip-address;
          description
            "IP Address.";
        }
        description
          "IP Address based Maintenance End Point(MEP) MEP Addressing.";
      }
      description
        "Maintenance End Point (MEP)
        "MEP Addressing.";
    }
    description
      "Grouping for Maintenance End Point(MEP) MEP Address";
  }

  grouping mip-address {
    choice mip-address {
      default ip-address; "ip-address";
      case mac-address {
        leaf mac-address {
          type yang:mac-address;
          description
            "MAC Address of Maintenance Intermediate Point";
        }
        description
          "MAC Address based Maintenance Intermediate
           Point (MIP) MIP Addressing.";
      }
      case ip-address {
        leaf ip-address {
          type inet:ip-address;
          description
            "IP Address.";
        }
        description
          "IP Address based Maintenance Intermediate Point(MIP) MIP Addressing.";
      }
      description
        "Maintenance Intermediate Point (MIP)
        "MIP Addressing.";
    }
    description
      "Maintenance Intermediate Point (MIP)
      "MIP Address.";
  }

  grouping maintenance-domain-id {
    description
      "Grouping containing leaves sufficient to identify
       a Maintenance Domain.";
    leaf technology {
      type identityref {
        base technology-types;
      }
      mandatory true;
      description
        "Defines the technology.";
    }
    leaf md-name-string {
      type md-name-string;
      mandatory true;
      description
        "Defines the generic administrative maintenance domain Maintenance Domain name.";
    }
  }

  grouping md-name {
    leaf md-name-format {
      type identityref {
        base name-format;
      }
      description
        "Maintenance Domain Name format.";
    }
    choice md-name {
      case md-name-null {
        leaf md-name-null {
          when "derived-from-or-self(../md-name-format,"
          +"'name-format-null')"
             + "'name-format-null')" {
            description
              "Maintenance Domain (MD)
              "MD name format is equal to null format.";
          }
          type empty;
          description
            "Maintenance Domain (MD)
            "MD name Null."; null.";
        }
      }
      description
        "Maintenance Domain (MD)
        "MD name.";
    }
    description
      "Maintenance Domain (MD)
      "MD name.";
  }

  grouping ma-identifier {
    description
      "Grouping containing leaves sufficient to identify an Maintenance Association (MA)."; MA.";
    leaf ma-name-string {
      type ma-name-string;
      description
        "Maintenance Association (MA)
        "MA name string.";
    }
  }

  grouping ma-name {
    description
      "Maintenance Association (MA)
      "MA name.";
    leaf ma-name-format {
      type identityref {
        base name-format;
      }
      description
        "Maintenance Association (MA)
        "MA name format.";
    }
    choice ma-name {
      case ma-name-null {
        leaf ma-name-null {
          when "derived-from-or-self(../ma-name-format, "
          +"'name-format-null')"
             + "'name-format-null')" {
            description
              "Maintenance Association (MA).";
              "MA.";
          }
          type empty;
          description
            "Empty";
        }
      }
      description
        "Maintenance Association) name(MA).";
        "MA name.";
    }
  }

  grouping mep-id {
    choice mep-id {
      default "mep-id-int";
      case mep-id-int {
        leaf mep-id-int {
          type int32;
          description
            "Maintenance End Point (MEP)
            "MEP ID
             in integer format.";
        }
      }
      description
        "Maintenance End Point (MEP)
        "MEP ID.";
    }
    leaf mep-id-format {
      type identityref {
        base identifier-format;
      }
      description
        "Maintenance End Point (MEP)
        "MEP ID format.";
    }
    description
      "Maintenance End Point (MEP)
      "MEP ID.";
  }

  grouping mep {
    description
      "Defines elements within the
       Maintenance End Point (MEP)."; MEP.";
    leaf mep-name {
      type mep-name;
      mandatory true;
      description
        "Generic administrative name of the
         Maintenance End Point (MEP).";
         MEP.";
    }
    uses mep-id;
    uses mep-address;
  }

  grouping monitor-stats {
    description
      "grouping
      "Grouping for monitoring statistics, statistics; this will be augmented
       by others who use this component"; component.";
    choice monitor-stats {
      default "monitor-null";
      case monitor-null {
        description
          "This is a place holder placeholder when
           no monitoring statistics is needed"; are needed.";
        leaf monitor-null {
          type empty;
          description
            "There is are no monitoring statistics to be defined.";
        }
      }
      description
        "Define the monitor stats.";
    }
  }

  grouping connectivity-context {
    description
      "Grouping defining the connectivity context for an
       Maintenance Association (MA), MA,
       for example, an LSP for MPLS-TP.  This will be
       augmented by each protocol who use that uses this component.";
    choice connectivity-context {
      default "context-null";
      case context-null {
        description
          "This is a place holder placeholder when no context is needed.";
        leaf context-null {
          type empty;
          description
            "There is no context to be defined.";
        }
      }
      description
        "Connectivity context.";
    }
  }

  grouping cos {
    description
      "Grouping for Priority used in transmitted packets,
       for example, in the CoS field in MPLS-TP.";
    leaf cos-id {
      type uint8;
      description
        "Class of Service(CoS) id, Service (CoS) ID; this value is used to indicate
         Class of Service information .";
    }
  }

  grouping mip-grouping {
    uses mip-address;
    description
      "Grouping for Maintenance Intermediate Point(MIP) MIP
       configuration.";
  }

  container domains {
    description
      "Contains configuration related data.  Within the
       container
       container, there is a list of fault domains. each
       domian  Each
       domain has a List list of Maintenance Association
       (MA)."; MAs.";
    list domain {
      key "technology md-name-string";
      description
        "Define a list of Domains within the
         ietf-connection-oriented-oam module.";
      uses maintenance-domain-id;
      uses md-name;
      leaf md-level {
        type md-level;
        description
          "Define the MD-Level."; MD level.";
      }
      container mas {
        description
          "This container defines Maintenance Association (MA),
           within that have multiple MA and within
          "Contains configuration-related data.  Within the
           container, there is a list of MAs.  Each MA have
           Maintenance End Point (MEP)."; has a
           list of MEPs.";
        list ma {
          key "ma-name-string";
          uses ma-identifier;
          uses ma-name;
          uses connectivity-context;
          uses cos {
            description
              "Default class of service for this
               Maintenance Association (MA),
               which MA;
               it may be overridden for particular
               Maintenance End Points (MEPs),
               sessions MEPs,
               sessions, or operations.";
          }
          leaf cc-enable {
            type boolean;
            description
              "Indicate whether the
               Continuity Check (CC) CC is enabled.";
          }
          list mep {
            key "mep-name";
            description
              "Contain a list of Maintenance End Points (MEPs)"; MEPs.";
            uses mep;
            uses cos;
            leaf cc-enable {
              type boolean;
              description
                "Indicate whether the Continuity Check (CC)is CC is enabled.";
            }
            list session {
              key "session-cookie";
              description
                "Monitoring session to/from a particular remote Maintenance End Point (MEP). MEP.
                 Depending on the protocol, this could represent
                 Continuity Check (CC)
                 CC messages received from a single remote MEP (if the
                 protocol uses multicast CCs) or a target to which
                 unicast echo request CCs are sent and from which
                 responses are received (if the protocol uses a
                 unicast request/response mechanism).";
              leaf session-cookie {
                type uint32;
                description
                  "Cookie to identify different sessions, when there
                   are multiple remote Maintenance End Point(MEP) MEPs or multiple sessions tothe to
                   the same remote MEP.";
              }
              container destination-mep {
                uses mep-id;
                description
                  "Destination Maintenance End Point(MEP)."; MEP.";
              }
              container destination-mep-address {
                uses mep-address;
                description
                  "Destination Maintenance End Point (MEP) MEP Address.";
              }
              uses cos;
            }
          }
          list mip {
            if-feature "mip";
            key "name";
            leaf name {
              type string;
              description
                "Identifier of Maintenance intermediate point"; Intermediate Point";
            }
            leaf interface {
              type if:interface-ref;
              description
                "Interface";
                "Interface.";
            }
            uses mip-grouping;
            description
              "List for Maintenance Intermediate Point (MIP)."; MIP.";
          }
          description
            "Maintenance Association list.";
        }
      }
    }
  }

  notification defect-condition-notification {
    description
      "Upon
      "When the defect condition is met, this notification is sent"; sent.";
    leaf technology {
      type identityref {
        base technology-types;
      }
      description
        "The technology"; technology.";
    }
    leaf md-name-string {
      type leafref {
        path "/domains/domain/md-name-string";
      }
      mandatory true;
      description
        "Indicate which Maintenance Domain(MD)
         does MD the defect belong belongs to.";
    }
    leaf ma-name-string {
      type leafref {
        path "/domains/domain/mas/ma/ma-name-string";
      }
      mandatory true;
      description
        "Indicate which Maintenance Association (MA)
         is MA the defect is associated with.";
    }
    leaf mep-name {
      type leafref {
        path "/domains/domain/mas/ma/mep/mep-name";
      }
      description
        "Indicate which Maintenance End Point(MEP) MEP is seeing the defect.";
    }
    leaf defect-type {
      type identityref {
        base defect-types;
      }
      description
        "The currently active defects on the specific
         Maintenance End Point (MEP)."; MEP.";
    }
    container generating-mepid {
      uses mep-id;
      description
        "Indicate who is generating the defect (if known). If
         unknown
         unknown, set it as to 0.";
    }
    uses defect-message {
      description
        "The defect
        "Defect message to indicate provide more details.";
    }
  }

  notification defect-cleared-notification {
    description
      "Upon
      "When the defect cleared is met, cleared, this notification is sent"; sent.";
    leaf technology {
      type identityref {
        base technology-types;
      }
      description
        "The technology.";
    }
    leaf md-name-string {
      type leafref {
        path "/domains/domain/md-name-string";
      }
      mandatory true;
      description
        "Indicate which Maintenance Domain (MD)
         does MD the defect belong belongs to";
    }
    leaf ma-name-string {
      type leafref {
        path "/domains/domain/mas/ma/ma-name-string";
      }
      mandatory true;
      description
        "Indicate which Maintenance Association (MA)
         is MA the defect is associated with.";
    }
    leaf mep-name {
      type leafref {
        path "/domains/domain/mas/ma/mep/mep-name";
      }
      description
        "Indicate which Maintenance End Point (MEP) MEP is seeing the defect.";
    }
    leaf defect-type {
      type identityref {
        base defect-types;
      }
      description
        "The currently active defects on the specific Maintenance End Point (MEP)."; MEP.";
    }
    container generating-mepid {
      uses mep-id;
      description
        "Indicate who is generating the defect (if known). if
         unknown If
         unknown, set it as to 0.";
    }
    uses defect-message {
      description
        "Defect message to indicate provide more details.";
    }
  }

  rpc continuity-check {
    if-feature "continuity-check";
    description
      "Generates continuity-check Continuity Check as per RFC7276 Table 4."; 4 of RFC 7276.";
    input {
      leaf technology {
        type identityref {
          base technology-types;
        }
        description
          "The technology"; technology.";
      }
      leaf md-name-string {
        type leafref {
          path "/domains/domain/md-name-string";
        }
        mandatory true;
        description
          "Indicate which Maintenance Domain (MD)
           does MD the defect belong belongs to.";
      }
      leaf md-level {
        type leafref {
          path "/domains/domain/md-level";
        }
        description
          "The maintenance domain level."; Maintenance Domain Level.";
      }
      leaf ma-name-string {
        type leafref {
          path "/domains/domain/mas/ma/ma-name-string";
        }
        mandatory true;
        description
          "Indicate which MA is the defect is associated with"; with.";
      }
      uses cos;
      uses time-to-live;
      leaf sub-type {
        type identityref {
          base command-sub-type;
        }
        description
          "Defines different command types.";
      }
      leaf source-mep {
        type leafref {
          path "/domains/domain/mas/ma/mep/mep-name";
        }
        description
          "Source Maintenance End Point (MEP)."; MEP.";
      }
      container destination-mep {
        uses mep-address;
        uses mep-id {
          description
            "Only applicable if the destination is a Maintenance End Point (MEP)."; MEP.";
        }
        description
          "Destination Maintenance End Point (MEP)."; MEP.";
      }
      leaf count {
        type uint32;
        default "3";
        description
          "Number of continuity-check message messages to be sent.";
      }
      leaf cc-transmit-interval {
        type time-interval;
        description
          "Time interval between echo requests.";
      }
      leaf packet-size {
        type uint32 {
          range "64..10000";
        }
        description
          "Size of continuity-check packets, in octets.";
      }
    }
    output {
      uses monitor-stats {
        description
          "Stats of continuity check."; Continuity Check.";
      }
    }
  }

  rpc continuity-verification {
    if-feature "connectivity-verification";
    description
      "Generates continuity-verification Connectivity Verification as per RFC7276 Table 4."; 4 in RFC 7276.";
    input {
      leaf md-name-string {
        type leafref {
          path "/domains/domain/md-name-string";
        }
        mandatory true;
        description
          "Indicate which MD (Maintenance Domain)
           does the defect belong belongs to.";
      }
      leaf md-level {
        type leafref {
          path "/domains/domain/md-level";
        }
        description
          "The maintenance domain level."; Maintenance Domain Level.";
      }
      leaf ma-name-string {
        type leafref {
          path "/domains/domain/mas/ma/ma-name-string";
        }
        mandatory true;
        description
          "Indicate which Maintenance Association (MA)
           is MA the defect is associated with.";
      }
      uses cos;
      uses time-to-live;
      leaf sub-type {
        type identityref {
          base command-sub-type;
        }
        description
          "Defines different command types.";
      }
      leaf source-mep {
        type leafref {
          path "/domains/domain/mas/ma/mep/mep-name";
        }
        description
          "Source Maintenance End Point(MEP)."; MEP.";
      }
      container destination-mep {
        uses mep-address;
        uses mep-id {
          description
            "Only applicable if the destination is a Maintenance End Point (MEP)."; MEP.";
        }
        description
          "Destination Maintenance End Point(MEP)."; MEP.";
      }
      leaf count {
        type uint32;
        default "3";
        description
          "Number of continuity-verification message messages to be sent.";
      }
      leaf interval {
        type time-interval;
        description
          "Time interval between echo requests.";
      }
      leaf packet-size {
        type uint32 {
          range "64..10000";
        }
        description
          "Size of continuity-verification packets, in octets"; octets.";
      }
    }
    output {
      uses monitor-stats {
        description
          "Stats of continuity check."; Continuity Check.";
      }
    }
  }

  rpc traceroute {
    if-feature "traceroute";
    description
      "Generates Traceroute or Path Trace and return returns response.
       Referencing RFC7276
       References RFC 7276 for common Toolset name, name -- for
       MPLS-TP OAM, it's Route Tracing, and for TRILL OAM, it's
       Path Tracing tool.  Starts with TTL of one and increment increments
       by one at each hop. Untill hop until the destination is reached or TTL
       reach
       reaches max value.";
    input {
      leaf md-name-string {
        type leafref {
          path "/domains/domain/md-name-string";
        }
        mandatory true;
        description
          "Indicate which Maintenance Domain (MD)
           does MD the defect belong belongs to.";
      }
      leaf md-level {
        type leafref {
          path "/domains/domain/md-level";
        }
        description
          "The maintenance domain level."; Maintenance Domain Level.";
      }
      leaf ma-name-string {
        type leafref {
          path "/domains/domain/mas/ma/ma-name-string";
        }
        mandatory true;
        description
          "Indicate which Maintenance Association (MA)
           is MA the defect is associated with.";
      }
      uses cos;
      uses time-to-live;
      leaf command-sub-type {
        type identityref {
          base command-sub-type;
        }
        description
          "Defines different command types.";
      }
      leaf source-mep {
        type leafref {
          path "/domains/domain/mas/ma/mep/mep-name";
        }
        description
          "Source Maintenance End Point (MEP)."; MEP.";
      }
      container destination-mep {
        uses mep-address;
        uses mep-id {
          description
            "Only applicable if the destination is a
             Maintenance End Point (MEP)."; MEP.";
        }
        description
          "Destination Maintenance End Point (MEP)."; MEP.";
      }
      leaf count {
        type uint32;
        default "1";
        description
          "Number of traceroute probes to send.  In protocols where a
           separate message is sent at each TTL, this is the number
           of packets to be sent at each TTL.";
      }
      leaf interval {
        type time-interval;
        description
          "Time interval between echo requests.";
      }
    }
    output {
      list response {
        key "response-index";
        leaf response-index {
          type uint8;
          description
            "Arbitrary index for the response.  In protocols that
             guarantee there is only a single response at each TTL,
             the TTL can be used as the response index.";
        }
        uses time-to-live;
        container destination-mep {
          description
            "Maintenance End Point (MEP)
            "MEP from which the response has been received";
          uses mep-address;
          uses mep-id {
            description
              "Only applicable if the destination is a
               Maintenance End Point (MEP)."; MEP.";
          }
        }
        container mip {
          if-feature "mip";
          leaf interface {
            type if:interface-ref;
            description
              "Maintenance Intermediate Point (MIP)
              "MIP interface.";
          }
          uses mip-address;
          description
            "Maintenance Intermediate Point (MIP)
            "MIP responding with traceroute";
        }
        uses monitor-stats {
          description
            "Stats of traceroute.";
        }
        description
          "List of response."; responses.";
      }
    }
  }
}

   <CODE ENDS>

6.  Base Mode

   The Base Mode ('default mode' ("default mode" described in section Section 4) defines the
   default configuration that MUST be present in the devices that comply
   with this document.  Base Mode allows users to have a "zero-touch"
   experience.  Several parameters require technology specific technology-specific
   definition.

6.1.  MEP Address

   In the Base Mode of operation, the MEP Address is by default the IP
   address of the interface on which the MEP is located.

6.2.  MEP ID for Base Mode

   In the Base Mode of operation, each device creates a single MEP
   associated with a virtual OAM port with no physical layer (NULL PHY).
   The MEP-ID associated with this MEP is zero (0).  The choice of MEP-
   ID of zero is explained below.

   MEP-ID is 2 octet a 2-octet field by default.  It is never used on the wire
   except when using CCM.  It is important to have a method that can
   derive the MEP-ID of base mode Base Mode in an automatic manner with no user
   intervention.  The IP address cannot be directly used for this purpose
   purpose, as the MEP-ID is a much smaller field.  For the Base Mode of operation
   operation, MEP-ID
   zero (0) is set as the default MEP-ID. to zero by default.

   The CCM packet use uses the MEP-ID on in the payload.  CCM MUST NOT be used
   in the Base Mode.  Hence  Hence, CCM MUST be disabled on the Maintenance
   Association of the Base Mode.

   If CCM is required, users MUST configure a separate Maintenance
   association
   Association and assign unique value values for the corresponding MEP IDs.

   CFM [IEEE802.1Q] defines MEP ID MEP-ID as an unsigned integer in the range 1
   to 8191.  In this document document, we propose extend extending the range to 0 to
   65535.  Value 0 is reserved for the MEP-ID of in the Base Mode operation
   and MUST NOT be used for other purposes.

6.3.  Maintenance Association

   The ID of the Maintenance Association (MA-ID) [IEEE802.1Q] has a
   flexible format and includes two parts: Maintenance Domain Name and
   Short MA name.  In the Base Mode of operation, the value of the
   Maintenance Domain Name must be the character string
   "GenericBaseMode" (excluding the quotes "). quotes).  In the Base Mode
   operation, the Short MA Name format is set to a 2-octet integer
   format (value 3 in Short MA Format field [IEEE802.1Q]) and the Short
   MA name is set to 65532 (0xFFFC).

7.  Connection-oriented  Connection-Oriented OAM YANG model applicability Data Model Applicability

   The "ietf-connection-oriented-oam" model module defined in this document
   provides a technology-independent abstraction of key OAM constructs
   for connection-oriented protocols.  This model module can be further
   extended to include technology specific technology-specific details, e.g., adding new
   data nodes with
   technology specific technology-specific functions and parameters into
   proper anchor points of the base model, so as to develop a
   technology-specific connection-oriented OAM model.

   This section demonstrates the usability of the connection-oriented
   YANG OAM data model to various connection-oriented OAM technologies,
   e.g., TRILL and MPLS-TP.  Note that, in this section, we only present
   several snippets of technology-specific model extensions for
   illustrative purposes.  The complete model extensions should be
   worked on in respective protocol working groups.

7.1.  Generic YANG Data Model extension Extension for TRILL OAM

   The TRILL OAM YANG module (I-D.trill-yang-oam) [TRILL-YANG-OAM] is augmenting the
   connection-oriented OAM module for both configuration and RPC
   commands.

   In addition,the TRILL OAM YANG module also requires the base TRILL
   module ([I-D.ietf-trill-yang]) ([TRILL-YANG]) to be supported supported, as there is a strong
   relationship between those modules.

   The configuration extensions for connection-oriented OAM include the
   MD configuration extension, Technology technology type extension, MA
   configuration extension, Connectivity-Context Extension, extension, MEP
   Configuration
   Extension, extension, and ECMP extension.  In the RPC extension,
   the continuity-
   check continuity-check and path-discovery RPC are extended with TRILL TRILL-
   specific parameters.

7.1.1.  MD Configuration Extension

   MD level configuration parameters are management information which that can
   be inherited in the TRILL OAM model and set by the connection-
   oriented base model as default values.  For example example, domain name can
   be set to area-ID in the TRILL OAM case.  In addition, at the
   Maintenance Domain level Level (i.e., at root level), the domain data node
   can be augmented with technology type.

   Note that MD level configuration parameters provides provide context
   information for the management system to correlate faults, defects,
   and network failures with location information, which information; this helps quickly
   identify root causes of network failures.

7.1.1.1.  Technology Type Extension

   No TRILL technology type has been defined in the connection-oriented
   base model.  Therefore  Therefore, a technology type extension is required in
   the TRILL OAM model.  The technology type "trill" is defined as an
   identity that augments the base "technology-types" defined in the
   connection-oriented base model:

      identity trill{
       base co-oam:technology-types;
       description
        "trill type";
      }

7.1.2.  MA Configuration Extension

   MA level configuration parameters are management information which that can
   be inherited in the TRILL OAM model and set by the connection-
   oriented base model as default values.  In addition, at the
   Maintenance Association(MA) Association (MA) level (i.e.,at (i.e., at the second level), the
   MA data node can be augmented with a connectivity-context extension.

   Note that MA level configuration parameters provides provide context
   information for the management system to correlate faults, defects,
   and network failures with location information, which information; this helps quickly
   identify root causes of network failures.

7.1.2.1.  Connectivity-Context Extension

   In TRILL OAM, one example of connectivity-context is either a 12 bit 12-bit
   VLAN ID or a 24 bit Fine Grain 24-bit Fine-Grained Label.  The connection-oriented base
   model defines a placeholder for context-id.  This allows other
   technologies to easily augment that to include technology specific technology-specific
   extensions.  The snippet below depicts an example of augmenting
   connectivity-context to include either a VLAN ID or Fine Grain Fine-Grained
   Label.

      augment /co-oam:domains/co-oam:domain
   /co-oam:mas/co-oam:ma/co-oam:connectivity-context:
            +--:(connectivity-context-vlan)
            |  +--rw connectivity-context-vlan?   vlan
            +--:(connectivity-context-fgl)
               +--rw connectivity-context-fgl?    fgl

7.1.3.  MEP Configuration Extension

   The MEP configuration definition in the connection-oriented base
   model already supports configuring the interface of MEP with either a
   MAC address or IP address.  In addition, the MEP address can be
   represented using a 2 octet 2-octet RBridge Nickname in TRILL OAM . OAM.  Hence,
   the TRILL OAM model augments the MEP configuration in the base model
   to add a nickname case into to the MEP address choice node as follows:

   augment /co-oam:domains/co-oam:domain
   /co-oam:mas/co-oam:ma/co-oam:mep/co-oam:mep-address:
            +--:( mep-address-trill)
            |  +--rw mep-address-trill?  tril-rb-nickname

   In addition, at the Maintenance Association Endpoint(MEP) association End Point (MEP) level
   (i.e.,at
   (i.e., at the third level), the MEP data node can be augmented with
   an ECMP extension.

7.1.3.1.  ECMP Extension

   Since TRILL supports ECMP path selection, flow-entropy in TRILL is
   defined as a 96 octet 96-octet field in the LIME Layer-Independent OAM Management
   in the Multi-Layer Environment (LIME) model extension for TRILL OAM.
   The snippet below illustrates its extension.

      augment /co-oam:domains/co-oam:domain
   /co-oam:mas/co-oam:ma/co-oam:mep:
               +--rw flow-entropy-trill?   flow-entropy-trill
      augment /co-oam:domains/co-oam:domain
   /co-oam:mas/co-oam:ma/co-oam:mep/co-oam:session:
               +--rw flow-entropy-trill?   flow-entropy-trill

7.1.4.  RPC extension Extension

   In the TRILL OAM YANG data model, the continuity-check and path-discovery path-
   discovery RPC commands are extended with TRILL specific TRILL-specific requirements.
   The snippet below depicts an example of illustrates the TRILL OAM RPC extension.

      augment /co-oam:continuity-check/co-oam:input:
            +--ro (out-of-band)?
            |  +--:(ipv4-address)
            |  |  +--ro ipv4-address?      inet:ipv4-address
            |  +--:(ipv6-address)
            |  |  +--ro ipv6-address?      inet:ipv6-address
            |  +--:(trill-nickname)
            |     +--ro trill-nickname?    tril-rb-nickname
            +--ro diagnostic-vlan?   boolean
      augment /co-oam:continuity-check/co-oam:input:
               +--ro flow-entropy-trill?   flow-entropy-trill
      augment /co-oam:continuity-check/co-oam:output:
            +--ro upstream-rbridge?   tril-rb-nickname
            +--ro next-hop-rbridge*   tril-rb-nickname
      augment /co-oam:path-discovery/co-oam:input:
            +--ro (out-of-band)?
            |  +--:(ipv4-address)
            |  |  +--ro ipv4-address?      inet:ipv4-address
            |  +--:(ipv6-address)
            |  |  +--ro ipv6-address?      inet:ipv6-address
            |  +--:(trill-nickname)
            |     +--ro trill-nickname?    tril-rb-nickname
            +--ro diagnostic-vlan?   boolean
      augment /co-oam:path-discovery/co-oam:input:
               +--ro flow-entropy-trill?   flow-entropy-trill
      augment /co-oam:path-discovery/co-oam:output/co-oam:response:
            +--ro upstream-rbridge?   tril-rb-nickname
            +--ro next-hop-rbridge*   tril-rb-nickname

7.2.  Generic YANG Data Model extension Extension for MPLS-TP OAM

   The MPLS-TP OAM YANG module can augment the connection-oriented OAM
   Module
   module with some technology-specific details.  And the
   [mpls-tp-oam-yang]  [MPLS-TP-OAM-YANG]
   presents the YANG Data data model for MPLS-TP OAM.

   The configuration extensions for connection-oriented OAM include the
   MD configuration extension, Technology type extension, Sub Technology
   Type Extension,
   Subtype extension, MA configuration extension, and MEP Configuration
   Extension.
   extension.

7.2.1.  MD Configuration Extension

   MD level configuration parameters are management information which that can
   be inherited in the MPLS-TP OAM model and set by the connection-
   oriented OAM base model as default values.  For example example, domain name
   can be set to area-ID or the provider's Autonomous System Number(ASN) Number
   (ASN) [RFC6370] in the MPLS-TP OAM case.  In addition, at the
   Maintenance Domain level (i.e.,at Level (i.e., at root level), the domain data node
   can be augmented with technology type and sub-technology type. technology subtype.

   Note that MD level configuration parameters provides provide context
   information for the management system to correlate faults, defects,
   and network failures with location information, which information; this helps quickly
   identify root causes of network failures

7.2.1.1.  Technology Type Extension

   No MPLS-TP technology type has been defined in the connection-
   oriented base model, hence it is required in the MPLS-TP OAM model.
   The technology type "mpls-tp" is defined as an identity that augments
   the base "technology-types" defined in the connection-oriented base
   model:

       identity mpls-tp{
             base co-oam:technology-types;
             description
              "mpls-tp type";
            }

7.2.1.2.  Sub  Technology Type Subtype Extension

   In MPLS-TP, since different encapsulation types such as IP/UDP
   Encapsulation,
   encapsulation and PW-ACH encapsulation can be employed, the "technology-
   sub-type"
   "technology-sub-type" data node is defined and added into the MPLS-TP
   OAM model to further identify the encapsulation types within the
   MPLS-TP OAM model.  Based on it, we also define a technology sub-type subtype
   for IP/UDP encapsulation and PW-ACH encapsulation.  Other Encapsulation
   encapsulation types can be defined in the same way.  The snippet
   below depicts an example of several encapsulation types.

   identity technology-sub-type {
         description
         "certain
         "Certain implementations can have different
          encapsulation types such as ip/udp, pw-ach IP/UDP, PW-ACH, and so on.
          Instead of defining separate models for each
          encapsulation, we define a technology sub-type subtype to
          further identify different encapsulations.
          Technology sub-type subtype is associated at the MA level"; level."; }

              identity technology-sub-type-udp {
                base technology-sub-type;
                description
                  "technology sub-type
                  "Technology subtype is IP/UDP encapsulation"; encapsulation.";
              }

              identity technology-sub-type-ach {
                base technology-sub-type;
                description
                  "technology sub-type
                  "Technology subtype is PW-ACH encapsulation"; encapsulation.";
              }
              }

         augment "/co-oam:domains/co-oam:domain"
               +"/co-oam:mas/co-oam:ma
               +"/co-oam:mas/co-oam:ma" {
                leaf technology-sub-type {
                  type identityref {
                    base technology-sub-type;
                  }
                }
              }

7.2.2.  MA Configuration Extension

   MA level configuration parameters are management information which that can
   be inherited in the MPLS-TP OAM model and set by the connection-
   oriented OAM base model as default values.  One example  Examples of MA Name
   could be MEG are
   MPLS-TP LSP ID or MEG_ID, MEG Section ID ID, or MEG PW ID[RFC6370].

   Note ID [RFC6370].

   Note that MA level configuration parameters provides provide context
   information for the management system to correlate faults, defects,
   and network failures with location information, which information; this helps quickly
   identify root causes of network failures.

7.2.3.  MEP Configuration Extension

   In MPLS-TP, MEP-ID is either a variable length variable-length label value in case of
   G-ACH encapsulation or a 2 octet 2-octet unsigned integer value in case of
   IP/UDP encapsulation.  One example of MEP-ID is MPLS-TP LSP_MEP_ID
   [RFC6370].  In the connection-oriented base model, MEP-ID is defined
   as a choice/case node which that can supports support an int32 value, and the same
   definition can be used for MPLS-TP with no further modification.  In
   addition, at the Maintenance Association Endpoint(MEP) association End Point (MEP) level (i.e.,at (i.e.,
   at the third level), the MEP data node can be augmented with Session a
   session extension and interface extension.

8.  Security Considerations

   The YANG module specified in this document defines a schema for data
   that is designed to be accessed via network management protocols such
   as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   [RFC5246].
   [RFC8446].

   The NETCONF access control model [RFC6536] Network Configuration Access Control Model [RFC8341] provides the
   means to restrict access for particular NETCONF or RESTCONF users to
   a preconfigured subset of all available NETCONF or RESTCONF protocol
   operations and content.

   There are a number of data nodes defined in the YANG module which that are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive in some
   network environments.  Write operations (e.g., <edit-config>) edit-config) to these
   data nodes without proper protection can have a negative effect on
   network operations.  These are the subtrees and data nodes and their
   sensitivity/vulnerability:

   /co-oam:domains/co-oam:domain/

   /co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma

   /co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep

   /co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep/
   co-oam:session

   Unauthorized access to any of these lists can adversely affect OAM
   management system handling of end-to-end OAM and coordination of OAM
   within underlying network layers layers.  This may lead to inconsistent
   configuration, reporting, and presentation for the OAM mechanisms
   used to manage the network.

9.  IANA Considerations

   This document registers a URI in the IETF "IETF XML registry Registry" [RFC3688].
   Following the format in RFC 3688, the
   The following registration is
   requested to be has been made:

     URI: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam
     Registrant Contact: The IESG.
     XML: N/A, N/A; the requested URI is an XML namespace.

   This document registers a YANG module in the YANG "YANG Module Names Names"
   registry [RFC6020].

  name:         ietf-connection-oriented-oam
  namespace:    urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam
  prefix:       co-oam
  reference:    RFC XXXX 8531

10.  Acknowledgments

   Giles Heron came up with the idea of developing a YANG model as a way
   of creating a unified OAM API set (interface), work in this document
   is largely an inspiration of that.  Alexander Clemm provided many
   valuable tips, comments and remarks that helped to refine the YANG
   model presented in this document.

   Carlos Pignataro, David Ball,Mahesh Jethanandani,Benoit
   Claise,Ladislav Lhotka,GUBALLA JENS,Yuji Tochio,Gregory Mirsky, Huub
   van Helvoort, Tom Taylor, Dapeng Liu,Mishael Wexler, Adi Molkho
   participated and contributed to this document.

11.  References

11.1.

10.1.  Normative References

   [IEEE802.1Q]
              "Connectivity Fault Management",
              IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks-Bridges and Bridged Networks", IEEE Std 802.1Q-2014,
              2014. 802.1Q.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
              Profile (MPLS-TP) Identifiers", RFC 6370,
              DOI 10.17487/RFC6370, September 2011,
              <https://www.rfc-editor.org/info/rfc6370>.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536,
              DOI 10.17487/RFC6536, March 2012,
              <https://www.rfc-editor.org/info/rfc6536>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

11.2.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
              <https://www.rfc-editor.org/info/rfc8343>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

10.2.  Informative References

   [G.800]    "Unified functional architecture of transport networks",
              ITU-T Recommendation G.800, 2016.

   [G.8013]   "OAM functions and mechanisms for Ethernet based
              networks", ITU-T Recommendation G.8013/Y.1731, 2013.

   [I-D.ietf-lime-yang-connectionless-oam]
              Kumar, D., Wang, Z., Wu, Q., Rahman, R., and S. Raghavan,
              "Generic YANG Data Model for the Management of Operations,
              Administration, and Maintenance (OAM) Protocols that use
              Connectionless Communications", draft-ietf-lime-yang-
              connectionless-oam-18 (work in progress), November 2017.

   [I-D.ietf-netmod-revised-datastores]
              Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore
              Architecture", draft-ietf-netmod-revised-datastores-10
              (work in progress), January 2018.

   [I-D.ietf-netmod-yang-tree-diagrams]
              Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
              ietf-netmod-yang-tree-diagrams-06 (work in progress),
              February 2018.

   [I-D.ietf-trill-yang]
              Weiguo, H., Yizhou, L., Kumar, D., Durrani, M., Zhai, H.,
              and L. Xia, "TRILL YANG Data Model", draft-ietf-trill-
              yang-04 (work in progress), December 2015.

   [I-D.ietf-trill-yang-oam]
              Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L.,
              and H. Weiguo, "YANG Data Model for TRILL Operations,
              Administration, and Maintenance (OAM)", draft-ietf-trill-
              yang-oam-05 (work in progress), March 2017.

   [MEF-17]   MEF Forum, "Service OAM Requirements & Framework - Phase
              1", METRO
              ETHERNET FORUM MEF 17, April 2007.

   [mpls-tp-oam-yang]

   [MPLS-TP-OAM-YANG]
              Zhang, L., Zheng, L., Aldrin, S., and G. Mirsky, "YANG
              Data Model for MPLS-TP Operations, Administration, and
              Maintenance", draft-zhang-mpls-tp-yang-oam (work
              Maintenance (OAM)", Work in
              progress), 2016. Progress, draft-zhang-mpls-tp-
              yang-oam-05, October 2017.

   [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
              D., and S. Mansfield, "Guidelines for the Use of the "OAM"
              Acronym in the IETF", BCP 161, RFC 6291,
              DOI 10.17487/RFC6291, June 2011,
              <https://www.rfc-editor.org/info/rfc6291>.

   [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
              Ghanwani, "Routing Bridges (RBridges): Base Protocol
              Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
              <https://www.rfc-editor.org/info/rfc6325>.

   [RFC6371]  Busi, I., Ed. and D. Allan, Ed., "Operations,
              Administration, and Maintenance Framework for MPLS-Based
              Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
              September 2011, <https://www.rfc-editor.org/info/rfc6371>.

   [RFC6905]  Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R.
              Watve, "Requirements for Operations, Administration, and
              Maintenance (OAM) in Transparent Interconnection of Lots
              of Links (TRILL)", RFC 6905, DOI 10.17487/RFC6905, March
              2013, <https://www.rfc-editor.org/info/rfc6905>.

   [RFC7174]  Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake
              3rd, "Transparent Interconnection of Lots of Links (TRILL)
              Operations, Administration, and Maintenance (OAM)
              Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014,
              <https://www.rfc-editor.org/info/rfc7174>.

   [RFC7276]  Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
              Weingarten, "An Overview of Operations, Administration,
              and Maintenance (OAM) Tools", RFC 7276,
              DOI 10.17487/RFC7276, June 2014,
              <https://www.rfc-editor.org/info/rfc7276>.

   [RFC7455]  Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake
              3rd, D., Aldrin, S., and Y. Li, "Transparent
              Interconnection of Lots of Links (TRILL): Fault
              Management", RFC 7455, DOI 10.17487/RFC7455, March 2015,
              <https://www.rfc-editor.org/info/rfc7455>.

Appendix A.  Contributors' Addresses

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore Architecture
              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
              <https://www.rfc-editor.org/info/rfc8342>.

   [RFC8532]  Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S.
              Raghavan, "Generic YANG Data Model for the Management of
              Operations, Administration, and Maintenance (OAM)
              Protocols That Use Connectionless Communications",
              RFC 8532, DOI 10.17487/RFC8532, March 2019,
              <https://www.rfc-editor.org/info/rfc8532>.

   [TRILL-YANG]
              Weiguo, H., Yizhou, L., Kumar, D., Durrani, M., Zhai, H.,
              and L. Xia, "TRILL YANG Data Model", Work in Progress,
              draft-ietf-trill-yang-04, December 2015.

   [TRILL-YANG-OAM]
              Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L.,
              and H. Weiguo, "YANG Data Model for TRILL Operations,
              Administration, and Maintenance (OAM)", Work in Progress,
              draft-ietf-trill-yang-oam-05, March 2017.

Acknowledgments

   Giles Heron came up with the idea of developing a YANG data model as
   a way of creating a unified OAM API set (interface); this document
   was largely inspired by that.  Alexander Clemm provided many valuable
   tips, comments, and remarks that helped to refine the YANG data model
   presented in this document.

   Carlos Pignataro, David Ball, Mahesh Jethanandani, Benoit Claise,
   Ladislav Lhotka, Jens Guballa, Yuji Tochio, Gregory Mirsky, Huub van
   Helvoort, Tom Taylor, Dapeng Liu, Mishael Wexler, and Adi Molkho
   contributed to and participated in the development of this document.

Contributors

   Tissa Senevirathne
   Consultant

   Email: tsenevir@gmail.com

   Norman Finn
   CISCO Systems
   510 McCarthy Blvd
   Milpitas, CA  95035
      USA
   United States of America

   Email: nfinn@cisco.com
   Samer Salam
   CISCO Systems
   595 Burrard St. Suite 2123
   Vancouver, BC  V7X 1J1
   Canada

   Email: ssalam@cisco.com

Authors' Addresses

   Deepak Kumar
   CISCO Systems
   510 McCarthy Blvd
   Milpitas, CA  95035
   USA
   United States of America

   Email: dekumar@cisco.com

   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: bill.wu@huawei.com

   Michael Wang
   Huawei Technologies,Co.,Ltd Technologies, Co., Ltd
   101 Software Avenue, Yuhua District
   Nanjing  210012
   China

   Email: wangzitao@huawei.com