< draft-ietf-lime-yang-oam-model-01.txt   draft-ietf-lime-yang-oam-model-02.txt >
Network Working Group T. Senevirathne Network Working Group T. Senevirathne
Internet-Draft Consultant Internet-Draft Consultant
Intended status: Standards Track N. Finn Intended status: Standards Track N. Finn
Expires: May 30, 2016 D. Kumar, Ed. Expires: September 1, 2016 D. Kumar, Ed.
S. Salam S. Salam
Cisco Cisco
Q. Wu, Ed. Q. Wu, Ed.
M. Wang M. Wang
Huawei Huawei
November 27, 2015 February 29, 2016
Generic YANG Data Model for Operations, Administration, and Maintenance Generic YANG Data Model for Connection Oriented Operations,
(OAM) Administration, and Maintenance(OAM) protocols
draft-ietf-lime-yang-oam-model-01 draft-ietf-lime-yang-oam-model-02
Abstract Abstract
This document presents base YANG Data model for OAM. It provides a This document presents a base YANG Data model for connection oriented
protocol-independent and technology-independent abstraction of key OAM protocols. It provides a technology-independent abstraction of
OAM constructs. Based model presented here can be extended to key OAM constructs for connection oriented protocols. Based model
include technology specific details. This is leading to uniformity presented here can be extended to include technology specific
between OAM technologies and support nested OAM workflows (i.e., details. This is leading to uniformity between OAM protocols and
performing OAM functions at different layers through a unified support nested OAM workflows (i.e., performing OAM functions at
interface). different levels through a unified interface).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 30, 2016. This Internet-Draft will expire on September 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture of Generic YANG Model for OAM . . . . . . . . . 6 3. Architecture of Generic YANG Model for OAM . . . . . . . . . 6
4. Overview of the OAM Model . . . . . . . . . . . . . . . . . . 7 4. Overview of the OAM Model . . . . . . . . . . . . . . . . . . 7
4.1. Maintenance Domain (MD) configuration . . . . . . . . . . 8 4.1. Maintenance Domain (MD) configuration . . . . . . . . . . 7
4.2. Maintenance Association (MA) configuration . . . . . . . 8 4.2. Maintenance Association (MA) configuration . . . . . . . 8
4.3. Maintenance Endpoint (MEP) configuration . . . . . . . . 9 4.3. Maintenance Endpoint (MEP) configuration . . . . . . . . 9
4.4. rpc definitions . . . . . . . . . . . . . . . . . . . . . 9 4.4. rpc definitions . . . . . . . . . . . . . . . . . . . . . 9
4.5. OAM data hierarchy . . . . . . . . . . . . . . . . . . . 12 4.5. OAM data hierarchy . . . . . . . . . . . . . . . . . . . 12
5. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 5. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17
6. Base Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6. Base Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.1. MEP Address . . . . . . . . . . . . . . . . . . . . . . . 41 6.1. MEP Address . . . . . . . . . . . . . . . . . . . . . . . 41
6.2. MEP ID for Base Mode . . . . . . . . . . . . . . . . . . 42 6.2. MEP ID for Base Mode . . . . . . . . . . . . . . . . . . 41
6.3. Maintenance Domain . . . . . . . . . . . . . . . . . . . 42 6.3. Maintenance Domain . . . . . . . . . . . . . . . . . . . 41
6.4. Maintenance Association . . . . . . . . . . . . . . . . . 42 6.4. Maintenance Association . . . . . . . . . . . . . . . . . 41
7. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Normative References . . . . . . . . . . . . . . . . . . 44 11.1. Normative References . . . . . . . . . . . . . . . . . . 43
11.2. Informative References . . . . . . . . . . . . . . . . . 45 11.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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 networks connections (Connectivity Verification, 1. Monitor networks connections (Connectivity Verification,
Continuity Check). Continuity Check).
skipping to change at page 3, line 19 skipping to change at page 3, line 19
for similar purposes. for similar purposes.
[IEEE802.1Q] Connectivity Fault Management is a well-established OAM [IEEE802.1Q] Connectivity Fault Management is a well-established OAM
standard that is widely adopted for Ethernet networks. ITU-T standard that is widely adopted for Ethernet networks. ITU-T
[Y.1731][Y.1731], MEF Service OAM, MPLS-TP [RFC6371], TRILL [Y.1731][Y.1731], MEF Service OAM, MPLS-TP [RFC6371], TRILL
[RFC7455][RFC7455] all define OAM methods based on manageability [RFC7455][RFC7455] all define OAM methods based on manageability
frame work of [IEEE802.1Q] [IEEE802.1Q]CFM. frame work of [IEEE802.1Q] [IEEE802.1Q]CFM.
Given the wide adoption of the underlying OAM concepts defined in Given the wide adoption of the underlying OAM concepts defined in
[IEEE802.1Q][IEEE802.1Q] CFM, it is a reasonable choice to develop [IEEE802.1Q][IEEE802.1Q] CFM, it is a reasonable choice to develop
the unified management framework based on those concepts. In this the unified management framework for connection oriented OAM based on
document, we take the [IEEE802.1Q][IEEE802.1Q] CFM model and extend those concepts. In this document, we take the
it to a technology independent framework and build the corresponding [IEEE802.1Q][IEEE802.1Q] CFM model and extend it to a technology
YANG model accordingly. The YANG model presented in this document is independent framework and build the corresponding YANG model
the base model and supports generic continuity check, connectivity accordingly. The YANG model presented in this document is the base
verification and path discovery. The generic YANG model for OAM is model for connection oriented OAM protocols and supports generic
designed such that it can be extended to cover various technologies. continuity check, connectivity verification and path discovery. The
generic YANG model for connection oriented OAM is designed such that
it can be extended to cover various connection oriented technologies.
Technology dependent nodes and RPC (remote process call) commands are Technology dependent nodes and RPC (remote process call) commands are
defined in technology specific YANG models, which use and extend the defined in technology specific YANG models, which use and extend the
base model defined here. As an example, VXLAN uses source UDP port base model defined here. As an example, VXLAN uses source UDP port
number for flow entropy, while MPLS [RFC4379] uses IP addresses or number for flow entropy, while TRILL uses either MAC addresses, the
the label stack for flow entropy in the hashing for multipath VLAN tag or fine grain label or IP addresses for flow entropy in the
selection. To capture this variation, corresponding YANG models hashing for multipath selection. To capture this variation,
would define the applicable structures as augmentation to the generic corresponding YANG models would define the applicable structures as
base model presented here. This accomplishes three purposes: first augmentation to the generic base model presented here. This
it keeps each YANG model smaller and manageable. Second, it allows accomplishes three purposes: first it keeps each YANG model smaller
independent development of corresponding YANG models. Third, and manageable. Second, it allows independent development of
implementations can limit support to only the applicable set of YANG corresponding YANG models. Third, implementations can limit support
models. (e.g. TRILL RBridge may only need to implement Generic model to only the applicable set of YANG models. (e.g. TRILL RBridge may
and the TRILL YANG model). only need to implement Generic model and the TRILL YANG model).
All implementations that follow the YANG framework presented in this All implementations that follow the YANG framework presented in this
document MUST implement the generic YANG model presented here. document MUST implement the generic connection oriented YANG model
presented here.
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 issues a Ping according to each OAM protocol. A user who wishes to issues a
command or a Traceroute or initiate a performance monitoring session Continuity Check command or a Loop back or initiate a performance
can do so in the same manner regardless of the underlying protocol or monitoring session can do so in the same manner regardless of the
technology or specific vendor implementation. underlying protocol or technology or specific vendor implementation.
As an example, consider a scenario where an IP ping from device A to As an example, consider a scenario where Lookback from device A to
Device B failed. Between device A and B there are IEEE 802.1 bridges Device B failed. Between device A and B there are IEEE 802.1 bridges
a,b and c. Let's assume a,b and c are using [IEEE802.1Q] CFM. A a,b and c. Let's assume a,b and c are using [IEEE802.1Q] CFM. A
user upon detecting the IP layer ping failures may decide to drill user upon detecting the Loopback failures may decide to drill down to
down to the Ethernet layer and issue the corresponding fault the lower level at the different portion of the path and issue the
verification (LBM) and fault isolation (LTM) tools, using the same corresponding fault verification (LBM) and fault isolation (LTM)
API. This ability to go down to the same portion of path atlower tools, using the same API. This ability to go down to the different
layer for Fault localization and troubleshooting is referred to as portion of path at lower level for Fault localization and
"nested OAM workflow" and is a useful concept that leads to efficient troubleshooting is referred to as "nested OAM workflow" and is a
network troubleshooting and maintenance. The OAM YANG model useful concept that leads to efficient network troubleshooting and
presented in this document facilitates that without needing changes maintenance. The connection oriented OAM YANG model presented in
to the underlying protocols. this document facilitates that without needing changes to the
underlying protocols.
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The following notations are used within the data tree and carry the The following notations are used within the data tree and carry the
meaning as below. meaning as below.
skipping to change at page 6, line 10 skipping to change at page 6, line 10
referred to as reachability verification. referred to as reachability verification.
CV - Connectivity Verification [RFC7276].Connectivity CV - Connectivity Verification [RFC7276].Connectivity
Verifications are also referred to as path verification and Verifications are also referred to as path verification and
used to verify not only that the two MPs are connected, but used to verify not only that the two MPs are connected, but
also that they are connected through the expected path, also that they are connected through the expected path,
allowing detection of unexpected topology changes. allowing detection of unexpected topology changes.
3. Architecture of Generic YANG Model for OAM 3. Architecture of Generic YANG Model for OAM
In this document we define a generic YANG model for OAM. The YANG In this document we define a generic YANG model for connection
model defined here is generic such that other technologies can extend oriented OAM protocols. The YANG model defined here is generic such
it for technology specific needs. The Generic YANG model acts as the that other technologies can extend it for technology specific needs.
root for other OAM YANG models. This allows users to traverse The Generic YANG model acts as the root for other OAM YANG models.
between OAM of different technologies at ease through a uniform API This allows users to traverse between different OAM protocols at ease
set. This is also provides a nested OAM workflow. Figure 1 depicts through a uniform API set. This is also provides a nested OAM
the relationship of different OAM YANG models to the Generic YANG workflow. Figure 1 depicts the relationship of different OAM YANG
Model for OAM. Some technologies may have different sub- models to the Generic YANG Model for connection oriented OAM. The
technologies. As an example, consider Network Virtualization Generic YANG model for OAM provides a framework where technology-
Overlays. These could employ either VXLAN or NVGRE as encapsulation.
The Generic YANG model for OAM provides a framework where technology-
specific YANG models can inherit constructs from the base YANG models specific YANG models can inherit constructs from the base YANG models
without needing to redefine them within the sub-technology. without needing to redefine them within the sub-technology.
Figure 1 depicts relationship of different YANG modules. Figure 1 depicts relationship of different YANG modules.
+-+-+-+-+-+ +----------+
| gen | |Connection|
|OAM YANG | | Oriented |
+-+-+-+-+-+ | gen |
| |OAM YANG |
O +-+-+-+-+-++
| |
+---------------------------------------------------------+ |
| | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +------------------------------------------+
| TRILL | | NVO3 | | MPLS | | IP | . . .| foo | | | |
|OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | TRILL | | MPLS-TP | . . .| foo |
| | | | | |OAM YANG | |OAM YANG | |OAM YANG |
| +-+-+-+-+-+ +-+-+-+-+-+ | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | NVO3 | | MPLS | | . . .| foo | | | |
| |sub tech | |sub tech | | |sub tech | | | +-+-+-+-+-+
| +-+-+-+-+-+ +-+-+-+-+-+ | +-+-+-+-+-+ | | . . .| foo |
| | | | | | | |sub tech |
| | | | | | | +-+-+-+-+-+
+------------------------------------------------------------+ | | |
| Uniform API | | | |
+------------------------------------------------------------+ +-------------------------------------------------------+
| Uniform API |
+-------------------------------------------------------+
Relationship of OAM YANG model to generic (base) YANG model Relationship of OAM YANG model to generic (base) YANG model
4. Overview of the OAM Model 4. Overview of the OAM Model
In this document we adopt the concepts of the [IEEE802.1Q] CFM model In this document we adopt the concepts of the [IEEE802.1Q] CFM model
and structure it such that it can be adapted to different and structure it such that it can be adapted to different OAM
technologies. protocols for connection oriented technology.
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
Association (MA). In IP, the MA can be per IP Subnet, in NVO3 this Association (MA). In TRILL this can be per Fine-Grained Label or for
can be per VNI and for TRILL this can be per Fine-Grained Label or VPLS this can be per VPLS instance.
for VPLS this can be per VPLS instance.
Under each MA, there can be two or more MEPs (Maintenance Association Under each MA, there can be two or more MEPs (Maintenance Association
End Points). MEPs are addressed by their respective technology End Points). MEPs are addressed by their respective technology
specific address identifiers. The YANG model presented here provides specific address identifiers. The YANG model presented here provides
flexibility to accommodate different addressing schemes. flexibility to accommodate different addressing schemes.
In the vertical direction orthogonal to the Maintenance Domain, In the vertical direction orthogonal to the Maintenance Domain,
presented are the commands. Those, in YANG terms, are the rpc presented are the commands. Those, in YANG terms, are the rpc
commands. These rpc commands provide uniform APIs for continuity commands. These rpc commands provide uniform APIs for continuity
check,connectivity verification, path discovery and their equivalents check,connectivity verification, path discovery and their equivalents
as well as other OAM commands. as well as other OAM commands.
The generic YANG model defined here does not require explicit The generic YANG model defined here does not require explicit
configuration of OAM entities prior to using any of the OAM tools.The configuration of OAM entities prior to using any of the OAM tools.The
OAM tools used here are limited to OAM toolset specified in section OAM tools used here are limited to OAM toolset specified in section
5.1 of [RFC7276]. Users of Ping and Traceroute tools within IP 5.1 of [RFC7276]. In order to facilitate zero- touch experience,
devices are expecting ability to use OAM tools with no explicit this document defines a default mode of OAM. The default mode of OAM
configuration. In order to facilitate zero- touch experience, this is referred to as the Base Mode and specifies default values for each
document defines a default mode of OAM. The default mode of OAM is of model parameters, such as Maintenance Domain Level, Name of the
referred to as the Base Mode and specifies default values for each of
model parameters, such as Maintenance Domain Level, Name of the
Maintenance Association and Addresses of MEP and so on. The default Maintenance Association and Addresses of MEP and so on. The default
values of these depend on the technology. Base Mode for TRILL is values of these depend on the technology. Base Mode for TRILL is
defined in [RFC7455]. Base mode for other technologies such as NVO3, defined in [RFC7455]. Base mode for other technologies such as MPLS-
MPLS and future extensions will be defined in their corresponding TP and future extensions will be defined in their corresponding
documents. 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 model to support Base Mode. Implementations that comply
with this document, by default implement the data nodes of the with this document, by default implement the data nodes of the
applicable technology. Data nodes of the Base Mode are read-only applicable technology. Data nodes of the Base Mode are read-only
nodes. nodes.
4.1. Maintenance Domain (MD) configuration 4.1. Maintenance Domain (MD) configuration
The container "domains" is the top level container within the gen-oam The container "domains" is the top level container within the gen-oam
module. Within the container "domains", separate list is maintained module. Within the container "domains", separate list is maintained
per MD. The MD list uses the key MD-name-string for indexing. MD- per MD. The MD list uses the key MD-name-string for indexing. MD-
name-string is a leaf and derived from type string. Additional name name-string is a leaf and derived from type string. Additional name
formats as defined in [IEEE802.1Q] or other standards can be included formats as defined in [IEEE802.1Q] or other standards can be included
by association of the MD-name-format with an identity-ref. MD-name- by association of the MD-name-format with an identity-ref. MD-name-
format indicates the format of the augmented MD-names. MD-name is format indicates the format of the augmented MD-names. MD-name is
presented as choice/case construct. Thus, it is easily augmentable presented as choice/case construct. Thus, it is easily augmentable
by derivative work. by derivative work.
module: ietf-gen-oam module: ietf-conn-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
+--rw md-level MD-level . +--rw md-level MD-level .
skipping to change at page 8, line 39 skipping to change at page 8, line 33
4.2. Maintenance Association (MA) configuration 4.2. Maintenance Association (MA) configuration
Within a given Maintenance Domain there can be one or more Within a given Maintenance Domain there can be one or more
Maintenance Associations (MA). MAs are represented as a list and Maintenance Associations (MA). MAs are represented as a list and
indexed by the MA-name-string. Similar to MD-name defined indexed by the MA-name-string. Similar to MD-name defined
previously, additional name formats can be added by augmenting the previously, additional name formats can be added by augmenting the
name-format identity-ref and adding applicable case statements to MA- name-format identity-ref and adding applicable case statements to MA-
name. name.
module: ietf-gen-oam module: ietf-conn-oam
+--rw domains +--rw domains
+--rw domain* [technology MD-name-string] +--rw domain* [technology MD-name-string]
. .
. .
+--rw MAs +--rw MAs
+--rw MA* [MA-name-string] +--rw MA* [MA-name-string]
+--rw MA-name-string MA-name-string +--rw MA-name-string MA-name-string
+--rw MA-name-format? identityref +--rw MA-name-format? identityref
+--rw (MA-name)? +--rw (MA-name)?
| +--:(MA-name-null) | +--:(MA-name-null)
| +--rw MA-name-null? empty | +--rw MA-name-null? empty
Snippet of data hierarchy related to Maintenance Associations (MA) Snippet of data hierarchy related to Maintenance Associations (MA)
4.3. Maintenance Endpoint (MEP) configuration 4.3. Maintenance Endpoint (MEP) configuration
Within a given Maintenance Association (MA), there can be one or more Within a given Maintenance Association (MA), there can be one or more
Maintenance End Points (MEP). MEPs are represented as a list within Maintenance End Points (MEP). MEPs are represented as a list within
the data hierarchy and indexed by the key MEP-name. the data hierarchy and indexed by the key MEP-name.
module: ietf-gen-oam module: ietf-conn-oam
+--rw domains +--rw domains
+--rw domain* [technology MD-name-string] +--rw domain* [technology MD-name-string]
+--rw technology identityref +--rw technology identityref
. .
. .
+--rw MAs +--rw MAs
+--rw MA* [MA-name-string] +--rw MA* [MA-name-string]
+--rw MA-name-string MA-name-string +--rw MA-name-string MA-name-string
. .
. .
skipping to change at page 11, line 5 skipping to change at page 11, line 5
The rpc model facilitates issuing commands to a NETCONF server (in The rpc model facilitates issuing commands to a NETCONF server (in
this case to the device that need to execute the OAM command) and this case to the device that need to execute the OAM command) and
obtain a response. rpc model defined here abstracts OAM specific obtain a response. rpc model defined here abstracts OAM specific
commands in a technology independent manner. commands in a technology independent manner.
There are several rpc commands defined for the purpose of OAM. In There are several rpc commands defined for the purpose of OAM. In
this section we present a snippet of the continuity check command for this section we present a snippet of the continuity check command for
illustration purposes. Please refer to Section 4 for the complete illustration purposes. Please refer to Section 4 for the complete
data hierarchy and Section 5 for the YANG model. data hierarchy and Section 5 for the YANG model.
module: ietf-gen-oam module: ietf-conn-oam
+--rw domains +--rw domains
+--rw domain* [technology MD-name-string] +--rw domain* [technology MD-name-string]
+--rw technology identityref +--rw technology identityref
. .
. .
rpcs: rpcs:
+---x continuity-check +---x continuity-check
| +--ro input | +--ro input
| | +--ro technology identityref | | +--ro technology identityref
| | +--ro MD-name-string MD-name-string | | +--ro MD-name-string MD-name-string
skipping to change at page 11, line 44 skipping to change at page 11, line 44
| | | | +--:(ipv6-address) | | | | +--:(ipv6-address)
| | | | +--ro ipv6-address? inet:ipv6-address | | | | +--ro ipv6-address? inet:ipv6-address
| | | +--ro (MEP-ID)? | | | +--ro (MEP-ID)?
| | | | +--:(MEP-ID-int) | | | | +--:(MEP-ID-int)
| | | | +--ro MEP-ID-int? int32 | | | | +--ro MEP-ID-int? int32
| | | +--ro MEP-ID-format? identityref | | | +--ro MEP-ID-format? identityref
| | +--ro count? uint32 | | +--ro count? uint32
| | +--ro interval? Interval | | +--ro interval? Interval
| | +--ro packet-size? uint32 | | +--ro packet-size? uint32
| +--ro output | +--ro output
| +--ro tx-packt-count? oam-counter32 | | +--ro monitor-stats
| +--ro rx-packet-count? oam-counter32 | | |--+--:(monitor-null)
| +--ro min-delay? oam-counter32 | | +--ro monitor-null? Empty
| +--ro average-delay? oam-counter32
| +--ro max-delay? oam-counter32
Snippet of data hierarchy related to rpc call continuity-check Snippet of data hierarchy related to rpc call continuity-check
4.5. OAM data hierarchy 4.5. OAM data hierarchy
The complete data hierarchy related to the OAM YANG model is The complete data hierarchy related to the connection oriented OAM
presented below. YANG model is presented below.
module: ietf-gen-oam module: ietf-conn-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
+--rw md-level? MD-level +--rw md-level? MD-level
+--rw MAs +--rw MAs
skipping to change at page 14, line 48 skipping to change at page 14, line 48
| | | | | +--ro MEP-ID-int? int32 | | | | | +--ro MEP-ID-int? int32
| | | | +--:(MEP-ID-tlv) | | | | +--:(MEP-ID-tlv)
| | | | +--ro MEP-ID-type? int16 | | | | +--ro MEP-ID-type? int16
| | | | +--ro MEP-ID-len? int16 | | | | +--ro MEP-ID-len? int16
| | | | +--ro MEP-ID-value? binary | | | | +--ro MEP-ID-value? binary
| | | +--ro MEP-ID-format? identityref | | | +--ro MEP-ID-format? identityref
| | +--ro count? uint32 | | +--ro count? uint32
| | +--ro interval? Interval | | +--ro interval? Interval
| | +--ro packet-size? uint32 | | +--ro packet-size? uint32
| +--ro output | +--ro output
| +--ro tx-packt-count? oam-counter32 | | +--ro monitor-stats
| +--ro rx-packet-count? oam-counter32 | | |--+--:(monitor-null)
| +--ro min-delay? oam-counter32 | | +--ro monitor-null? Empty
| +--ro average-delay? oam-counter32
| +--ro max-delay? oam-counter32
+---x continuity-verification {connectivity-verification}? +---x continuity-verification {connectivity-verification}?
| +--ro input | +--ro input
| | +--ro technology identityref | | +--ro technology identityref
| | +--ro MD-name-string MD-name-string | | +--ro MD-name-string MD-name-string
| | +--ro MA-name-string? MA-name-string | | +--ro MA-name-string? MA-name-string
| | +--ro (flow-entropy)? | | +--ro (flow-entropy)?
| | | +--:(flow-entropy-null) | | | +--:(flow-entropy-null)
| | | +--ro flow-entropy-null? empty | | | +--ro flow-entropy-null? empty
| | +--ro priority? uint8 | | +--ro priority? uint8
| | +--ro ttl? uint8 | | +--ro ttl? uint8
skipping to change at page 15, line 41 skipping to change at page 15, line 39
| | | | | +--ro MEP-ID-int? int32 | | | | | +--ro MEP-ID-int? int32
| | | | +--:(MEP-ID-tlv) | | | | +--:(MEP-ID-tlv)
| | | | +--ro MEP-ID-type? int16 | | | | +--ro MEP-ID-type? int16
| | | | +--ro MEP-ID-len? int16 | | | | +--ro MEP-ID-len? int16
| | | | +--ro MEP-ID-value? binary | | | | +--ro MEP-ID-value? binary
| | | +--ro MEP-ID-format? identityref | | | +--ro MEP-ID-format? identityref
| | +--ro count? uint32 | | +--ro count? uint32
| | +--ro interval? Interval | | +--ro interval? Interval
| | +--ro packet-size? uint32 | | +--ro packet-size? uint32
| +--ro output | +--ro output
| +--ro tx-packt-count? oam-counter32 | | +--ro monitor-stats
| +--ro rx-packet-count? oam-counter32 | | |--+--:(monitor-null)
| +--ro min-delay? oam-counter32 | | +--ro monitor-null? Empty
| +--ro average-delay? oam-counter32
| +--ro max-delay? oam-counter32
+---x path-discovery +---x path-discovery
+--ro input +--ro input
| +--ro technology identityref | +--ro technology identityref
| +--ro MD-name-string MD-name-string | +--ro MD-name-string MD-name-string
| +--ro MA-name-string? MA-name-string | +--ro MA-name-string? MA-name-string
| +--ro (flow-entropy)? | +--ro (flow-entropy)?
| | +--:(flow-entropy-null) | | +--:(flow-entropy-null)
| | +--ro flow-entropy-null? empty | | +--ro flow-entropy-null? empty
| +--ro priority? uint8 | +--ro priority? uint8
| +--ro ttl? uint8 | +--ro ttl? uint8
skipping to change at page 17, line 4 skipping to change at page 16, line 48
| | +--:(ipv6-address) | | +--:(ipv6-address)
| | +--ro ipv6-address? inet:ipv6-address | | +--ro ipv6-address? inet:ipv6-address
| +--ro (MEP-ID)? | +--ro (MEP-ID)?
| | +--:(MEP-ID-int) | | +--:(MEP-ID-int)
| | | +--ro MEP-ID-int? int32 | | | +--ro MEP-ID-int? int32
| | +--:(MEP-ID-tlv) | | +--:(MEP-ID-tlv)
| | +--ro MEP-ID-type? int16 | | +--ro MEP-ID-type? int16
| | +--ro MEP-ID-len? int16 | | +--ro MEP-ID-len? int16
| | +--ro MEP-ID-value? binary | | +--ro MEP-ID-value? binary
| +--ro MEP-ID-format? identityref | +--ro MEP-ID-format? identityref
+--ro tx-packt-count? oam-counter32 +--ro monitor-stats
+--ro rx-packet-count? oam-counter32 --+--:(monitor-null)
+--ro min-delay? oam-counter32 +--ro monitor-null? Empty
+--ro average-delay? oam-counter32
+--ro max-delay? oam-counter32
notifications: notifications:
+---n defect-condition-notification +---n defect-condition-notification
+--ro technology identityref +--ro technology identityref
+--ro MD-name-string MD-name-string +--ro MD-name-string MD-name-string
+--ro MA-name-string? MA-name-string +--ro MA-name-string? MA-name-string
+--ro mep-name? MEP-name +--ro mep-name? MEP-name
+--ro defect-type? identityref +--ro defect-type? identityref
+--ro generating-mepid +--ro generating-mepid
| +--ro (MEP-ID)? | +--ro (MEP-ID)?
| | +--:(MEP-ID-int) | | +--:(MEP-ID-int)
| | | +--ro MEP-ID-int? int32 | | | +--ro MEP-ID-int? int32
skipping to change at page 17, line 36 skipping to change at page 17, line 31
+--:(error-null) +--:(error-null)
| +--ro error-null? empty | +--ro error-null? empty
+--:(error-code) +--:(error-code)
+--ro error-code? int3 +--ro error-code? int3
+--ro error-code? int32 +--ro error-code? int32
data hierarchy of OAM data hierarchy of OAM
5. OAM YANG Module 5. OAM YANG Module
<CODE BEGINS> file "ietf-gen-oam.yang" <CODE BEGINS> file "ietf-conn-oam.yang"
module ietf-gen-oam {
namespace "urn:ietf:params:xml:ns:yang:ietf-gen-oam";
prefix goam;
import ietf-interfaces { module ietf-conn-oam {
prefix if; namespace "urn:ietf:params:xml:ns:yang:ietf-conn-oam";
} prefix goam;
import ietf-yang-types {
prefix yang;
}
import ietf-inet-types {
prefix inet;
}
organization "IETF LIME Working Group";
contact
"Tissa Senevirathne tsenevir@cisco.com";
description
"This YANG module defines the generic configuration,
statistics and rpc for OAM to be used within IETF in
a protocol indpendent manner. Functional level
abstraction is indendent with YANG modeling. It is
assumed that each protocol maps corresponding
abstracts to its native format.
Each protocol may extend the YANG model defined
here to include protocol specific extensions";
revision 2015-04-09 { import ietf-interfaces {
description prefix if;
"Initial revision. - 04 version"; }
reference "draft-tissa-lime-oam"; import ietf-yang-types {
} prefix yang;
}
import ietf-inet-types {
prefix inet;
}
/* features */ organization "IETF LIME Working Group";
feature connectivity-verification { contact
description "Tissa Senevirathne tsenevir@cisco.com";
"This feature indicates that the server supports description
executing connectivity verification OAM command and "This YANG module defines the generic configuration,
returning a response. Servers that do not advertise statistics and rpc for connection oriented OAM to be used within IETF in
this feature will not support executing a protocol indpendent manner. Functional level
connectivity verification command or rpc model for abstraction is indendent with YANG modeling. It is
connectivity verification command."; assumed that each protocol maps corresponding
} abstracts to its native format.
Each protocol may extend the YANG model defined
here to include protocol specific extensions";
/* Identities */ revision 2015-04-09 {
description
"Initial revision. - 04 version";
reference "draft-tissa-lime-oam";
}
identity technology-types { /* features */
description feature connectivity-verification {
"this is the base identy of technology types which are description
vpls, nvo3, TRILL, ipv4, ipv6, mpls, etc"; "This feature indicates that the server supports
} executing connectivity verification OAM command and
returning a response. Servers that do not advertise
this feature will not support executing
connectivity verification command or rpc model for
connectivity verification command.";
}
identity ipv4 { /* Identities */
base technology-types;
description
"technology of ipv4";
}
identity ipv6 { identity technology-types {
base technology-types; description
description "this is the base identy of technology types which are
"technology of ipv6"; TRILL,mpls,vpls etc";
} }
identity command-sub-type { identity command-sub-type {
description description
"defines different rpc command subtypes, e.g rfc792 IP "defines different rpc command subtypes, e.g rfc792 IP
ping, rfc4379 LSP ping, rfc6905 trill OAM, this is ping, rfc4379 LSP ping, rfc6905 trill OAM, this is
optional for most cases"; optional for most cases";
} }
identity icmp-rfc792 { identity icmp-rfc792 {
base command-sub-type; base command-sub-type;
description description
"Defines the command subtypes for ICMP ping"; "Defines the command subtypes for ICMP ping";
reference "RFC 792"; reference "RFC 792";
} }
identity name-format { identity name-format {
description description
"This defines the name format, IEEE 8021Q CFM defines varying "This defines the name format, IEEE 8021Q CFM defines varying
styles of names. It is expected name format as an identity ref styles of names. It is expected name format as an identity ref
to be extended with new types."; 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";
} }
identity identifier-format { identity identifier-format {
description description
"identifier-format identity can be augmented to define other "identifier-format identity can be augmented to define other
format identifiers used in MEPD-ID etc"; format identifiers used in MEPD-ID etc";
} }
identity identifier-format-integer { identity identifier-format-integer {
base identifier-format; base identifier-format;
description description
"defines identifier-format to be integer"; "defines identifier-format to be integer";
} }
identity defect-types { identity defect-types {
description description
"defines different defect types, e.g. remote rdi, "defines different defect types, e.g. remote rdi,
mis-connection defect, loss of continuity"; mis-connection defect, loss of continuity";
} }
identity remote-rdi { identity remote-rdi {
base defect-types; base defect-types;
description description
" Indicates the aggregate health of the remote MEPs. "; " Indicates the aggregate health of the remote MEPs. ";
} }
identity remote-mep-error{ identity remote-mep-error{
base defect-types; base defect-types;
description description
" Indicates that one or more of the remote MEPs is " Indicates that one or more of the remote MEPs is
reporting a failure "; reporting a failure ";
} }
identity invalue-oam-error{ identity invalue-oam-error{
base defect-types; base defect-types;
description description
"Indicates that one or more invalid OAM messages has been "Indicates that one or more invalid OAM messages has been
received and that 3.5 times that OAM message transmission received and that 3.5 times that OAM message transmission
interval has not yet expired. interval has not yet expired.
"; ";
} }
identity cross-connect-error{ identity cross-connect-error{
base defect-types; base defect-types;
description description
" Indicates that one or more cross-connect oam messages has been " Indicates that one or more cross-connect oam messages has been
received and that 3.5 times that OAM message transmission received and that 3.5 times that OAM message transmission
interval has not yet expired. interval has not yet expired.
"; ";
} }
/* typedefs */ /* typedefs */
typedef MEP-direction { typedef MEP-direction {
type enumeration { type enumeration {
enum "Up" { enum "Up" {
value 0; value 0;
description description
"Indicates when OAM frames are transmitted towards and "Indicates when OAM frames are transmitted towards and
received from the bridging/routing function."; received from the bridging/routing function.";
} }
enum "Down" { enum "Down" {
value 1; value 1;
description description
"Indicates when OAM frames are transmitted towards and "Indicates when OAM frames are transmitted towards and
received from the wire."; received from the wire.";
} }
} }
description description
"MEP direction."; "MEP direction.";
} }
typedef MEP-name {
type string;
description
"Generic administrative name for a MEP";
}
typedef Interval { typedef MEP-name {
type uint32; type string;
units "milliseconds"; description
default "1000"; "Generic administrative name for a MEP";
description }
"Interval between packets in milliseconds.
0 means no packets are sent.";
}
typedef ecmp-choices { typedef Interval {
type enumeration { type uint32;
enum "ecmp-use-platform-hash" { units "milliseconds";
value 0; default "1000";
description description
"Use Platform hashing."; "Interval between packets in milliseconds.
} 0 means no packets are sent.";
enum "ecmp-use-round-robin" { }
value 1;
description
"Use round robin hashing.";
}
}
description
"Equal cost multi Path Choices";
}
typedef MD-name-string { typedef ecmp-choices {
type string; type enumeration {
default ""; enum "ecmp-use-platform-hash" {
description value 0;
"Generic administrative name for an MD";
}
typedef MA-name-string { description
type string; "Use Platform hashing.";
default ""; }
description enum "ecmp-use-round-robin" {
"Generic administrative name for an MA"; value 1;
} description
"Use round robin hashing.";
}
}
description
"Equal cost multi Path Choices";
}
typedef oam-counter32 { typedef MD-name-string {
type yang:zero-based-counter32; type string;
description default "";
"defines 32 bit counter for OAM"; description
} "Generic administrative name for an MD";
}
typedef MD-level { typedef MA-name-string {
type uint32 { type string;
range "0..255"; default "";
} description
description "Generic administrative name for an MA";
"Maintenance Domain level. The level may be restricted in }
certain protocols (eg to 0-7)";
}
/* groupings */ typedef oam-counter32 {
type yang:zero-based-counter32;
description
"defines 32 bit counter for OAM";
}
grouping topology { typedef MD-level {
choice topology { type uint32 {
case topo-null { range "0..255";
}
description
"Maintenance Domain level. The level may be restricted in
certain protocols (eg to 0-7)";
}
/* groupings */
grouping topology {
choice topology {
case topo-null {
description
"this is a placeholder when no topology is needed";
leaf topo-null {
type empty;
description description
"this is a placeholder when no topology is needed"; "there is no topology define, it will be defined
leaf topo-null { in technology specific model.";
type empty; }
description }
"there is no topology define, it will be defined description
in technology specific model."; "Topology choices";
} }
} description
description "Topology";
"Topology choices"; }
}
description
"Topology";
}
grouping error-message { grouping error-message {
choice error { choice error {
case error-null { case error-null {
description
"this is a placeholder when no error status is needed";
leaf error-null {
type empty;
description description
"this is a placeholder when no error status is needed"; "there is no error define, it will be defined in
leaf error-null { technology specific model.";
type empty; }
description }
"there is no error define, it will be defined in case error-code {
technology specific model."; description
} "this is a placeholder to display error code.";
} leaf error-code {
case error-code { type int32;
description description
"this is a placeholder to display error code."; "error code is integer value specific to technology.";
leaf error-code { }
type int32; }
description description
"error code is integer value specific to technology."; "Error Message choices.";
} }
} description
description "Error Message.";
"Error Message choices."; }
}
description
"Error Message.";
}
grouping mp-address { grouping mp-address {
choice mp-address { choice mp-address {
case mac-address { case mac-address {
leaf mac-address { leaf mac-address {
type yang:mac-address; type yang:mac-address;
description
"MAC Address";
}
description
"MAC Address based MP Addressing.";
}
case ipv4-address {
leaf ipv4-address {
type inet:ipv4-address;
description
"Ipv4 Address";
}
description
"Ip Address based MP Addressing.";
}
case ipv6-address {
leaf ipv6-address {
type inet:ipv6-address;
description
"Ipv6 Address";
}
description
"ipv6 Address based MP Addressing.";
}
description
"MP Addressing.";
}
description
"MP Address";
} description
"MAC Address";
}
description
"MAC Address based MP Addressing.";
}
case ipv4-address {
leaf ipv4-address {
type inet:ipv4-address;
description
"Ipv4 Address";
}
description
"Ip Address based MP Addressing.";
}
case ipv6-address {
leaf ipv6-address {
type inet:ipv6-address;
description
"Ipv6 Address";
}
description
"ipv6 Address based MP Addressing.";
}
description
"MP Addressing.";
}
description
"MP Address";
}
grouping maintenance-domain-id { grouping maintenance-domain-id {
description description
"Grouping containing leaves sufficient to identify an MD"; "Grouping containing leaves sufficient to identify an MD";
leaf technology { leaf technology {
type identityref { type identityref {
base technology-types; base technology-types;
} }
mandatory true; mandatory true;
description description
"Defines the technology"; "Defines the technology";
} }
leaf MD-name-string { leaf MD-name-string {
type MD-name-string; type MD-name-string;
mandatory true; mandatory true;
description description
"Defines the generic administrative maintenance domain name"; "Defines the generic administrative maintenance domain name";
}
}
grouping MD-name { }
leaf MD-name-format { }
type identityref {
base name-format;
}
description
"Name format.";
}
choice MD-name {
case MD-name-null {
leaf MD-name-null {
when "../../../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 { grouping MD-name {
description leaf MD-name-format {
"MA name"; type identityref {
leaf MA-name-format { base name-format;
type identityref { }
base name-format; description
} "Name format.";
description }
"Ma name format"; choice MD-name {
} case MD-name-null {
choice MA-name { leaf MD-name-null {
case MA-name-null { when "../../../MD-name-format = name-format-null" {
leaf MA-name-null {
when "../../../MA-name-format = name-format-null" {
description
"MA";
}
type empty;
description description
"empty"; "MD name format is equal to null format.";
} }
} type empty;
description description
"MA name"; "MD name Null.";
} }
} }
description
"MD name.";
}
description
"MD name";
}
grouping MEP-ID { grouping ma-identifier {
choice MEP-ID { description
default "MEP-ID-int"; "Grouping containing leaves sufficient to identify an MA";
case MEP-ID-int { leaf MA-name-string {
leaf MEP-ID-int { type MA-name-string;
type int32;
description
"MEP ID in integer format";
}
}
case MEP-ID-tlv {
leaf MEP-ID-type {
type int16;
description description
"Type of MEP-ID"; "MA name string.";
} }
leaf MEP-ID-len { }
type int16;
grouping MA-name {
description
"MA name";
leaf MA-name-format {
type identityref {
base name-format;
}
description description
"Length of MEP-ID value"; "Ma name format";
} }
leaf MEP-ID-value { choice MA-name {
type binary { case MA-name-null {
length "12..255"; leaf MA-name-null {
} when "../../../MA-name-format = name-format-null" {
description description
"Value please refer RFC6428."; "MA";
}
type empty;
description
"empty";
}
}
description
"MA name";
} }
} }
description
"MEP-ID";
}
leaf MEP-ID-format {
type identityref {
base identifier-format;
}
description
"MEP ID format.";
}
description
"MEP-ID";
}
grouping MEP {
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 mp-address;
uses connectivity-context;
leaf Interface {
type if:interface-ref;
description
"Interface name as defined by ietf-interfaces";
}
uses topology;
}
grouping session-type { grouping MEP-ID {
description choice MEP-ID {
"This object indicates the current session default "MEP-ID-int";
definition."; case MEP-ID-int {
leaf session-type-enum { leaf MEP-ID-int {
type enumeration { type int32;
enum proactive { description
description "MEP ID in integer format";
"The current session is proactive"; }
} }
enum on-demand { case MEP-ID-tlv {
description leaf MEP-ID-type {
"The current session is on-demand."; type int16;
} description
"Type of MEP-ID";
} }
description leaf MEP-ID-len {
"session type enum"; type int16;
} description
} "Length of MEP-ID value";
}
leaf MEP-ID-value {
type binary {
length "12..255";
}
description
"Value please refer RFC6428.";
}
}
description
"MEP-ID";
}
leaf MEP-ID-format {
type identityref {
base identifier-format;
}
description
"MEP ID format.";
}
description
"MEP-ID";
}
grouping monitor-stats { grouping MEP {
leaf tx-packt-count { description
type oam-counter32; "Defines elements within the MEP";
description leaf mep-name {
"Transmitted Packet count"; type MEP-name;
} mandatory true;
leaf rx-packet-count { description
type oam-counter32; "Generic administrative name of the MEP";
description }
"Received packet count"; uses MEP-ID;
}
leaf min-delay {
type oam-counter32;
units milliseconds;
description
"Delay is specified in milliseconds";
}
leaf average-delay {
type oam-counter32;
units millisecond;
description
"average delay in milliseconds";
}
leaf max-delay {
type oam-counter32;
units millisecond;
description
"Maximum delay in milliseconds";
}
description
"Monitor Statistics";
}
grouping MIP { uses mp-address;
description uses connectivity-context;
"defines MIP"; leaf Interface {
leaf interface { type if:interface-ref;
type if:interface-ref; description
description "Interface name as defined by ietf-interfaces";
"Interface"; }
} uses topology;
} }
grouping related-oam-layer { grouping session-type {
leaf offset { description
type int32 { "This object indicates the current session
range "-255..255"; definition.";
} leaf session-type-enum {
description type enumeration {
"defines offset (in MD levels) to a related OAM layer enum proactive {
+1 is the layer immediately above description
-1 is the layer immediately below"; "The current session is proactive";
} }
uses maintenance-domain-id; enum on-demand {
uses ma-identifier; description
description "The current session is on-demand.";
"related OAM layer";
}
grouping interface-status { }
description }
"collection of interface related status"; description
leaf admin-status { "session type enum";
type leafref { }
path "/if:interfaces-state/if:interface/if:admin-status"; }
}
config false;
description
"oper status from ietf-interface module";
}
leaf oper-status {
type leafref {
path "/if:interfaces-state/if:interface/if:oper-status";
}
config false;
description
"oper status from ietf-interface module";
}
}
grouping connectivity-context { grouping monitor-stats {
description description
"Grouping defining the connectivity context for an MA; for "grouping for monitoring statistics, this will be augmented
example, a VRF for IP, or an LSP for MPLS. This will be by others who use this component";
augmented by each protocol who use this component"; choice monitor-stats {
choice connectivity-context { default "monitor-null";
default "context-null"; case monitor-null {
case context-null { description
description "this is a place holder when
"this is a place holder when no context is needed"; no monitoring statistics is needed";
leaf context-null { leaf monitor-null {
type empty; type empty;
description description
"there is no context define"; "there is no monitoring statistics to be defined";
} }
} }
description description
"connectivity context"; "define the monitor stats";
} }
} }
grouping priority { grouping MIP {
description description
"Priority used in transmitted packets; for example, in the "defines MIP";
TOS/DSCP field in IP or the Traffic Class field in MPLS"; leaf interface {
leaf priority { type if:interface-ref;
type uint8; description
description "Interface";
"priority"; }
} }
}
grouping flow-entropy { grouping related-oam-layer {
description leaf offset {
"defines the grouping statement for flow-entropy"; type int32 {
choice flow-entropy { range "-255..255";
default "flow-entropy-null"; }
case flow-entropy-null { description
description "defines offset (in MD levels) to a related OAM layer
"this is a place holder when no flow entropy is needed"; +1 is the layer immediately above
leaf flow-entropy-null { -1 is the layer immediately below";
type empty; }
description uses maintenance-domain-id;
"there is no flow entropy defined"; uses ma-identifier;
} description
} "related OAM layer";
description }
"Flow entropy";
}
}
grouping measurement-timing-group { grouping interface-status {
description description
"This grouping includes objects used for "collection of interface related status";
proactive and on-demand leaf admin-status {
scheduling of PM measurement sessions."; type leafref {
path "/if:interfaces-state/if:interface/if:admin-status";
}
config false;
description
"oper status from ietf-interface module";
}
leaf oper-status {
type leafref {
path "/if:interfaces-state/if:interface/if:oper-status";
}
config false;
description
"oper status from ietf-interface module";
}
}
container start-time { grouping connectivity-context {
description description
"This container defines the session start time."; "Grouping defining the connectivity context for an MA; for
choice start-time { example, a VRF for VPLS, or an LSP for MPLS-TP. This will be
description augmented by each protocol who use this component";
"Measurement sessions tart time can be immediate, relative, or choice connectivity-context {
absolute."; default "context-null";
container immediate { case context-null {
presence "Start the measurement session immediately."; description
description "this is a place holder when no context is needed";
"Start Time of probe immediately."; leaf context-null {
} type empty;
leaf absolute { description
type yang:date-and-time; "there is no context define";
description
"This objects specifies the scheduled start time
to perform the on-demand monitoring operations.";
}
}
} }
}
container stop-time {
description
"This container defines the session stop time.";
choice stop-time {
description description
"Measurement session stop time can be none, or absolute."; "connectivity context";
container none { }
presence "Never end the measurement session."; }
description grouping priority {
"Stop time is never to end."; description
"Priority used in transmitted packets; for example, in the
TOS/DSCP field in IP or the Traffic Class field in MPLS";
leaf priority {
type uint8;
description
"priority";
}
}
grouping flow-entropy {
description
"defines the grouping statement for flow-entropy";
choice flow-entropy {
default "flow-entropy-null";
case flow-entropy-null {
description
"this is a place holder when no flow entropy is needed";
leaf flow-entropy-null {
type empty;
description
"there is no flow entropy defined";
}
} }
description
"Flow entropy";
}
}
leaf absolute { grouping measurement-timing-group {
type yang:date-and-time; description
"This grouping includes objects used for
proactive and on-demand
scheduling of PM measurement sessions.";
container start-time {
description description
"This objects specifies the scheduled stop time "This container defines the session start time.";
to perform the on-demand monitoring operations."; choice start-time {
} description
} "Measurement sessions tart time can be immediate, relative, or
absolute.";
container immediate {
presence "Start the measurement session immediately.";
description
"Start Time of probe immediately.";
}
leaf absolute {
type yang:date-and-time;
description
"This objects specifies the scheduled start time
to perform the on-demand monitoring operations.";
}
} }
} }
container domains { container stop-time {
description description
"Contains configuration related data. Within the container "This container defines the session stop time.";
is list of fault domains. Wihin each domian has List of MA."; choice stop-time {
list domain { description
key "technology MD-name-string"; "Measurement session stop time can be none, or absolute.";
ordered-by system; container none {
description presence "Never end the measurement session.";
"Define the list of Domains within the IETF-OAM"; description
uses maintenance-domain-id; "Stop time is never to end.";
uses MD-name;
leaf md-level {
type MD-level;
description
"Defines the MD-Level";
}
container MAs {
description
"This container defines MA, within that have multiple MA
and within MA have MEP, MIP";
list MA {
key "MA-name-string";
ordered-by system;
uses ma-identifier;
uses MA-name;
uses connectivity-context;
leaf mep-direction {
type MEP-direction;
mandatory true;
description
"Direction for MEPs in this MA";
}
leaf interval {
type Interval;
default "0";
description
"Defines default Keepalive/CC Interval. May be
overridden for specific sessions if supported by the
protocol.";
}
leaf loss-threshold {
type uint32;
default "3";
description
"number of consecutive Keepalive/CC messages missed
before declaring loss of continuity fault. This is
monitored per each remote MEP session";
}
leaf ttl {
type uint8;
default "255";
description
"Time to Live";
}
uses flow-entropy {
description
"Default flow entropy in this MA, which may be
overridden for particular MEPs, sessions or
operations";
}
uses priority {
description
"Default priority for this MA, which may be overridden
for particular MEPs, sessions or operations.";
}
list MEP {
key "mep-name";
ordered-by system;
description
"contain list of MEPS";
uses MEP;
uses interface-status {
description
"status of associated interface";
}
uses flow-entropy;
uses priority;
list session {
key "session-cookie";
ordered-by user;
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 leaf absolute {
unicast echo request CCs are sent and from which type yang:date-and-time;
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.";
}
leaf ttl {
type uint8;
default "255";
description
"Time to Live.";
}
leaf interval {
type Interval;
description
"Transmission interval for CC packets for this
session.";
}
leaf enable {
type boolean;
default "false";
description
"enable or disable a monitor session";
}
leaf ecmp-choice {
type ecmp-choices;
description
"0 means use the specified interface
1 means use round robin";
}
leaf source-mep {
type MEP-name;
description
"Source MEP for this session, if applicable";
}
container destination-mep {
uses MEP-ID;
description
"Destination MEP";
}
container destination-mep-address {
uses mp-address;
description
"Destination MEP Address";
}
uses connectivity-context;
uses flow-entropy;
uses priority;
list outgoing-interface {
key "interface";
leaf interface {
type if:interface-ref;
description
"Outgoing Interface";
}
description
"outgoing interfaces";
}
}
}
list MIP {
key "interface";
uses MIP;
description
"Maintenance Intermediate Point";
}
list related-oam-layer {
key "offset";
description
"List of OAM layers above and below that are related to
current MA. This allow users to easily navigate up and
down to efficiently troubleshoot a connectivity
issue";
uses related-oam-layer;
}
description description
"Maintenance Association list"; "This objects specifies the scheduled stop time
} to perform the on-demand monitoring operations.";
} }
} }
} }
}
notification defect-condition-notification { container domains {
description description
"When defect condition is met this notificiation is sent"; "Contains configuration related data. Within the container
uses maintenance-domain-id { is list of fault domains. Wihin each domian has List of MA.";
description list domain {
"defines the MD (Maintenance Domain) identifier, which is the key "technology MD-name-string";
Generic MD-name-string and the technology."; ordered-by system;
description
} "Define the list of Domains within the IETF-OAM";
uses ma-identifier; uses maintenance-domain-id;
leaf mep-name { uses MD-name;
type MEP-name; leaf md-level {
description type MD-level;
"Indicate which MEP is seeing the error"; description
} "Defines the MD-Level";
leaf defect-type { }
type identityref { container MAs {
base defect-types; description
} "This container defines MA, within that have multiple MA
description and within MA have MEP, MIP";
"The currently active defects on the specific MEP."; list MA {
} key "MA-name-string";
container generating-mepid { ordered-by system;
uses MEP-ID; uses ma-identifier;
description uses MA-name;
"Who is generating the error (if known) if uses connectivity-context;
unknown make it 0."; leaf mep-direction {
} type MEP-direction;
uses error-message { mandatory true;
description description
"Error message to indicate more details."; "Direction for MEPs in this MA";
} }
} leaf interval {
rpc continuity-check { type Interval;
description default "0";
"Generates continuity-check as per RFC7276 Table 4."; description
input { "Defines default Keepalive/CC Interval. May be
uses maintenance-domain-id { overridden for specific sessions if supported by the
description protocol.";
"defines the MD (Maintenance Domain) identifier, which is }
the generic leaf loss-threshold {
MD-name-string and the technology."; type uint32;
} default "3";
uses ma-identifier { description
description "number of consecutive Keepalive/CC messages missed
"identfies the Maintenance association"; before declaring loss of continuity fault. This is
} monitored per each remote MEP session";
uses flow-entropy; }
uses priority; leaf ttl {
leaf ttl { type uint8;
type uint8; default "255";
default "255";
description description
"Time to Live"; "Time to Live";
} }
uses session-type; uses flow-entropy {
leaf ecmp-choice { description
type ecmp-choices; "Default flow entropy in this MA, which may be
description overridden for particular MEPs, sessions or
"0 means use the specified interface operations";
1 means use round robin"; }
} uses priority {
leaf sub-type { description
type identityref { "Default priority for this MA, which may be overridden
base command-sub-type; for particular MEPs, sessions or operations.";
}
description
"defines different command types";
}
list outgoing-interfaces {
key "interface";
leaf interface {
type if:interface-ref;
description
"outgoing interface";
}
description
"outgoing Interfaces";
}
leaf source-mep {
type MEP-name;
description
"Source MEP";
}
container destination-mp {
uses mp-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 ping echo request message to send";
}
leaf interval {
type Interval;
description
"Interval between echo requests";
} }
leaf packet-size { list MEP {
type uint32 { key "mep-name";
range "64..10000"; ordered-by system;
} description
default "64"; "contain list of MEPS";
description uses MEP;
"Size of ping echo request packets, in octets"; uses interface-status {
} description
} "status of associated interface";
output { }
uses monitor-stats { uses flow-entropy;
description uses priority;
"Stats of continuity check."; list session {
} key "session-cookie";
} ordered-by user;
} 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.";
}
leaf ttl {
type uint8;
default "255";
description
"Time to Live.";
}
leaf interval {
type Interval;
description
"Transmission interval for CC packets for this
session.";
}
leaf enable {
type boolean;
default "false";
description
"enable or disable a monitor session";
rpc continuity-verification { }
if-feature connectivity-verification; leaf ecmp-choice {
description type ecmp-choices;
"Generates continuity-verification as per RFC7276 Table 4."; description
input { "0 means use the specified interface
uses maintenance-domain-id { 1 means use round robin";
description }
"defines the MD (Maintenance Domain) identifier, which is leaf source-mep {
the generic type MEP-name;
MD-name-string and the technology."; description
} "Source MEP for this session, if applicable";
uses ma-identifier { }
description container destination-mep {
"identfies the Maintenance association"; uses MEP-ID;
} description
uses flow-entropy;
uses priority;
leaf ttl {
type uint8;
default "255";
description
"Time to Live";
}
uses session-type;
leaf ecmp-choice {
type ecmp-choices;
description
"0 means use the specified interface
1 means use round robin";
}
leaf sub-type {
type identityref {
base command-sub-type;
}
description
"defines different command types";
}
list outgoing-interfaces {
key "interface";
leaf interface {
type if:interface-ref;
description
"outgoing interface";
}
description
"outgoing Interfaces";
}
leaf source-mep {
type MEP-name;
description
"Source MEP";
}
container destination-mp {
uses mp-address;
uses MEP-ID {
description "Only applicable if the destination is a MEP";
}
description
"Destination MEP"; "Destination MEP";
} }
leaf count { container destination-mep-address {
type uint32; uses mp-address;
default "3"; description
description "Destination MEP Address";
"Number of ping echo request message to send"; }
} uses connectivity-context;
leaf interval { uses flow-entropy;
type Interval; uses priority;
description list outgoing-interface {
"Interval between echo requests"; key "interface";
} leaf interface {
leaf packet-size { type if:interface-ref;
type uint32 { description
range "64..10000"; "Outgoing Interface";
} }
default "64"; description
description "outgoing interfaces";
"Size of ping echo request packets, in octets"; }
}
}
list MIP {
key "interface";
uses MIP;
description
"Maintenance Intermediate Point";
}
list related-oam-layer {
key "offset";
description
"List of OAM layers above and below that are related to
current MA. This allow users to easily navigate up and
down to efficiently troubleshoot a connectivity
issue";
uses related-oam-layer;
}
description
"Maintenance Association list";
}
}
}
}
} notification defect-condition-notification {
} description
output { "When defect condition is met this notificiation is sent";
uses monitor-stats { uses maintenance-domain-id {
description description
"Stats of continuity check."; "defines the MD (Maintenance Domain) identifier, which is the
} Generic MD-name-string and the technology.";
} }
} uses ma-identifier;
rpc path-discovery { leaf mep-name {
description type MEP-name;
"Generates Trace-route or Path Trace and return response. description
Referencing RFC7276 for common Toolset name, for IP it's "Indicate which MEP is seeing the error";
Traceroute, for MPLS OAM it's Traceroute mode, for }
MPLS-TP OAM it's Route Tracing, for Pseudowire OAM it's leaf defect-type {
LSP Ping, and for TRILL OAM It's Path Tracing tool. type identityref {
Starts with TTL base defect-types;
of one and increment by one at each hop. Untill destination }
reached or TTL reach max valune"; description
input { "The currently active defects on the specific MEP.";
uses maintenance-domain-id { }
description container generating-mepid {
"defines the MD (Maintenance Domain) identifier, which is uses MEP-ID;
the generic MD-name-string and the technology."; description
} "Who is generating the error (if known) if
uses ma-identifier { unknown make it 0.";
description }
"identfies the Maintenance association"; uses error-message {
} description
uses flow-entropy; "Error message to indicate more details.";
uses priority; }
leaf ttl { }
type uint8; rpc continuity-check {
default "255"; description
description "Generates continuity-check as per RFC7276 Table 4.";
"Time to Live"; input {
} uses maintenance-domain-id {
uses session-type; description
leaf command-sub-type { "defines the MD (Maintenance Domain) identifier, which is
type identityref { the generic
MD-name-string and the technology.";
}
uses ma-identifier {
description
"identfies the Maintenance association";
}
uses flow-entropy;
uses priority;
leaf ttl {
type uint8;
default "255";
description
"Time to Live";
}
uses session-type;
leaf ecmp-choice {
type ecmp-choices;
description
"0 means use the specified interface
1 means use round robin";
}
leaf sub-type {
type identityref {
base command-sub-type;
}
description
"defines different command types";
}
list outgoing-interfaces {
key "interface";
leaf interface {
type if:interface-ref;
description
"outgoing interface";
}
description
"outgoing Interfaces";
}
leaf source-mep {
type MEP-name;
description
"Source MEP";
}
container destination-mp {
uses mp-address;
uses MEP-ID {
description "Only applicable if the destination is a MEP";
}
description
"Destination MEP";
}
leaf count {
type uint32;
default "3";
description
base command-sub-type; "Number of ping echo request message to send";
} }
description leaf interval {
"defines different command types"; type Interval;
} description
leaf ecmp-choice { "Interval between echo requests";
type ecmp-choices; }
description leaf packet-size {
"0 means use the specified interface type uint32 {
1 means use round robin"; range "64..10000";
} }
list outgoing-interfaces { default "64";
key "interface"; description
leaf interface { "Size of ping echo request packets, in octets";
type if:interface-ref; }
description }
"Interface."; output {
} uses monitor-stats {
description description
"Outgoing interface list."; "Stats of continuity check.";
} }
leaf source-mep { }
type MEP-name; }
description
"Source MEP"; rpc continuity-verification {
} if-feature connectivity-verification;
container destination-mp { description
uses mp-address; "Generates continuity-verification as per RFC7276 Table 4.";
uses MEP-ID { input {
description "Only applicable if the destination is a MEP"; uses maintenance-domain-id {
} description
description "defines the MD (Maintenance Domain) identifier, which is
"Destination MEP"; the generic
} MD-name-string and the technology.";
leaf count { }
type uint32; uses ma-identifier {
default "1"; description
description "identfies the Maintenance association";
"Number of traceroute probes to send. In protocols where a }
separate message is sent at each TTL, this is the number uses flow-entropy;
of packets to send at each TTL."; uses priority;
} leaf ttl {
leaf interval { type uint8;
type Interval; default "255";
description description
"Interval between echo requests"; "Time to Live";
} }
} uses session-type;
output { leaf ecmp-choice {
list response { type ecmp-choices;
key "response-index"; description
leaf response-index { "0 means use the specified interface
type uint8; 1 means use round robin";
description }
"Arbitrary index for the response. In protocols that leaf sub-type {
guarantee there is only a single response at each TTL type identityref {
(eg IP Traceroute), the TTL can be used as the response base command-sub-type;
index."; }
} description
leaf ttl { "defines different command types";
type uint8; }
description list outgoing-interfaces {
"Time to Live"; key "interface";
} leaf interface {
container destination-mp { type if:interface-ref;
description "MP from which the response has been received"; description
uses mp-address; "outgoing interface";
uses MEP-ID { }
description description
"Only applicable if the destination is a MEP"; "outgoing Interfaces";
} }
} leaf source-mep {
uses monitor-stats { type MEP-name;
description description
"If count is 1, there is a single delay value reported."; "Source MEP";
} }
description container destination-mp {
"List of response."; uses mp-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 ping echo request message to send";
}
leaf interval {
type Interval;
description
"Interval between echo requests";
}
leaf packet-size {
type uint32 {
range "64..10000";
}
default "64";
description
"Size of ping echo request packets, in octets";
}
}
output {
uses monitor-stats {
description
"Stats of continuity check.";
}
}
}
rpc path-discovery {
description
"Generates Trace-route or Path Trace and return response.
Referencing RFC7276 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 increment
by one at each hop. Untill destination reached or TTL
reach max valune";
input {
uses maintenance-domain-id {
description
"defines the MD (Maintenance Domain) identifier, which is
the generic MD-name-string and the technology.";
}
uses ma-identifier {
description
"identfies the Maintenance association";
}
uses flow-entropy;
uses priority;
leaf ttl {
type uint8;
default "255";
description
"Time to Live";
}
uses session-type;
leaf command-sub-type {
type identityref {
base command-sub-type;
}
description
"defines different command types";
}
leaf ecmp-choice {
type ecmp-choices;
description
"0 means use the specified interface
1 means use round robin";
}
list outgoing-interfaces {
key "interface";
leaf interface {
type if:interface-ref;
description
"Interface.";
}
description
"Outgoing interface list.";
}
leaf source-mep {
type MEP-name;
description
"Source MEP";
}
container destination-mp {
uses mp-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 send at each TTL.";
}
leaf interval {
type Interval;
description
"Interval between echo requests";
}
}
output {
list response {
key "response-index";
leaf response-index {
type uint8;
description
"Arbitrary index for the response. In protocols that
guarantee there is only a single response at each TTL
, the TTL can be used as the response
index.";
}
leaf ttl {
type uint8;
description
"Time to Live";
}
container destination-mp {
description "MP from which the response has been received";
uses mp-address;
uses MEP-ID {
description
"Only applicable if the destination is a MEP";
}
}
uses monitor-stats {
description
"Stats of path-discovery.";
}
description
"List of response.";
}
}
}
}
YANG module of OAM YANG module of OAM
<CODE ENDS> <CODE ENDS>
6. Base Mode 6. Base Mode
The Base Mode defines default configuration that MUST be present in The Base Mode defines default configuration that MUST be present in
the devices that comply with this document. Base Mode allows users the devices that comply with this document. Base Mode allows users
to have "zero-touch" experience. Several parameters require to have "zero-touch" experience. Several parameters require
 End of changes. 103 change blocks. 
1197 lines changed or deleted 1168 lines changed or added

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