RFC 8531
Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols
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
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.
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
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
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-nickname7.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.
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 failures7.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.
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
[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.
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 853110. 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>.
[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.
[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>.
[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
Samer Salam CISCO Systems 595 Burrard St. Suite 2123 Vancouver, BC V7X 1J1 Canada Email: ssalam@cisco.comAuthors' 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