rfc8531v1.txt   rfc8531.txt 
skipping to change at page 1, line 24 skipping to change at page 1, line 24
This document presents a base YANG data model for connection-oriented This document presents a base YANG data model for connection-oriented
Operations, Administration, and Maintenance (OAM) protocols. It Operations, Administration, and Maintenance (OAM) protocols. It
provides a technology-independent abstraction of key OAM constructs provides a technology-independent abstraction of key OAM constructs
for such protocols. The model presented here can be extended to for such protocols. The model presented here can be extended to
include technology-specific details. This guarantees uniformity in include technology-specific details. This guarantees uniformity in
the management of OAM protocols and provides support for nested OAM the management of OAM protocols and provides support for nested OAM
workflows (i.e., performing OAM functions at different levels through workflows (i.e., performing OAM functions at different levels through
a unified interface). a unified interface).
The YANG model in this document conforms to the Network Management The YANG data model in this document conforms to the Network
Datastore Architecture. Management Datastore Architecture.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6
3. Architecture of Generic YANG Model for Connection-Oriented 3. Architecture of Generic YANG Data Model for Connection-
OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Oriented OAM . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of the Connection-Oriented OAM YANG Model . . . . . 7 4. Overview of the Connection-Oriented OAM YANG Data Model . . . 7
4.1. Maintenance Domain (MD) Configuration . . . . . . . . . . 8 4.1. Maintenance Domain (MD) Configuration . . . . . . . . . . 8
4.2. Maintenance Association (MA) Configuration . . . . . . . 9 4.2. Maintenance Association (MA) Configuration . . . . . . . 9
4.3. Maintenance End Point (MEP) Configuration . . . . . . . . 9 4.3. Maintenance End Point (MEP) Configuration . . . . . . . . 9
4.4. RPC Definitions . . . . . . . . . . . . . . . . . . . . . 10 4.4. RPC Definitions . . . . . . . . . . . . . . . . . . . . . 10
4.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 13 4.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 13
4.6. Monitor Statistics . . . . . . . . . . . . . . . . . . . 13 4.6. Monitor Statistics . . . . . . . . . . . . . . . . . . . 13
4.7. OAM Data Hierarchy . . . . . . . . . . . . . . . . . . . 13 4.7. OAM Data Hierarchy . . . . . . . . . . . . . . . . . . . 13
5. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 5. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17
6. Base Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6. Base Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. MEP Address . . . . . . . . . . . . . . . . . . . . . . . 40 6.1. MEP Address . . . . . . . . . . . . . . . . . . . . . . . 40
6.2. MEP ID for Base Mode . . . . . . . . . . . . . . . . . . 40 6.2. MEP ID for Base Mode . . . . . . . . . . . . . . . . . . 40
6.3. Maintenance Association . . . . . . . . . . . . . . . . . 41 6.3. Maintenance Association . . . . . . . . . . . . . . . . . 41
7. Connection-Oriented OAM YANG Model Applicability . . . . . . 41 7. Connection-Oriented OAM YANG Data Model Applicability . . . . 41
7.1. Generic YANG Model Extension for TRILL OAM . . . . . . . 41 7.1. Generic YANG Data Model Extension for TRILL OAM . . . . . 41
7.1.1. MD Configuration Extension . . . . . . . . . . . . . 42 7.1.1. MD Configuration Extension . . . . . . . . . . . . . 42
7.1.2. MA Configuration Extension . . . . . . . . . . . . . 42 7.1.2. MA Configuration Extension . . . . . . . . . . . . . 42
7.1.3. MEP Configuration Extension . . . . . . . . . . . . . 43 7.1.3. MEP Configuration Extension . . . . . . . . . . . . . 43
7.1.4. RPC Extension . . . . . . . . . . . . . . . . . . . . 43 7.1.4. RPC Extension . . . . . . . . . . . . . . . . . . . . 43
7.2. Generic YANG Model Extension for MPLS-TP OAM . . . . . . 44 7.2. Generic YANG Data Model Extension for MPLS-TP OAM . . . . 44
7.2.1. MD Configuration Extension . . . . . . . . . . . . . 44 7.2.1. MD Configuration Extension . . . . . . . . . . . . . 44
7.2.2. MA Configuration Extension . . . . . . . . . . . . . 46 7.2.2. MA Configuration Extension . . . . . . . . . . . . . 46
7.2.3. MEP Configuration Extension . . . . . . . . . . . . . 46 7.2.3. MEP Configuration Extension . . . . . . . . . . . . . 46
8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1. Normative References . . . . . . . . . . . . . . . . . . 48 10.1. Normative References . . . . . . . . . . . . . . . . . . 48
10.2. Informative References . . . . . . . . . . . . . . . . . 49 10.2. Informative References . . . . . . . . . . . . . . . . . 49
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 51 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 51
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
Operations, Administration, and Maintenance (OAM) are important Operations, Administration, and Maintenance (OAM) are important
networking functions that allow operators to: networking functions that allow operators to:
1. monitor network connections (connectivity verification, 1. monitor network connections (i.e., reachability verification and
continuity check), Continuity Check),
2. troubleshoot failures (fault verification and localization), and 2. troubleshoot failures (i.e., fault verification and localization)
3. monitor performance. 3. monitor service-level agreements and performance (i.e.,
performance management)
An overview of OAM tools is presented in [RFC7276]. Over the years, An overview of OAM tools is presented in [RFC7276]. Over the years,
many technologies have developed similar tools for fault and many technologies have developed similar tools for fault and
performance management. performance management.
The different sets of OAM tools may support both connection-oriented The different sets of OAM tools may support both connection-oriented
technologies or connectionless technologies. In connection-oriented technologies or connectionless technologies. In connection-oriented
technologies, a connection is established prior to the transmission technologies, a connection is established prior to the transmission
of data. After the connection is established, no additional control of data. After the connection is established, no additional control
information such as signaling or operations and maintenance information such as signaling or operations and maintenance
skipping to change at page 3, line 46 skipping to change at page 3, line 47
Transport Profile (MPLS-TP) [RFC6371], and Transparent Transport Profile (MPLS-TP) [RFC6371], and Transparent
Interconnection of Lots of Links (TRILL) [RFC7455] all define OAM Interconnection of Lots of Links (TRILL) [RFC7455] all define OAM
mechanisms based on the manageability framework of Connectivity Fault mechanisms based on the manageability framework of Connectivity Fault
Management (CFM) [IEEE802.1Q]. Management (CFM) [IEEE802.1Q].
Given the wide adoption of the underlying OAM concepts defined in CFM Given the wide adoption of the underlying OAM concepts defined in CFM
[IEEE802.1Q], it is a reasonable choice to develop the unified [IEEE802.1Q], it is a reasonable choice to develop the unified
management framework for connection-oriented OAM based on those management framework for connection-oriented OAM based on those
concepts. In this document, we take the CFM [IEEE802.1Q] model and concepts. In this document, we take the CFM [IEEE802.1Q] model and
extend it to a technology-independent framework and define the extend it to a technology-independent framework and define the
corresponding YANG model accordingly. The YANG model presented in corresponding YANG data model accordingly. The YANG data model
this document is the base model for connection-oriented OAM protocols presented in this document is the base model for connection-oriented
and supports generic continuity check, connectivity verification, and OAM protocols and supports generic continuity check, connectivity
path discovery (traceroute). The generic YANG model for connection- verification, and path discovery (traceroute). The generic YANG data
oriented OAM is designed to be extensible to other connection- model for connection-oriented OAM is designed to be extensible to
oriented technologies. Technology-dependent nodes and remote other connection-oriented technologies. Technology-dependent nodes
procedure call (RPC) commands are defined in technology-specific YANG and remote procedure call (RPC) commands are defined in technology-
models, which use and extend the base model defined here. As an specific YANG data models, which use and extend the base model
example, Virtual eXtensible Local Area Network (VXLAN) uses the defined here. As an example, Virtual eXtensible Local Area Network
source UDP port number for flow entropy, while TRILL uses either (a) (VXLAN) uses the source UDP port number for flow entropy, while TRILL
MAC addresses, (b) the VLAN tag or Fine-Grained Label, and/or (c) IP uses either (a) MAC addresses, (b) the VLAN tag or Fine-Grained
addresses for flow entropy in the hashing for multipath selection. Label, and/or (c) IP addresses for flow entropy in the hashing for
To capture this variation, corresponding YANG models would define the multipath selection. To capture this variation, corresponding YANG
applicable structures as augmentation to the generic base model data models would define the applicable structures as augmentation to
presented here. This accomplishes three goals: First, it keeps each the generic base model presented here. This accomplishes three
YANG model smaller and more manageable. Second, it allows goals: First, it keeps each YANG data model smaller and more
independent development of corresponding YANG models. Third, manageable. Second, it allows independent development of
implementations can limit support to only the applicable set of YANG corresponding YANG data models. Third, implementations can limit
models (e.g., TRILL RBridge may only need to implement the generic support to only the applicable set of YANG data models (e.g., TRILL
model and the TRILL YANG model). 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 The YANG data model presented in this document is generated at the
management layer. Encapsulations and state machines may differ management layer. Encapsulations and state machines may differ
according to each OAM protocol. A user who wishes to issue a according to each OAM protocol. A user who wishes to issue a
Continuity Check command or a Loopback or initiate a performance Continuity Check command or a Loopback or initiate a performance
monitoring session can do so in the same manner, regardless of the monitoring session can do so in the same manner, regardless of the
underlying protocol or technology or specific vendor implementation. underlying protocol or technology or specific vendor implementation.
As an example, consider a scenario where connectivity from device A As an example, consider a scenario where connectivity from device A
loopback to device B fails. Between device A and B there are IEEE 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 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 [IEEE802.1Q]. A user, upon detecting the loopback failure, may
decide to drill down to the lower level at different segments of the decide to drill down to the lower level at different segments of the
path and issue the corresponding fault verification (Loopback path and issue the corresponding fault verification (Loopback
Message) and fault isolation (Looktrace Message) tools, using the Message) and fault isolation (Looktrace Message) tools, using the
same API. This ability to drill down to a lower layer of 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 protocol stack at a specific segment within a path for fault
localization and troubleshooting is referred to as "nested OAM localization and troubleshooting is referred to as "nested OAM
workflow". It is a useful concept that leads to efficient network workflow". It is a useful concept that leads to efficient network
troubleshooting and maintenance workflows. The connection-oriented troubleshooting and maintenance workflows. The connection-oriented
OAM YANG model presented in this document facilitates that without OAM YANG data model presented in this document facilitates that
needing changes to the underlying protocols. without needing changes to the underlying protocols.
The YANG model in this document conforms to the Network Management The YANG data model in this document conforms to the Network
Datastore Architecture defined in [RFC8342]. Management Datastore Architecture defined in [RFC8342].
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Many of the terms used in this document (including those set out in Many of the terms used in this document (including those set out in
skipping to change at page 5, line 24 skipping to change at page 5, line 24
CCM - Continuity Check Message [IEEE802.1Q] CCM - Continuity Check Message [IEEE802.1Q]
ECMP - Equal-Cost Multipath ECMP - Equal-Cost Multipath
LBM - Loopback Message [IEEE802.1Q] LBM - Loopback Message [IEEE802.1Q]
LTM - Linktrace Message [IEEE802.1Q] LTM - Linktrace Message [IEEE802.1Q]
MP - Maintenance Point [IEEE802.1Q] MP - Maintenance Point [IEEE802.1Q]
MEP - Maintenance End Point [RFC7174] (Maintenance association End MEP - Maintenance End Point [RFC7174] (also known as Maintenance
Point [IEEE802.1Q], MEG End Point [RFC6371]) association End Point [IEEE802.1Q] and MEG End Point [RFC6371])
MIP - Maintenance Intermediate Point [RFC7174] (Maintenance domain MIP - Maintenance Intermediate Point [RFC7174] (also known as
Intermediate Point [IEEE802.1Q], MEG Intermediate Point Maintenance domain Intermediate Point [IEEE802.1Q] and MEG
[RFC6371]) Intermediate Point [RFC6371])
MA - Maintenance Association [IEEE802.1Q] [RFC7174] MA - Maintenance Association [IEEE802.1Q] [RFC7174]
MD - Maintenance Domain [IEEE802.1Q] MD - Maintenance Domain [IEEE802.1Q]
MEG - Maintenance Entity Group [RFC6371] MEG - Maintenance Entity Group [RFC6371]
MTV - Multi-destination Tree Verification Message MTV - Multi-destination Tree Verification Message
OAM - Operations, Administration, and Maintenance [RFC6291] OAM - Operations, Administration, and Maintenance [RFC6291]
skipping to change at page 6, line 31 skipping to change at page 6, line 31
On-demand OAM - On-demand OAM refers to OAM actions that are On-demand OAM - On-demand OAM refers to OAM actions that are
initiated via manual intervention for a limited time to carry out initiated via manual intervention for a limited time to carry out
diagnostics. An on-demand OAM method requires only transient diagnostics. An on-demand OAM method requires only transient
configuration. configuration.
2.3. Tree Diagrams 2.3. Tree Diagrams
Tree diagrams used in this document follow the notation defined in Tree diagrams used in this document follow the notation defined in
[RFC8340]. [RFC8340].
3. Architecture of Generic YANG Model for Connection-Oriented OAM 3. Architecture of Generic YANG Data Model for Connection-Oriented OAM
In this document, we define a generic YANG model for connection- In this document, we define a generic YANG data model for connection-
oriented OAM protocols. The YANG model defined here is generic in a oriented OAM protocols. The YANG data model defined here is generic
sense that other technologies can extend it for technology-specific in a sense that other technologies can extend it for technology-
needs. The generic YANG model for connection-oriented OAM acts as specific needs. The generic YANG data model for connection-oriented
the root for other OAM YANG models. This allows users to traverse OAM acts as the root for other OAM YANG data models. This allows
between different OAM protocols with ease through a uniform API set. users to traverse between different OAM protocols with ease through a
This also enables a nested OAM workflow. Figure 1 depicts the uniform API set. This also enables a nested OAM workflow. Figure 1
relationship of different OAM YANG models to the Generic YANG Model depicts the relationship of different OAM YANG data models to the
for connection-oriented OAM. The Generic YANG model for connection- Generic YANG Data Model for connection-oriented OAM. The Generic
oriented OAM provides a framework where technology-specific YANG YANG data model for connection-oriented OAM provides a framework
models can inherit constructs from the base YANG models without where technology-specific YANG data models can inherit constructs
needing to redefine them within the sub-technology. from the base YANG data models without needing to redefine them
within the sub-technology.
+-----------+ +-----------+
|Connection-| |Connection-|
| Oriented | | Oriented |
| generic | | generic |
| OAM YANG | | OAM YANG |
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| |
| |
| |
skipping to change at page 7, line 31 skipping to change at page 7, line 31
| | +-+-+-+-+-+ | | +-+-+-+-+-+
| | . . .| foo | | | . . .| foo |
| | |sub tech | | | |sub tech |
| | +-+-+-+-+-+ | | +-+-+-+-+-+
| | | | | |
| | | | | |
+-------------------------------------------------------+ +-------------------------------------------------------+
| Uniform API | | Uniform API |
+-------------------------------------------------------+ +-------------------------------------------------------+
Figure 1: Relationship of OAM YANG Model to Generic (Base) YANG Model Figure 1: Relationship of OAM YANG Data Model to Generic (Base) YANG
Data Model
4. Overview of the Connection-Oriented OAM YANG Model 4. Overview of the Connection-Oriented OAM YANG Data Model
In this document, we adopt the concepts of the CFM [IEEE802.1Q] 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- and structure such that it can be adapted to different connection-
oriented OAM protocols. oriented OAM protocols.
At the top of the model is the Maintenance Domain. Each Maintenance At the top of the model is the Maintenance Domain. Each Maintenance
Domain is associated with a Maintenance Name and a Domain Level. Domain is associated with a Maintenance Name and a Domain Level.
Under each Maintenance Domain, there is one or more Maintenance Under each Maintenance Domain, there is one or more Maintenance
Associations (MAs). In TRILL, the MA can correspond to a Fine- Associations (MAs). In TRILL, the MA can correspond to a Fine-
Grained Label. Grained Label.
Under each MA, there can be two or more MEPs (Maintenance End Under each MA, there can be two or more MEPs (Maintenance End
Points). MEPs are addressed by their respective technology-specific Points). MEPs are addressed by their respective technology-specific
address identifiers. The YANG model presented here provides address identifiers. The YANG data model presented here provides
flexibility to accommodate different addressing schemes. flexibility to accommodate different addressing schemes.
Commands are presented in the management protocol, which is Commands are presented in the management protocol, which is
orthogonal to the Maintenance Domain. These are RPC commands, in orthogonal to the Maintenance Domain. These are RPC commands, in
YANG terms. They provide uniform APIs for continuity check, YANG terms. They provide uniform APIs for continuity check,
connectivity verification, path discovery (traceroute), and their connectivity verification, path discovery (traceroute), and their
equivalents, as well as other OAM commands. equivalents, as well as other OAM commands.
The OAM entities in the generic YANG model defined here will be The OAM entities in the generic YANG data model defined here will be
either explicitly or implicitly configured using any of the OAM either explicitly or implicitly configured using any of the OAM
tools. The OAM tools used here are limited to the OAM toolset tools. The OAM tools used here are limited to the OAM toolset
specified in Section 5.1 of [RFC7276]. In order to facilitate a specified in Section 5.1 of [RFC7276]. In order to facilitate a
zero-touch experience, this document defines a default mode of OAM. zero-touch experience, this document defines a default mode of OAM.
The default mode of OAM is referred to as the "Base Mode" and 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 specifies default values for each of the model's parameters, such as
Maintenance Domain Level, Name of the Maintenance Association, Maintenance Domain Level, Name of the Maintenance Association,
Addresses of MEPs, and so on. The default values of these depend on Addresses of MEPs, and so on. The default values of these depend on
the technology. Base Mode for TRILL is defined in [RFC7455]. Base the technology. Base Mode for TRILL is defined in [RFC7455]. Base
Mode for other technologies and future extensions developed in IETF Mode for other technologies and future extensions developed in IETF
will be defined in their corresponding documents. will be defined in their corresponding documents.
It is important to note that no specific enhancements are needed in It is important to note that no specific enhancements are needed in
the YANG model to support Base Mode. Implementations that comply the YANG data model to support Base Mode. Implementations that
with this document use, by default, the data nodes of the applicable comply with this document use, by default, the data nodes of the
technology. Data nodes of the Base Mode are read-only nodes. applicable technology. Data nodes of the Base Mode are read-only
nodes.
4.1. Maintenance Domain (MD) Configuration 4.1. Maintenance Domain (MD) Configuration
The container "domains" is the top-level container within the "gen- The container "domains" is the top-level container within the "gen-
oam" module. Within the container "domains", a separate list is oam" module. Within the container "domains", a separate list is
maintained per MD. The MD list uses the key "md-name-string" for 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 indexing. The "md-name-string" is a leaf and derived from type
string. Additional name formats as defined in [IEEE802.1Q], or other string. Additional name formats as defined in [IEEE802.1Q], or other
standards, can be included by association of the "md-name-format" standards, can be included by association of the "md-name-format"
with an identity-ref. The "md-name-format" indicates the format of with an identity-ref. The "md-name-format" indicates the format of
skipping to change at page 13, line 17 skipping to change at page 13, line 17
4.5. Notifications 4.5. Notifications
Notification is sent upon detecting a defect condition and upon Notification is sent upon detecting a defect condition and upon
clearing a defect with a Maintenance Domain Name, MA Name, defect- clearing a defect with a Maintenance Domain Name, MA Name, defect-
type (the currently active defects), generating-mepid, and defect- type (the currently active defects), generating-mepid, and defect-
message to indicate more details. message to indicate more details.
4.6. Monitor Statistics 4.6. Monitor Statistics
Grouping for monitoring statistics is to be used by technology- Grouping for monitoring statistics is to be used by technology-
specific YANG modules that augment the generic YANG model to provide specific YANG modules that augment the generic YANG data model to
statistics due to proactive OAM-like Continuity Check Messages -- for provide statistics due to proactive OAM-like Continuity Check
example, CCM transmit, CCM receive, CCM error, etc. Messages -- for example, CCM transmit, CCM receive, CCM error, etc.
4.7. OAM Data Hierarchy 4.7. OAM Data Hierarchy
The complete data hierarchy related to the connection-oriented OAM The complete data hierarchy related to the connection-oriented OAM
YANG model is presented below. YANG data model is presented below.
module: ietf-connection-oriented-oam module: ietf-connection-oriented-oam
+--rw domains +--rw domains
+--rw domain* [technology md-name-string] +--rw domain* [technology md-name-string]
+--rw technology identityref +--rw technology identityref
+--rw md-name-string md-name-string +--rw md-name-string md-name-string
+--rw md-name-format? identityref +--rw md-name-format? identityref
+--rw (md-name)? +--rw (md-name)?
| +--:(md-name-null) | +--:(md-name-null)
| +--rw md-name-null? empty | +--rw md-name-null? empty
skipping to change at page 18, line 16 skipping to change at page 18, line 16
Editor: Deepak Kumar <dekumar@cisco.com> Editor: Deepak Kumar <dekumar@cisco.com>
Editor: Qin Wu <bill.wu@huawei.com> Editor: Qin Wu <bill.wu@huawei.com>
Editor: Michael Wang <wangzitao@huawei.com>"; Editor: Michael Wang <wangzitao@huawei.com>";
description description
"This YANG module defines the generic configuration, "This YANG module defines the generic configuration,
statistics and RPC for connection-oriented OAM statistics and RPC for connection-oriented OAM
to be used within IETF in a protocol-independent manner. to be used within IETF in a protocol-independent manner.
Functional-level abstraction is independent Functional-level abstraction is independent
with YANG modeling. It is assumed that each protocol with YANG modeling. It is assumed that each protocol
maps corresponding abstracts to its native format. maps corresponding abstracts to its native format.
Each protocol may extend the YANG model defined Each protocol may extend the YANG data model defined
here to include protocol-specific extensions here to include protocol-specific extensions
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
skipping to change at page 20, line 25 skipping to change at page 20, line 25
are detected when a certain number of expected messages are not are detected when a certain number of expected messages are not
received. A proactive OAM method requires persistent received. A proactive OAM method requires persistent
configuration."; configuration.";
reference reference
"RFC 7276: An Overview of Operations, Administration, and "RFC 7276: An Overview of Operations, Administration, and
Maintenance (OAM) Tools"; Maintenance (OAM) Tools";
} }
identity name-format { identity name-format {
description description
"This defines the name format, CFM (IEEE 802.1ag) defines varying "This defines the name format, CFM (IEEE 802.1Q) defines varying
styles of names. It is expected that name format is an identity styles of names. It is expected that name format is an identity
reference to be extended with new types."; reference to be extended with new types.";
} }
identity name-format-null { identity name-format-null {
base name-format; base name-format;
description description
"Defines name format as null."; "Defines name format as null.";
} }
skipping to change at page 23, line 7 skipping to change at page 23, line 7
description description
"Define 32-bit counter for OAM."; "Define 32-bit counter for OAM.";
} }
typedef md-level { typedef md-level {
type uint32 { type uint32 {
range "0..255"; range "0..255";
} }
description description
"Maintenance Domain level. The level may be restricted in "Maintenance Domain Level. The level may be restricted in
certain protocols (e.g., protocol in layer 0 to layer 7)."; certain protocols (e.g., protocol in layer 0 to layer 7).";
} }
grouping maintenance-domain-reference { grouping maintenance-domain-reference {
description description
"This grouping uniquely identifies a Maintenance Domain."; "This grouping uniquely identifies a Maintenance Domain.";
leaf maintenance-domain { leaf maintenance-domain {
type leafref { type leafref {
path "/co-oam:domains/co-oam:domain/co-oam:md-name-string"; path "/co-oam:domains/co-oam:domain/co-oam:md-name-string";
} }
skipping to change at page 34, line 42 skipping to change at page 34, line 42
} }
mandatory true; mandatory true;
description description
"Indicate which MD the defect belongs to."; "Indicate which MD the defect belongs to.";
} }
leaf md-level { leaf md-level {
type leafref { type leafref {
path "/domains/domain/md-level"; path "/domains/domain/md-level";
} }
description description
"The maintenance domain level."; "The Maintenance Domain Level.";
} }
leaf ma-name-string { leaf ma-name-string {
type leafref { type leafref {
path "/domains/domain/mas/ma/ma-name-string"; path "/domains/domain/mas/ma/ma-name-string";
} }
mandatory true; mandatory true;
description description
"Indicate which MA the defect is associated with."; "Indicate which MA the defect is associated with.";
} }
uses cos; uses cos;
skipping to change at page 36, line 10 skipping to change at page 36, line 10
uses monitor-stats { uses monitor-stats {
description description
"Stats of continuity check."; "Stats of continuity check.";
} }
} }
} }
rpc continuity-verification { rpc continuity-verification {
if-feature "connectivity-verification"; if-feature "connectivity-verification";
description description
"Generates Continuity Verification as per Table 4 in RFC 7276."; "Generates Connectivity Verification as per Table 4 in RFC 7276.";
input { input {
leaf md-name-string { leaf md-name-string {
type leafref { type leafref {
path "/domains/domain/md-name-string"; path "/domains/domain/md-name-string";
} }
mandatory true; mandatory true;
description description
"Indicate which MD the defect belongs to."; "Indicate which MD the defect belongs to.";
} }
leaf md-level { leaf md-level {
type leafref { type leafref {
path "/domains/domain/md-level"; path "/domains/domain/md-level";
} }
description description
"The maintenance domain level."; "The Maintenance Domain Level.";
} }
leaf ma-name-string { leaf ma-name-string {
type leafref { type leafref {
path "/domains/domain/mas/ma/ma-name-string"; path "/domains/domain/mas/ma/ma-name-string";
} }
mandatory true; mandatory true;
description description
"Indicate which MA the defect is associated with."; "Indicate which MA the defect is associated with.";
} }
uses cos; uses cos;
skipping to change at page 38, line 12 skipping to change at page 38, line 12
} }
mandatory true; mandatory true;
description description
"Indicate which MD the defect belongs to."; "Indicate which MD the defect belongs to.";
} }
leaf md-level { leaf md-level {
type leafref { type leafref {
path "/domains/domain/md-level"; path "/domains/domain/md-level";
} }
description description
"The maintenance domain level."; "The Maintenance Domain Level.";
} }
leaf ma-name-string { leaf ma-name-string {
type leafref { type leafref {
path "/domains/domain/mas/ma/ma-name-string"; path "/domains/domain/mas/ma/ma-name-string";
} }
mandatory true; mandatory true;
description description
"Indicate which MA the defect is associated with."; "Indicate which MA the defect is associated with.";
} }
uses cos; uses cos;
skipping to change at page 41, line 16 skipping to change at page 41, line 16
The ID of the Maintenance Association (MA-ID) [IEEE802.1Q] has a The ID of the Maintenance Association (MA-ID) [IEEE802.1Q] has a
flexible format and includes two parts: Maintenance Domain Name and flexible format and includes two parts: Maintenance Domain Name and
Short MA name. In the Base Mode of operation, the value of the Short MA name. In the Base Mode of operation, the value of the
Maintenance Domain Name must be the character string Maintenance Domain Name must be the character string
"GenericBaseMode" (excluding the quotes). In the Base Mode "GenericBaseMode" (excluding the quotes). In the Base Mode
operation, the Short MA Name format is set to a 2-octet integer 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 format (value 3 in Short MA Format field [IEEE802.1Q]) and the Short
MA name is set to 65532 (0xFFFC). MA name is set to 65532 (0xFFFC).
7. Connection-Oriented OAM YANG Model Applicability 7. Connection-Oriented OAM YANG Data Model Applicability
The "ietf-connection-oriented-oam" module defined in this document The "ietf-connection-oriented-oam" module defined in this document
provides a technology-independent abstraction of key OAM constructs provides a technology-independent abstraction of key OAM constructs
for connection-oriented protocols. This module can be further for connection-oriented protocols. This module can be further
extended to include technology-specific details, e.g., adding new extended to include technology-specific details, e.g., adding new
data nodes with technology-specific functions and parameters into data nodes with technology-specific functions and parameters into
proper anchor points of the base model, so as to develop a proper anchor points of the base model, so as to develop a
technology-specific connection-oriented OAM model. technology-specific connection-oriented OAM model.
This section demonstrates the usability of the connection-oriented This section demonstrates the usability of the connection-oriented
YANG OAM data model to various connection-oriented OAM technologies, YANG OAM data model to various connection-oriented OAM technologies,
e.g., TRILL and MPLS-TP. Note that, in this section, we only present e.g., TRILL and MPLS-TP. Note that, in this section, we only present
several snippets of technology-specific model extensions for several snippets of technology-specific model extensions for
illustrative purposes. The complete model extensions should be illustrative purposes. The complete model extensions should be
worked on in respective protocol working groups. worked on in respective protocol working groups.
7.1. Generic YANG Model Extension for TRILL OAM 7.1. Generic YANG Data Model Extension for TRILL OAM
The TRILL OAM YANG module [TRILL-YANG-OAM] is augmenting the The TRILL OAM YANG module [TRILL-YANG-OAM] is augmenting the
connection-oriented OAM module for both configuration and RPC connection-oriented OAM module for both configuration and RPC
commands. commands.
In addition,the TRILL OAM YANG module also requires the base TRILL In addition,the TRILL OAM YANG module also requires the base TRILL
module ([TRILL-YANG]) to be supported, as there is a strong module ([TRILL-YANG]) to be supported, as there is a strong
relationship between those modules. relationship between those modules.
The configuration extensions for connection-oriented OAM include the The configuration extensions for connection-oriented OAM include the
skipping to change at page 42, line 11 skipping to change at page 42, line 11
Configuration extension, and ECMP extension. In the RPC extension, Configuration extension, and ECMP extension. In the RPC extension,
the continuity-check and path-discovery RPC are extended with TRILL- the continuity-check and path-discovery RPC are extended with TRILL-
specific parameters. specific parameters.
7.1.1. MD Configuration Extension 7.1.1. MD Configuration Extension
MD level configuration parameters are management information that can MD level configuration parameters are management information that can
be inherited in the TRILL OAM model and set by the connection- be inherited in the TRILL OAM model and set by the connection-
oriented base model as default values. For example, domain name can 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 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 Maintenance Domain Level (i.e., at root level), the domain data node
can be augmented with technology type. can be augmented with technology type.
Note that MD level configuration parameters provide context Note that MD level configuration parameters provide context
information for the management system to correlate faults, defects, information for the management system to correlate faults, defects,
and network failures with location information; this helps quickly and network failures with location information; this helps quickly
identify root causes of network failures. identify root causes of network failures.
7.1.1.1. Technology Type Extension 7.1.1.1. Technology Type Extension
No TRILL technology type has been defined in the connection-oriented No TRILL technology type has been defined in the connection-oriented
skipping to change at page 43, line 48 skipping to change at page 43, line 48
augment /co-oam:domains/co-oam:domain augment /co-oam:domains/co-oam:domain
/co-oam:mas/co-oam:ma/co-oam:mep: /co-oam:mas/co-oam:ma/co-oam:mep:
+--rw flow-entropy-trill? flow-entropy-trill +--rw flow-entropy-trill? flow-entropy-trill
augment /co-oam:domains/co-oam:domain augment /co-oam:domains/co-oam:domain
/co-oam:mas/co-oam:ma/co-oam:mep/co-oam:session: /co-oam:mas/co-oam:ma/co-oam:mep/co-oam:session:
+--rw flow-entropy-trill? flow-entropy-trill +--rw flow-entropy-trill? flow-entropy-trill
7.1.4. RPC Extension 7.1.4. RPC Extension
In the TRILL OAM YANG model, the continuity-check and path-discovery In the TRILL OAM YANG data model, the continuity-check and path-
RPC commands are extended with TRILL-specific requirements. The discovery RPC commands are extended with TRILL-specific requirements.
snippet below depicts an example of the TRILL OAM RPC extension. The snippet below depicts an example of the TRILL OAM RPC extension.
augment /co-oam:continuity-check/co-oam:input: augment /co-oam:continuity-check/co-oam:input:
+--ro (out-of-band)? +--ro (out-of-band)?
| +--:(ipv4-address) | +--:(ipv4-address)
| | +--ro ipv4-address? inet:ipv4-address | | +--ro ipv4-address? inet:ipv4-address
| +--:(ipv6-address) | +--:(ipv6-address)
| | +--ro ipv6-address? inet:ipv6-address | | +--ro ipv6-address? inet:ipv6-address
| +--:(trill-nickname) | +--:(trill-nickname)
| +--ro trill-nickname? tril-rb-nickname | +--ro trill-nickname? tril-rb-nickname
+--ro diagnostic-vlan? boolean +--ro diagnostic-vlan? boolean
skipping to change at page 44, line 34 skipping to change at page 44, line 34
| | +--ro ipv6-address? inet:ipv6-address | | +--ro ipv6-address? inet:ipv6-address
| +--:(trill-nickname) | +--:(trill-nickname)
| +--ro trill-nickname? tril-rb-nickname | +--ro trill-nickname? tril-rb-nickname
+--ro diagnostic-vlan? boolean +--ro diagnostic-vlan? boolean
augment /co-oam:path-discovery/co-oam:input: augment /co-oam:path-discovery/co-oam:input:
+--ro flow-entropy-trill? flow-entropy-trill +--ro flow-entropy-trill? flow-entropy-trill
augment /co-oam:path-discovery/co-oam:output/co-oam:response: augment /co-oam:path-discovery/co-oam:output/co-oam:response:
+--ro upstream-rbridge? tril-rb-nickname +--ro upstream-rbridge? tril-rb-nickname
+--ro next-hop-rbridge* tril-rb-nickname +--ro next-hop-rbridge* tril-rb-nickname
7.2. Generic YANG Model Extension for MPLS-TP OAM 7.2. Generic YANG Data Model Extension for MPLS-TP OAM
The MPLS-TP OAM YANG module can augment the connection-oriented OAM The MPLS-TP OAM YANG module can augment the connection-oriented OAM
module with some technology-specific details. [MPLS-TP-OAM-YANG] module with some technology-specific details. [MPLS-TP-OAM-YANG]
presents the YANG data model for MPLS-TP OAM. presents the YANG data model for MPLS-TP OAM.
The configuration extensions for connection-oriented OAM include the The configuration extensions for connection-oriented OAM include the
MD configuration extension, Technology type extension, Technology MD configuration extension, Technology type extension, Technology
Subtype extension, MA configuration extension, and MEP Configuration Subtype extension, MA configuration extension, and MEP Configuration
extension. extension.
7.2.1. MD Configuration Extension 7.2.1. MD Configuration Extension
MD level configuration parameters are management information that can MD level configuration parameters are management information that can
be inherited in the MPLS-TP OAM model and set by the connection- be inherited in the MPLS-TP OAM model and set by the connection-
oriented OAM base model as default values. For example, domain name oriented OAM base model as default values. For example, domain name
can be set to area-ID or the provider's Autonomous System Number 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 (ASN) [RFC6370] in the MPLS-TP OAM case. In addition, at the
Maintenance Domain level (i.e., at root level), the domain data node Maintenance Domain Level (i.e., at root level), the domain data node
can be augmented with technology type and technology subtype. can be augmented with technology type and technology subtype.
Note that MD level configuration parameters provide context Note that MD level configuration parameters provide context
information for the management system to correlate faults, defects, information for the management system to correlate faults, defects,
and network failures with location information; this helps quickly and network failures with location information; this helps quickly
identify root causes of network failures identify root causes of network failures
7.2.1.1. Technology Type Extension 7.2.1.1. Technology Type Extension
No MPLS-TP technology type has been defined in the connection- No MPLS-TP technology type has been defined in the connection-
skipping to change at page 51, line 34 skipping to change at page 51, line 34
draft-ietf-trill-yang-04, December 2015. draft-ietf-trill-yang-04, December 2015.
[TRILL-YANG-OAM] [TRILL-YANG-OAM]
Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L.,
and H. Weiguo, "YANG Data Model for TRILL Operations, and H. Weiguo, "YANG Data Model for TRILL Operations,
Administration, and Maintenance (OAM)", Work in Progress, Administration, and Maintenance (OAM)", Work in Progress,
draft-ietf-trill-yang-oam-05, March 2017. draft-ietf-trill-yang-oam-05, March 2017.
Acknowledgments Acknowledgments
Giles Heron came up with the idea of developing a YANG model as a way Giles Heron came up with the idea of developing a YANG data model as
of creating a unified OAM API set (interface); this document was a way of creating a unified OAM API set (interface); this document
largely inspired by that. Alexander Clemm provided many valuable was largely inspired by that. Alexander Clemm provided many valuable
tips, comments, and remarks that helped to refine the YANG model tips, comments, and remarks that helped to refine the YANG data model
presented in this document. presented in this document.
Carlos Pignataro, David Ball, Mahesh Jethanandani, Benoit Claise, Carlos Pignataro, David Ball, Mahesh Jethanandani, Benoit Claise,
Ladislav Lhotka, Jens Guballa, Yuji Tochio, Gregory Mirsky, Huub van Ladislav Lhotka, Jens Guballa, Yuji Tochio, Gregory Mirsky, Huub van
Helvoort, Tom Taylor, Dapeng Liu, Mishael Wexler, and Adi Molkho Helvoort, Tom Taylor, Dapeng Liu, Mishael Wexler, and Adi Molkho
contributed to and participated in the development of this document. contributed to and participated in the development of this document.
Contributors Contributors
Tissa Senevirathne Tissa Senevirathne
Consultant Consultant
 End of changes. 35 change blocks. 
84 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/