diff options
Diffstat (limited to 'doc/rfc/rfc8531.txt')
| -rw-r--r-- | doc/rfc/rfc8531.txt | 3027 |
1 files changed, 3027 insertions, 0 deletions
diff --git a/doc/rfc/rfc8531.txt b/doc/rfc/rfc8531.txt new file mode 100644 index 0000000..40bc177 --- /dev/null +++ b/doc/rfc/rfc8531.txt @@ -0,0 +1,3027 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Kumar +Request for Comments: 8531 Cisco +Category: Standards Track Q. Wu +ISSN: 2070-1721 M. Wang + Huawei + April 2019 + + + Generic YANG Data Model for + Connection-Oriented Operations, Administration, and Maintenance (OAM) + Protocols + +Abstract + + This document presents a base YANG data model for connection-oriented + Operations, Administration, and Maintenance (OAM) protocols. It + provides a technology-independent abstraction of key OAM constructs + for such protocols. The model presented here can be extended to + include technology-specific details. This guarantees uniformity in + the management of OAM protocols and provides support for nested OAM + workflows (i.e., performing OAM functions at different levels through + a unified interface). + + The YANG data model in this document conforms to the Network + Management Datastore Architecture. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8531. + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 1] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + +Copyright Notice + + Copyright (c) 2019 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 2] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 + 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 + 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Architecture of Generic YANG Data Model for Connection- + Oriented OAM . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Overview of the Connection-Oriented OAM YANG Data Model . . . 8 + 4.1. Maintenance Domain (MD) Configuration . . . . . . . . . . 9 + 4.2. Maintenance Association (MA) Configuration . . . . . . . 10 + 4.3. Maintenance End Point (MEP) Configuration . . . . . . . . 11 + 4.4. RPC Definitions . . . . . . . . . . . . . . . . . . . . . 11 + 4.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 14 + 4.6. Monitor Statistics . . . . . . . . . . . . . . . . . . . 14 + 4.7. OAM Data Hierarchy . . . . . . . . . . . . . . . . . . . 14 + 5. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19 + 6. Base Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 42 + 6.1. MEP Address . . . . . . . . . . . . . . . . . . . . . . . 42 + 6.2. MEP ID for Base Mode . . . . . . . . . . . . . . . . . . 42 + 6.3. Maintenance Association . . . . . . . . . . . . . . . . . 42 + 7. Connection-Oriented OAM YANG Data Model Applicability . . . . 43 + 7.1. Generic YANG Data Model Extension for TRILL OAM . . . . . 43 + 7.1.1. MD Configuration Extension . . . . . . . . . . . . . 43 + 7.1.2. MA Configuration Extension . . . . . . . . . . . . . 44 + 7.1.3. MEP Configuration Extension . . . . . . . . . . . . . 45 + 7.1.4. RPC Extension . . . . . . . . . . . . . . . . . . . . 46 + 7.2. Generic YANG Data Model Extension for MPLS-TP OAM . . . . 46 + 7.2.1. MD Configuration Extension . . . . . . . . . . . . . 47 + 7.2.2. MA Configuration Extension . . . . . . . . . . . . . 48 + 7.2.3. MEP Configuration Extension . . . . . . . . . . . . . 48 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 50 + 10.2. Informative References . . . . . . . . . . . . . . . . . 51 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 53 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 + + + + + + + + + + + +Kumar, et al. Standards Track [Page 3] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + +1. Introduction + + Operations, Administration, and Maintenance (OAM) are important + networking functions that allow operators to: + + 1. monitor network communications (i.e., reachability verification + and Continuity Check) + + 2. troubleshoot failures (i.e., fault verification and localization) + + 3. monitor service-level agreements and performance (i.e., + performance management) + + An overview of OAM tools is presented in [RFC7276]. Over the years, + many technologies have developed similar tools for fault and + performance management. + + The different sets of OAM tools may support both connection-oriented + technologies or connectionless technologies. In connection-oriented + technologies, a connection is established prior to the transmission + of data. After the connection is established, no additional control + information such as signaling or operations and maintenance + information is required to transmit the actual user data. In + connectionless technologies, data is typically sent between + communicating endpoints without prior arrangement, but control + information is required to identify the destination (e.g., [G.800]). + The YANG data model for OAM protocols using connectionless + communications is specified in [RFC8532] and [IEEE802.1Q]. + + Connectivity Fault Management as specified in [IEEE802.1Q] is a well- + established OAM standard that is widely adopted for Ethernet + networks. ITU-T [G.8013], MEF Forum (MEF) Service OAM [MEF-17], MPLS + Transport Profile (MPLS-TP) [RFC6371], and Transparent + Interconnection of Lots of Links (TRILL) [RFC7455] all define OAM + mechanisms based on the manageability framework of Connectivity Fault + Management (CFM) [IEEE802.1Q]. + + Given the wide adoption of the underlying OAM concepts defined in CFM + [IEEE802.1Q], it is a reasonable choice to develop the unified + management framework for connection-oriented OAM based on those + concepts. In this document, we take the CFM [IEEE802.1Q] model and + extend it to a technology-independent framework and define the + corresponding YANG data model accordingly. The YANG data model + presented in this document is the base model for connection-oriented + OAM protocols and supports generic continuity check, connectivity + verification, and path discovery (traceroute). The generic YANG data + model for connection-oriented OAM is designed to be extensible to + other connection-oriented technologies. Technology-dependent nodes + + + +Kumar, et al. Standards Track [Page 4] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + and remote procedure call (RPC) commands are defined in technology- + specific YANG data models, which use and extend the base model + defined here. As an example, Virtual eXtensible Local Area Network + (VXLAN) uses the source UDP port number for flow entropy, while TRILL + uses either (a) MAC addresses, (b) the VLAN tag or Fine-Grained + Label, and/or (c) IP addresses for flow entropy in the hashing for + multipath selection. To capture this variation, corresponding YANG + data models would define the applicable structures as augmentation to + the generic base model presented here. This accomplishes three + goals: First, it keeps each YANG data model smaller and more + manageable. Second, it allows independent development of + corresponding YANG data models. Third, implementations can limit + support to only the applicable set of YANG data models (e.g., TRILL + RBridge may only need to implement the generic model and the TRILL + YANG data model). + + The YANG data model presented in this document is generated at the + management layer. Encapsulations and state machines may differ + according to each OAM protocol. A user who wishes to issue a + Continuity Check command or a Loopback or initiate a performance + monitoring session can do so in the same manner, regardless of the + underlying protocol or technology or specific vendor implementation. + + As an example, consider a scenario where connectivity from device A + loopback to device B fails. Between device A and B there are IEEE + 802.1 bridges a, b, and c. Let's assume a, b, and c are using CFM + [IEEE802.1Q]. A user, upon detecting the loopback failure, may + decide to drill down to the lower level at different segments of the + path and issue the corresponding fault verification (Loopback + Message) and fault isolation (Looktrace Message) tools, using the + same API. This ability to drill down to a lower layer of the + protocol stack at a specific segment within a path for fault + localization and troubleshooting is referred to as "nested OAM + workflow". It is a useful concept that leads to efficient network + troubleshooting and maintenance workflows. The connection-oriented + OAM YANG data model presented in this document facilitates that + without needing changes to the underlying protocols. + + The YANG data model in this document conforms to the Network + Management Datastore Architecture defined in [RFC8342]. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + + +Kumar, et al. Standards Track [Page 5] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + Many of the terms used in this document (including those set out in + Sections Section 2.1 and Section 2.2) are specific to the world of + OAM. This document does not attempt to explain the terms but does + assume that the reader is familiar with the concepts. For a good + overview, read [IEEE802.1Q]. For an example of how these OAM terms + appear in IETF work, see [RFC6371]. + +2.1. Abbreviations + + CCM - Continuity Check Message [IEEE802.1Q] + + ECMP - Equal-Cost Multipath + + LBM - Loopback Message [IEEE802.1Q] + + LTM - Linktrace Message [IEEE802.1Q] + + MP - Maintenance Point [IEEE802.1Q] + + MEP - Maintenance End Point [RFC7174] (also known as Maintenance + association End Point [IEEE802.1Q] and MEG End Point [RFC6371]) + + MIP - Maintenance Intermediate Point [RFC7174] (also known as + Maintenance domain Intermediate Point [IEEE802.1Q] and MEG + Intermediate Point [RFC6371]) + + MA - Maintenance Association [IEEE802.1Q] [RFC7174] + + MD - Maintenance Domain [IEEE802.1Q] + + MEG - Maintenance Entity Group [RFC6371] + + MTV - Multi-destination Tree Verification Message + + OAM - Operations, Administration, and Maintenance [RFC6291] + + TRILL - Transparent Interconnection of Lots of Links [RFC6325] + + CFM - Connectivity Fault Management [RFC7174] [IEEE802.1Q] + + RPC - Remote Procedure Call + + CC - Continuity Check [RFC7276] + + CV - Connectivity Verification [RFC7276] + + + + + + +Kumar, et al. Standards Track [Page 6] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + +2.2. Terminology + + Continuity Checks - Continuity Checks are used to verify that a + destination is reachable and therefore also are referred to as + "reachability verification". + + Connectivity Verification - Connectivity Verification is used to + verify that a destination is connected. It is also referred to as + "path verification" and used to verify not only that the two MPs + are connected, but also that they are connected through the + expected path, allowing detection of unexpected topology changes. + + Proactive OAM - Proactive OAM refers to OAM actions that are carried + out continuously to permit proactive reporting of fault. A + proactive OAM method requires persistent configuration. + + On-demand OAM - On-demand OAM refers to OAM actions that are + initiated via manual intervention for a limited time to carry out + diagnostics. An on-demand OAM method requires only transient + configuration. + +2.3. Tree Diagrams + + Tree diagrams used in this document follow the notation defined in + [RFC8340]. + +3. Architecture of Generic YANG Data Model for Connection-Oriented OAM + + In this document, we define a generic YANG data model for connection- + oriented OAM protocols. The YANG data model defined here is generic + in a sense that other technologies can extend it for technology- + specific needs. The generic YANG data model for connection-oriented + OAM acts as the root for other OAM YANG data models. This allows + users to traverse between different OAM protocols with ease through a + uniform API set. This also enables a nested OAM workflow. Figure 1 + depicts the relationship of different OAM YANG data models to the + Generic YANG Data Model for connection-oriented OAM. The Generic + YANG data model for connection-oriented OAM provides a framework + where technology-specific YANG data models can inherit constructs + from the base YANG data models without needing to redefine them + within the sub-technology. + + + + + + + + + + +Kumar, et al. Standards Track [Page 7] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + +-----------+ + |Connection-| + | Oriented | + | generic | + | OAM YANG | + +-+-+-+-+-+-+ + | + | + | + +------------------------------------------+ + | | | + +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ + | TRILL | | MPLS-TP | . . .| foo | + |OAM YANG | |OAM YANG | |OAM YANG | + +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ + | | | + | | +-+-+-+-+-+ + | | . . .| foo | + | | |sub tech | + | | +-+-+-+-+-+ + | | | + | | | + +-------------------------------------------------------+ + | Uniform API | + +-------------------------------------------------------+ + + Figure 1: Relationship of OAM YANG Data Model to Generic (Base) YANG + Data Model + +4. Overview of the Connection-Oriented OAM YANG Data Model + + In this document, we adopt the concepts of the CFM [IEEE802.1Q] model + and structure such that it can be adapted to different connection- + oriented OAM protocols. + + At the top of the model is the Maintenance Domain. Each Maintenance + Domain is associated with a Maintenance Name and a Domain Level. + + Under each Maintenance Domain, there is one or more Maintenance + Associations (MAs). In TRILL, the MA can correspond to a Fine- + Grained Label. + + Under each MA, there can be two or more MEPs (Maintenance End + Points). MEPs are addressed by their respective technology-specific + address identifiers. The YANG data model presented here provides + flexibility to accommodate different addressing schemes. + + + + + +Kumar, et al. Standards Track [Page 8] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + Commands are presented in the management protocol, which is + orthogonal to the Maintenance Domain. These are RPC commands, in + YANG terms. They provide uniform APIs for Continuity Check, + connectivity verification, path discovery (traceroute), and their + equivalents, as well as other OAM commands. + + The OAM entities in the generic YANG data model defined here will be + either explicitly or implicitly configured using any of the OAM + tools. The OAM tools used here are limited to the OAM toolset + specified in Section 5.1 of [RFC7276]. In order to facilitate a + zero-touch experience, this document defines a default mode of OAM. + The default mode of OAM is referred to as the "Base Mode" and + specifies default values for each of the model's parameters, such as + Maintenance Domain Level, Name of the Maintenance Association, + Addresses of MEPs, and so on. The default values of these depend on + the technology. Base Mode for TRILL is defined in [RFC7455]. Base + Mode for other technologies and future extensions developed in IETF + will be defined in their corresponding documents. + + It is important to note that no specific enhancements are needed in + the YANG data model to support Base Mode. Implementations that + comply with this document use, by default, the data nodes of the + applicable technology. Data nodes of the Base Mode are read-only + nodes. + +4.1. Maintenance Domain (MD) Configuration + + The container "domains" is the top-level container within the + "gen-oam" module. Within the container "domains", a separate list is + maintained per MD. The MD list uses the key "md-name-string" for + indexing. The "md-name-string" is a leaf and derived from type + string. Additional name formats as defined in [IEEE802.1Q], or other + standards, can be included by association of the "md-name-format" + with an identity-ref. The "md-name-format" indicates the format of + the augmented "md-name". The "md-name" is presented as choice/case + construct. Thus, it is easily augmentable by derivative work. + + + + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 9] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + module: ietf-connection-oriented-oam + +--rw domains + +--rw domain* [technology md-name-string] + +--rw technology identityref + +--rw md-name-string md-name-string + +--rw md-name-format? identityref + +--rw (md-name)? + | +--:(md-name-null) + | +--rw md-name-null? empty + +--rw md-level? md-level + + Snippet of Data Hierarchy Related to OAM Domains + +4.2. Maintenance Association (MA) Configuration + + Within a given Maintenance Domain, there can be one or more + Maintenance Associations (MAs). MAs are represented as a list and + indexed by the "ma-name-string". Similar to "md-name" defined + previously, additional name formats can be added by augmenting the + name-format "identity-ref" and adding applicable case statements to + "ma-name". + + module: ietf-connection-oriented-oam + +--rw domains + +--rw domain* [technology md-name-string] + . + . + +--rw mas + +--rw ma* [ma-name-string] + +--rw ma-name-string ma-name-string + +--rw ma-name-format? identityref + +--rw (ma-name)? + | +--:(ma-name-null) + | +--rw ma-name-null? empty + + Snippet of Data Hierarchy Related to Maintenance Associations (MAs) + + + + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 10] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + +4.3. Maintenance End Point (MEP) Configuration + + Within a given Maintenance Association (MA), there can be one or more + Maintenance End Points (MEPs). MEPs are represented as a list within + the data hierarchy and indexed by the key "mep-name". + + module: ietf-connection-oriented-oam + +--rw domains + +--rw domain* [technology md-name-string] + +--rw technology identityref + . + . + +--rw mas + +--rw ma* [ma-name-string] + . + . + +--rw mep* [mep-name] + | +--rw mep-name mep-name + | +--rw (mep-id)? + | | +--:(mep-id-int) + | | +--rw mep-id-int? int32 + | +--rw mep-id-format? identityref + | +--rw (mep-address)? + | | +--:(mac-address) + | | | +--rw mac-address? yang:mac-address + | | +--:(ip-address) + | | +--rw ip-address? inet:ip-address + . . + . . + . . + + Snippet of Data Hierarchy Related to Maintenance End Point (MEP) + +4.4. RPC Definitions + + The RPC model facilitates issuing commands to a "server" (in this + case, to the device that need to execute the OAM command) and + obtaining a response. The RPC model defined here abstracts OAM- + specific commands in a technology-independent manner. + + There are several RPC commands defined for the purpose of OAM. In + this section, we present a snippet of the Continuity Check command + for illustration purposes. Please refer to Section 4.5 for the + complete data hierarchy and Section 5 for the YANG module. + + + + + + + +Kumar, et al. Standards Track [Page 11] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + 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) + + + +Kumar, et al. Standards Track [Page 12] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + | | | | +---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}? + + + +Kumar, et al. Standards Track [Page 13] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + | +--ro interface? if:interface-ref + | +--ro (mip-address)? + | +--:(mac-address) + | | +--ro mac-address? yang:mac-address + | +--:(ip-address) + | +--ro ip-address? inet:ip-address + +--ro (monitor-stats)? + +--:(monitor-null) + +--ro monitor-null? empty + + Snippet of Data Hierarchy Related to RPC Call Continuity-Check + +4.5. Notifications + + Notification is sent upon detecting a defect condition and upon + clearing a defect with a Maintenance Domain Name, MA Name, defect- + type (the currently active defects), generating-mepid, and defect- + message to indicate more details. + +4.6. Monitor Statistics + + Grouping for monitoring statistics is to be used by technology- + specific YANG modules that augment the generic YANG data model to + provide statistics due to proactive OAM-like Continuity Check + Messages -- for example, CCM transmit, CCM receive, CCM error, etc. + +4.7. OAM Data Hierarchy + + The complete data hierarchy related to the connection-oriented OAM + YANG data model is presented below. + + module: ietf-connection-oriented-oam + +--rw domains + +--rw domain* [technology md-name-string] + +--rw technology identityref + +--rw md-name-string md-name-string + +--rw md-name-format? identityref + +--rw (md-name)? + | +--:(md-name-null) + | +--rw md-name-null? empty + +--rw md-level? md-level + +--rw mas + +--rw ma* [ma-name-string] + +--rw ma-name-string ma-name-string + +--rw ma-name-format? identityref + +--rw (ma-name)? + | +--:(ma-name-null) + | +--rw ma-name-null? empty + + + +Kumar, et al. Standards Track [Page 14] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + +--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 + + + +Kumar, et al. Standards Track [Page 15] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + | | +---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}? + + + +Kumar, et al. Standards Track [Page 16] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + +---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 + + + + + + + +Kumar, et al. Standards Track [Page 17] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + notifications: + +---n defect-condition-notification + | +--ro technology? identityref + | +--ro md-name-string -> /domains/domain/md-name-string + | +--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string + | +--ro mep-name? -> /domains/domain/mas/ma/mep/mep-name + | +--ro defect-type? identityref + | +--ro generating-mepid + | | +--ro (mep-id)? + | | | +--:(mep-id-int) + | | | +--ro mep-id-int? int32 + | | +--ro mep-id-format? identityref + | +--ro (defect)? + | +--:(defect-null) + | | +--ro defect-null? empty + | +--:(defect-code) + | +--ro defect-code? int32 + +---n defect-cleared-notification + +--ro technology? identityref + +--ro md-name-string -> /domains/domain/md-name-string + +--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string + +--ro mep-name? -> /domains/domain/mas/ma/mep/mep-name + +--ro defect-type? identityref + +--ro generating-mepid + | +--ro (mep-id)? + | | +--:(mep-id-int) + | | +--ro mep-id-int? int32 + | +--ro mep-id-format? identityref + +--ro (defect)? + +--:(defect-null) + | +--ro defect-null? empty + +--:(defect-code) + +--ro defect-code? int32 + + Data Hierarchy of OAM + + + + + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 18] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + +5. OAM YANG Module + + This module imports typedefs from [RFC6991] and [RFC8343], and it + references [RFC6371], [RFC6905], and [RFC7276]. + + <CODE BEGINS> file "ietf-connection-oriented-oam@2019-04-16.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://datatracker.ietf.org/wg/lime + WG List: <mailto:lime@ietf.org> + Editor: Deepak Kumar <dekumar@cisco.com> + Editor: Qin Wu <bill.wu@huawei.com> + Editor: Michael Wang <wangzitao@huawei.com>"; + description + "This YANG module defines the generic configuration, + statistics and RPC for connection-oriented OAM + to be used within IETF in a protocol-independent manner. + 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 extensions + + Copyright (c) 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 + + + +Kumar, et al. Standards Track [Page 19] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + (http://trustee.ietf.org/license-info). + + This version of this YANG module is part of RFC 8531; see + the RFC itself for full legal notices."; + + revision 2019-04-16 { + description + "Initial revision."; + reference + "RFC 8531: Generic YANG Data Model for Connection- + Oriented 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 model for a + connectivity verification command."; + } + + feature continuity-check { + description + "This feature indicates that the server supports + executing a Continuity Check OAM command and + returning a response. Servers that do not advertise + this feature will not support executing a + Continuity Check command or RPC model for 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 model for a + traceroute command."; + } + + feature mip { + description + "This feature indicates that the Maintenance + Intermediate Point (MIP) needs to be explicitly configured"; + + + +Kumar, et al. Standards Track [Page 20] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + } + + identity technology-types { + description + "This is the base identity of technology types that are + TRILL, MPLS-TP, etc."; + } + + identity command-sub-type { + description + "Defines different RPC command subtypes, + e.g., TRILL OAM as specified in RFC 6905; this is + optional for most 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 activation indicates that the tool is activated + manually to detect a specific anomaly. + 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. 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, CFM (IEEE 802.1Q) defines varying + styles of names. It is expected that name format is an identity + reference to be extended with new types."; + } + + + +Kumar, et al. Standards Track [Page 21] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + identity name-format-null { + base name-format; + description + "Defines name format as null."; + } + + identity identifier-format { + description + "Identifier-format identity can be augmented to define other + format identifiers used in MEP-ID, etc."; + } + + identity identifier-format-integer { + base identifier-format; + description + "Defines identifier-format to be integer."; + } + + identity defect-types { + description + "Defines different defect types, e.g., + Remote Defect Indication (RDI), loss of continuity."; + } + + identity rdi { + base defect-types; + description + "The 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 MEPs are + reporting a failure."; + } + + identity loss-of-continuity { + base defect-types; + description + "Indicates that there are no proactive Continuity Check (CC) + OAM packets from the source MEP (and in the case of + Connectivity Verification, this includes the requirement to have + the expected unique, technology-dependent source MEP identifier) + received within the interval."; + reference + "RFC 6371: Operations, Administration, and Maintenance + + + +Kumar, et al. Standards Track [Page 22] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + Framework for MPLS-Based Transport Networks"; + } + + identity cv-defect { + base defect-types; + description + "This function should support monitoring between the MEPs + and, in addition, between a MEP and MIP. When performing + Connectivity Verification, 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 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) + messages 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 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. + + + +Kumar, et al. Standards Track [Page 23] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + 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 counter for OAM."; + } + + typedef md-level { + type uint32 { + range "0..255"; + } + description + "Maintenance Domain 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."; + 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. It consists + of a maintenance-domain-reference and + + + +Kumar, et al. Standards Track [Page 24] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + a maintenance-association 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"; + } + description + "A reference to a specific Maintenance Association."; + } + } + + grouping maintenance-association-end-point-reference { + description + "This grouping uniquely identifies + a Maintenance Association. It consists + of a maintenance-association-reference and + a maintenance-association-end-point 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 = " + + "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 + + + +Kumar, et al. Standards Track [Page 25] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + "This is a placeholder when no defect status is needed."; + leaf defect-null { + type empty; + description + "There is no defect to be defined; it will be defined in + 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"; + case mac-address { + leaf mac-address { + type yang:mac-address; + description + "MAC Address."; + } + description + "MAC Address based MEP Addressing."; + } + case ip-address { + leaf ip-address { + type inet:ip-address; + description + "IP Address."; + } + description + "IP Address based MEP Addressing."; + } + description + "MEP Addressing."; + } + + + +Kumar, et al. Standards Track [Page 26] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + description + "Grouping for MEP Address"; + } + + grouping mip-address { + choice mip-address { + default "ip-address"; + case mac-address { + leaf mac-address { + type yang:mac-address; + description + "MAC Address of Maintenance Intermediate Point"; + } + description + "MAC Address based MIP Addressing."; + } + case ip-address { + leaf ip-address { + type inet:ip-address; + description + "IP Address."; + } + description + "IP Address based MIP Addressing."; + } + description + "MIP Addressing."; + } + description + "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 + + + +Kumar, et al. Standards Track [Page 27] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + "Defines the generic administrative 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')" { + description + "MD name format is equal to null format."; + } + type empty; + description + "MD name null."; + } + } + description + "MD name."; + } + description + "MD name."; + } + + grouping ma-identifier { + description + "Grouping containing leaves sufficient to identify an MA."; + leaf ma-name-string { + type ma-name-string; + description + "MA name string."; + } + } + + grouping ma-name { + description + "MA name."; + leaf ma-name-format { + type identityref { + base name-format; + + + +Kumar, et al. Standards Track [Page 28] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + } + description + "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')" { + description + "MA."; + } + type empty; + description + "Empty"; + } + } + description + "MA name."; + } + } + + grouping mep-id { + choice mep-id { + default "mep-id-int"; + case mep-id-int { + leaf mep-id-int { + type int32; + description + "MEP ID + in integer format."; + } + } + description + "MEP ID."; + } + leaf mep-id-format { + type identityref { + base identifier-format; + } + description + "MEP ID format."; + } + description + "MEP ID."; + } + + grouping mep { + + + +Kumar, et al. Standards Track [Page 29] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + description + "Defines elements within the MEP."; + leaf mep-name { + type mep-name; + mandatory true; + description + "Generic administrative name of the + MEP."; + } + uses mep-id; + uses mep-address; + } + + grouping monitor-stats { + description + "Grouping for monitoring statistics; this will be augmented + by others who use this component."; + choice monitor-stats { + default "monitor-null"; + case monitor-null { + description + "This is a placeholder when + no monitoring statistics are needed."; + leaf monitor-null { + type empty; + description + "There are no monitoring statistics to be defined."; + } + } + description + "Define the monitor stats."; + } + } + + grouping connectivity-context { + description + "Grouping defining the connectivity context for an MA, + for example, an LSP for MPLS-TP. This will be + augmented by each protocol that uses this component."; + choice connectivity-context { + default "context-null"; + case context-null { + description + "This is a placeholder when no context is needed."; + leaf context-null { + type empty; + description + "There is no context to be defined."; + + + +Kumar, et al. Standards Track [Page 30] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + } + } + 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; this value is used to indicate + Class of Service information ."; + } + } + + grouping mip-grouping { + uses mip-address; + description + "Grouping for MIP + configuration."; + } + + container domains { + description + "Contains configuration related data. Within the + container, there is a list of fault domains. Each + domain has a list of 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."; + } + container mas { + description + "Contains configuration-related data. Within the + container, there is a list of MAs. Each MA has a + list of MEPs."; + + + +Kumar, et al. Standards Track [Page 31] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + list ma { + key "ma-name-string"; + uses ma-identifier; + uses ma-name; + uses connectivity-context; + uses cos { + description + "Default class of service for this MA; + it may be overridden for particular MEPs, + sessions, or operations."; + } + leaf cc-enable { + type boolean; + description + "Indicate whether the CC is enabled."; + } + list mep { + key "mep-name"; + description + "Contain a list of MEPs."; + uses mep; + uses cos; + leaf cc-enable { + type boolean; + description + "Indicate whether the CC is enabled."; + } + list session { + key "session-cookie"; + description + "Monitoring session to/from a particular remote MEP. + Depending on the protocol, this could represent + 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 MEPs or multiple sessions to + the same remote MEP."; + } + container destination-mep { + uses mep-id; + description + "Destination MEP."; + + + +Kumar, et al. Standards Track [Page 32] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + } + container destination-mep-address { + uses mep-address; + description + "Destination MEP Address."; + } + uses cos; + } + } + list mip { + if-feature "mip"; + key "name"; + leaf name { + type string; + description + "Identifier of Maintenance Intermediate Point"; + } + leaf interface { + type if:interface-ref; + description + "Interface."; + } + uses mip-grouping; + description + "List for MIP."; + } + description + "Maintenance Association list."; + } + } + } + } + + notification defect-condition-notification { + description + "When the defect condition is met, this notification is 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; + + + +Kumar, et al. Standards Track [Page 33] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + description + "Indicate which MD the defect belongs to."; + } + leaf ma-name-string { + type leafref { + path "/domains/domain/mas/ma/ma-name-string"; + } + mandatory true; + description + "Indicate which MA the defect is associated with."; + } + leaf mep-name { + type leafref { + path "/domains/domain/mas/ma/mep/mep-name"; + } + description + "Indicate which MEP is seeing the defect."; + } + leaf defect-type { + type identityref { + base defect-types; + } + description + "The currently active defects on the specific MEP."; + } + container generating-mepid { + uses mep-id; + description + "Indicate who is generating the defect (if known). If + unknown, set it to 0."; + } + uses defect-message { + description + "Defect message to provide more details."; + } + } + + notification defect-cleared-notification { + description + "When the defect is cleared, this notification is sent."; + leaf technology { + type identityref { + base technology-types; + } + description + "The technology."; + } + leaf md-name-string { + + + +Kumar, et al. Standards Track [Page 34] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + type leafref { + path "/domains/domain/md-name-string"; + } + mandatory true; + description + "Indicate which MD the defect belongs to"; + } + leaf ma-name-string { + type leafref { + path "/domains/domain/mas/ma/ma-name-string"; + } + mandatory true; + description + "Indicate which MA the defect is associated with."; + } + leaf mep-name { + type leafref { + path "/domains/domain/mas/ma/mep/mep-name"; + } + description + "Indicate which MEP is seeing the defect."; + } + leaf defect-type { + type identityref { + base defect-types; + } + description + "The currently active defects on the specific MEP."; + } + container generating-mepid { + uses mep-id; + description + "Indicate who is generating the defect (if known). If + unknown, set it to 0."; + } + uses defect-message { + description + "Defect message to provide more details."; + } + } + + rpc continuity-check { + if-feature "continuity-check"; + description + "Generates Continuity Check as per Table 4 of RFC 7276."; + input { + leaf technology { + type identityref { + + + +Kumar, et al. Standards Track [Page 35] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + base technology-types; + } + description + "The technology."; + } + leaf md-name-string { + type leafref { + path "/domains/domain/md-name-string"; + } + mandatory true; + description + "Indicate which MD the defect belongs to."; + } + leaf md-level { + type leafref { + path "/domains/domain/md-level"; + } + description + "The Maintenance Domain Level."; + } + leaf ma-name-string { + type leafref { + path "/domains/domain/mas/ma/ma-name-string"; + } + mandatory true; + description + "Indicate which 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 MEP."; + } + container destination-mep { + uses mep-address; + uses mep-id { + description + + + +Kumar, et al. Standards Track [Page 36] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + "Only applicable if the destination is a MEP."; + } + description + "Destination MEP."; + } + leaf count { + type uint32; + default "3"; + description + "Number of continuity-check 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."; + } + } + } + + rpc continuity-verification { + if-feature "connectivity-verification"; + description + "Generates Connectivity Verification as per Table 4 in RFC 7276."; + input { + leaf md-name-string { + type leafref { + path "/domains/domain/md-name-string"; + } + mandatory true; + description + "Indicate which MD the defect belongs to."; + } + leaf md-level { + type leafref { + path "/domains/domain/md-level"; + + + +Kumar, et al. Standards Track [Page 37] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + } + description + "The Maintenance Domain Level."; + } + leaf ma-name-string { + type leafref { + path "/domains/domain/mas/ma/ma-name-string"; + } + mandatory true; + description + "Indicate which 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 MEP."; + } + container destination-mep { + uses mep-address; + uses mep-id { + description + "Only applicable if the destination is a MEP."; + } + description + "Destination MEP."; + } + leaf count { + type uint32; + default "3"; + description + "Number of continuity-verification messages to be sent."; + } + leaf interval { + type time-interval; + description + "Time interval between echo requests."; + } + + + +Kumar, et al. Standards Track [Page 38] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + leaf packet-size { + type uint32 { + range "64..10000"; + } + description + "Size of continuity-verification packets, in octets."; + } + } + output { + uses monitor-stats { + description + "Stats of Continuity Check."; + } + } + } + + rpc traceroute { + if-feature "traceroute"; + description + "Generates Traceroute or Path Trace and returns response. + References RFC 7276 for common Toolset name -- for + MPLS-TP OAM, it's Route Tracing, and for TRILL OAM, it's + Path Tracing tool. Starts with TTL of one and increments + by one at each hop until the destination is reached or TTL + reaches max value."; + input { + leaf md-name-string { + type leafref { + path "/domains/domain/md-name-string"; + } + mandatory true; + description + "Indicate which MD the defect belongs to."; + } + leaf md-level { + type leafref { + path "/domains/domain/md-level"; + } + description + "The Maintenance Domain Level."; + } + leaf ma-name-string { + type leafref { + path "/domains/domain/mas/ma/ma-name-string"; + } + mandatory true; + description + "Indicate which MA the defect is associated with."; + + + +Kumar, et al. Standards Track [Page 39] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + } + 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 MEP."; + } + container destination-mep { + uses mep-address; + uses mep-id { + description + "Only applicable if the destination is a MEP."; + } + description + "Destination 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, + + + +Kumar, et al. Standards Track [Page 40] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + the TTL can be used as the response index."; + } + uses time-to-live; + container destination-mep { + description + "MEP from which the response has been received"; + uses mep-address; + uses mep-id { + description + "Only applicable if the destination is a MEP."; + } + } + container mip { + if-feature "mip"; + leaf interface { + type if:interface-ref; + description + "MIP interface."; + } + uses mip-address; + description + "MIP responding with traceroute"; + } + uses monitor-stats { + description + "Stats of traceroute."; + } + description + "List of responses."; + } + } + } +} + + + <CODE ENDS> + + + + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 41] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + +6. Base Mode + + The Base Mode ("default mode" described in 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 + 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 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 in an automatic manner with no user + intervention. The IP address cannot be directly used for this + purpose, as the MEP-ID is a much smaller field. For the Base Mode of + operation, MEP-ID is set to zero by default. + + The CCM packet uses the MEP-ID in the payload. CCM MUST NOT be used + in the Base Mode. Hence, CCM MUST be disabled on the Maintenance + Association of the Base Mode. + + If CCM is required, users MUST configure a separate Maintenance + Association and assign unique values for the corresponding MEP IDs. + + CFM [IEEE802.1Q] defines MEP-ID as an unsigned integer in the range 1 + to 8191. In this document, we propose extending the range to 0 to + 65535. Value 0 is reserved for the MEP-ID 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). In the Base Mode + + + + + +Kumar, et al. Standards Track [Page 42] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + 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 OAM YANG Data Model Applicability + + The "ietf-connection-oriented-oam" module defined in this document + provides a technology-independent abstraction of key OAM constructs + for connection-oriented protocols. This module can be further + extended to include technology-specific details, e.g., adding new + data nodes with 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 for TRILL OAM + + The TRILL OAM YANG module [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 ([TRILL-YANG]) to be supported, as there is a strong + relationship between those modules. + + The configuration extensions for connection-oriented OAM include the + MD configuration extension, technology type extension, MA + configuration extension, Connectivity-Context extension, MEP + Configuration extension, and ECMP extension. In the RPC extension, + the continuity-check and path-discovery RPC are extended with TRILL- + specific parameters. + +7.1.1. MD Configuration Extension + + MD level configuration parameters are management information that can + be inherited in the TRILL OAM model and set by the connection- + oriented base model as default values. For example, domain name can + be set to area-ID in the TRILL OAM case. In addition, at the + Maintenance Domain Level (i.e., at root level), the domain data node + can be augmented with technology type. + + + + + +Kumar, et al. Standards Track [Page 43] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + Note that MD level configuration parameters provide context + information for the management system to correlate faults, defects, + and network failures with location 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, 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 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) level (i.e., at the second level), the + MA data node can be augmented with a connectivity-context extension. + + Note that MA level configuration parameters provide context + information for the management system to correlate faults, defects, + and network failures with location 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 + VLAN ID or a 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 + extensions. The snippet below depicts an example of augmenting + connectivity-context to include either a VLAN ID or 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 + + + +Kumar, et al. Standards Track [Page 44] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + +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 RBridge Nickname in TRILL OAM. Hence, + the TRILL OAM model augments the MEP configuration in the base model + to add a nickname case 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 End Point (MEP) level + (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 field in the 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 + + + + + + + + + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 45] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + +7.1.4. RPC Extension + + In the TRILL OAM YANG data model, the continuity-check and path- + discovery RPC commands are extended with TRILL-specific requirements. + The snippet below depicts an example of 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 for MPLS-TP OAM + + The MPLS-TP OAM YANG module can augment the connection-oriented OAM + module with some technology-specific details. [MPLS-TP-OAM-YANG] + presents the YANG data model for MPLS-TP OAM. + + The configuration extensions for connection-oriented OAM include the + MD configuration extension, Technology type extension, Technology + Subtype extension, MA configuration extension, and MEP Configuration + extension. + + + + + + +Kumar, et al. Standards Track [Page 46] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + +7.2.1. MD Configuration Extension + + MD level configuration parameters are management information that can + be inherited in the MPLS-TP OAM model and set by the connection- + oriented OAM base model as default values. For example, domain name + can be set to area-ID or the provider's Autonomous System Number + (ASN) [RFC6370] in the MPLS-TP OAM case. In addition, at the + Maintenance Domain Level (i.e., at root level), the domain data node + can be augmented with technology type and technology subtype. + + Note that MD level configuration parameters provide context + information for the management system to correlate faults, defects, + and network failures with location 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. Technology Subtype Extension + + In MPLS-TP, since different encapsulation types such as IP/UDP + encapsulation and PW-ACH encapsulation can be employed, the + "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 subtype + for IP/UDP encapsulation and PW-ACH encapsulation. Other + encapsulation types can be defined in the same way. The snippet + below depicts an example of several encapsulation types. + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 47] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + identity technology-sub-type { + description + "Certain implementations can have different + encapsulation types such as IP/UDP, PW-ACH, and so on. + Instead of defining separate models for each + encapsulation, we define a technology subtype to + further identify different encapsulations. + Technology subtype is associated at the MA level."; } + + identity technology-sub-type-udp { + base technology-sub-type; + description + "Technology subtype is IP/UDP encapsulation."; + } + + identity technology-sub-type-ach { + base technology-sub-type; + description + "Technology subtype is PW-ACH encapsulation."; + } + } + + augment "/co-oam:domains/co-oam:domain" + + "/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 that can + be inherited in the MPLS-TP OAM model and set by the connection- + oriented OAM base model as default values. Examples of MA Name are + MPLS-TP LSP MEG_ID, MEG Section ID, or MEG PW ID [RFC6370]. + + Note that MA level configuration parameters provide context + information for the management system to correlate faults, defects, + and network failures with location 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 label value in case of + G-ACH encapsulation or a 2-octet unsigned integer value in case of + IP/UDP encapsulation. One example of MEP-ID is MPLS-TP LSP_MEP_ID + + + +Kumar, et al. Standards Track [Page 48] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + [RFC6370]. In the connection-oriented base model, MEP-ID is defined + as a choice/case node that can support an int32 value, and the same + definition can be used for MPLS-TP with no further modification. In + addition, at the Maintenance association End Point (MEP) level (i.e., + at the third level), the MEP data node can be augmented with 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 + [RFC8446]. + + The 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 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) 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. This may lead to inconsistent + configuration, reporting, and presentation for the OAM mechanisms + used to manage the network. + + + + + + + +Kumar, et al. Standards Track [Page 49] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + +9. IANA Considerations + + This document registers a URI in the "IETF XML Registry" [RFC3688]. + The following registration has been made: + + URI: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam + Registrant Contact: The IESG. + XML: N/A; the requested URI is an XML namespace. + + This document registers a YANG module in the "YANG Module Names" + registry [RFC6020]. + + name: ietf-connection-oriented-oam + namespace: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam + prefix: co-oam + reference: RFC 8531 + +10. References + +10.1. Normative References + + [IEEE802.1Q] + IEEE, "IEEE Standard for Local and Metropolitan Area + Networks-Bridges and Bridged Networks", IEEE Std 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>. + + [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>. + + + + +Kumar, et al. Standards Track [Page 50] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + [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>. + + [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>. + + [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. + + [MEF-17] MEF Forum, "Service OAM Requirements & Framework - Phase + 1", MEF 17, April 2007. + + [MPLS-TP-OAM-YANG] + Zhang, L., Zheng, L., Aldrin, S., and G. Mirsky, "YANG + Data Model for MPLS-TP Operations, Administration, and + Maintenance (OAM)", Work in Progress, draft-zhang-mpls-tp- + yang-oam-05, October 2017. + + + + + +Kumar, et al. Standards Track [Page 51] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + [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>. + + [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>. + + + +Kumar, et al. Standards Track [Page 52] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + [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, April 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 + United States of America + + Email: nfinn@cisco.com + + + + + +Kumar, et al. Standards Track [Page 53] + +RFC 8531 Connection-Oriented OAM YANG Data Model April 2019 + + + 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 + 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 + 101 Software Avenue, Yuhua District + Nanjing 210012 + China + + Email: wangzitao@huawei.com + + + + + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 54] + |