< draft-ietf-lime-yang-connectionless-oam-13.txt   draft-ietf-lime-yang-connectionless-oam-14.txt >
Network Working Group D. Kumar Network Working Group D. Kumar
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track M. Wang Intended status: Standards Track M. Wang
Expires: April 26, 2018 Q. Wu Expires: April 27, 2018 Q. Wu
Huawei Huawei
R. Rahman R. Rahman
S. Raghavan S. Raghavan
Cisco Cisco
October 23, 2017 October 24, 2017
Generic YANG Data Model for Operations, Administration, and Generic YANG Data Model for the Management of Operations,
Maintenance(OAM) protocols for Connectionless networks Administration, and Maintenance (OAM) Protocols that use Connectionless
draft-ietf-lime-yang-connectionless-oam-13 Communications
draft-ietf-lime-yang-connectionless-oam-14
Abstract Abstract
This document presents a base YANG Data model for connectionless This document presents a base YANG Data model for connectionless
Operations Administration, and Maintenance(OAM) protocols. It Operations Administration, and Maintenance(OAM) protocols. The data
provides a technology-independent abstraction of key OAM constructs model is defined using the YANG in RFC7950 data modeling language.
for connectionless protocols. The base model presented here can be It provides a technology-independent abstraction of key OAM
extended to include technology specific details. This is leading to constructs for connectionless protocols. The base model presented
uniformity between OAM protocols and support both nested OAM here can be extended to include technology specific details. This is
workflows (i.e., performing OAM functions at different or same levels leading to uniformity between OAM protocols and support both nested
through a unified interface) and interacting OAM workflows ( i.e., OAM workflows (i.e., performing OAM functions at different or same
performing OAM functions at same levels through a unified interface). levels through a unified interface) and interacting OAM workflows
(i.e., performing OAM functions at same 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 26, 2018. This Internet-Draft will expire on April 27, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the Connectionless OAM Model . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. TP Address . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of the Connectionless OAM Model . . . . . . . . . . 5
3.1. TP Address . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. OAM neighboring test points . . . . . . . . . . . . . . . 6 3.3. OAM neighboring test points . . . . . . . . . . . . . . . 7
3.4. Test Point Locations Information . . . . . . . . . . . . 7 3.4. Test Point Locations Information . . . . . . . . . . . . 8
3.5. Test Point Locations . . . . . . . . . . . . . . . . . . 7 3.5. Test Point Locations . . . . . . . . . . . . . . . . . . 8
3.6. Path Discovery Data . . . . . . . . . . . . . . . . . . . 7 3.6. Path Discovery Data . . . . . . . . . . . . . . . . . . . 9
3.7. Continuity Check Data . . . . . . . . . . . . . . . . . . 8 3.7. Continuity Check Data . . . . . . . . . . . . . . . . . . 9
3.8. OAM data hierarchy . . . . . . . . . . . . . . . . . . . 8 3.8. OAM data hierarchy . . . . . . . . . . . . . . . . . . . 9
4. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11 4. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12
5. Connectionless model applicability . . . . . . . . . . . . . 39 5. Connectionless model applicability . . . . . . . . . . . . . 40
5.1. BFD Extension . . . . . . . . . . . . . . . . . . . . . . 39 5.1. BFD Extension . . . . . . . . . . . . . . . . . . . . . . 40
5.1.1. Augment Method . . . . . . . . . . . . . . . . . . . 39 5.1.1. Augment Method . . . . . . . . . . . . . . . . . . . 41
5.1.2. Schema Mount . . . . . . . . . . . . . . . . . . . . 42 5.1.2. Schema Mount . . . . . . . . . . . . . . . . . . . . 43
5.2. LSP ping extension . . . . . . . . . . . . . . . . . . . 44 5.2. LSP ping extension . . . . . . . . . . . . . . . . . . . 45
5.2.1. Augment Method . . . . . . . . . . . . . . . . . . . 44 5.2.1. Augment Method . . . . . . . . . . . . . . . . . . . 45
5.2.2. Schema Mount . . . . . . . . . . . . . . . . . . . . 45 5.2.2. Schema Mount . . . . . . . . . . . . . . . . . . . . 46
6. Security Considerations . . . . . . . . . . . . . . . . . . . 47 6. Security Considerations . . . . . . . . . . . . . . . . . . . 48
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 49 8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 50
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.1. Normative References . . . . . . . . . . . . . . . . . . 49 9.1. Normative References . . . . . . . . . . . . . . . . . . 50
9.2. Informative References . . . . . . . . . . . . . . . . . 50 9.2. Informative References . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
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 (Reachability Verification, 1. Monitor networks communication (Reachability Verification,
Continuity Check). Continuity Check).
2. Troubleshoot failures (Fault verification and localization). 2. Troubleshoot failures (Fault verification and localization).
3. Monitor Performance 3. Monitor Performance
An overview of OAM tools is presented at [RFC7276]. An overview of OAM tools is presented at [RFC7276].
Ping and Traceroute [RFC792], [RFC4443] are well-known fault Ping and Traceroute [RFC792], [RFC4443] are well-known fault
verification and isolation tools, respectively, for IP networks. verification and isolation tools, respectively, for IP networks.
skipping to change at page 3, line 32 skipping to change at page 3, line 32
for similar purposes. for similar purposes.
The different OAM tools may support connection-oriented technologies The different OAM tools may support 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 of data. After a connection is established prior to the transmission of data. After
connection is established, no additional control information such as connection is established, no additional control information such as
signaling or operations and maintenance information is required to signaling or operations and maintenance information is required to
transmit the data. In connectionless technologies, data is typically transmit the data. In connectionless technologies, data is typically
sent between end points without prior arrangement, but control sent between end points without prior arrangement, but control
information is required to identify destination.[G.800][RFC7276]. information is required to identify destination.[G.800][RFC7276].
Note that the Connection-Oriented OAM YANG DATA model is defined in Note that the YANG Data model for OAM protcols using connection-
oriented communications is defined in
[I-D.ietf-lime-yang-connection-oriented-oam-model]. [I-D.ietf-lime-yang-connection-oriented-oam-model].
In this document, we presents a base YANG Data model for This document defines a base YANG Data model for connectionless OAM
connectionless OAM protocols. The generic YANG model for protocols. The data model is defined using the YANG [RFC7950] data
connectionless OAM only includes configuration data and state data. modeling language. This generic YANG model for connectionless OAM
It can be used in conjunction with data retrieval method model only includes configuration data and state data. It can be used in
conjunction with data retrieval method model described in
[I-D.ietf-lime-yang-connectionless-oam-methods], which focuses on [I-D.ietf-lime-yang-connectionless-oam-methods], which focuses on
data retrieval procedures like RPC. However it also can be used data retrieval procedures such as RPC. However it also can be used
independently of data retrieval method model. independently of this data retrieval method model.
2. Conventions used in this document 2. Conventions used in this document
The following terms are defined in [RFC6241] and are not redefined The following terms are defined in [RFC6241] and are not redefined
here: here:
o client o client
o configuration data o configuration data
o server o server
o state data o state data
The following terms are defined in [RFC6020] and are not redefined The following terms are defined in [RFC7950] and are not redefined
here: here:
o augment o augment
o data model o data model
o data node o data node
The terminology for describing YANG data models is found in The terminology for describing YANG data models is found in
[RFC6020]. [RFC7950].
2.1. Terminology 2.1. Abbreviations
TP - Test Point BFD - Bidirectional Forwarding Detection [RFC5880].
MAC - Media Access Control RPC - A Remote Procedure Call [RFC1831].
BFD - Bidirectional Forwarding Detection DSCP - Differentiated Services Code Point.
RPC - A Remote Procedure Call VRF - Virtual Routing and Forwarding (VRF) [RFC 4382].
OWAMP - One-Way Active Measurement Protocol [RFC 4656].
TWAMP - Two-Way Active Measurement Protocol (TWAMP) [RFC 5357].
AS - Autonomous System.
LSP - Label Switched Path.
TE - Traffic Engineering.
MPLS - Multiprotocol Label Switching.
PTP - Precision Time Protocol [IEEE.1588].
NTP - Network Time Protocol [RFC5905].
2.2. Terminology
MAC address- Address for data link layer interface.
TP - Test Point. Test point is a functional entity that is defined
at a node in the network and can initiate and/or react to OAM
diagnostic test. This document focuses on the data-plane
functionality of TPs, while TPs interact with the control plane and
with the management plane as well.
RPC operation - A specific Remote Procedure Call. RPC operation - A specific Remote Procedure Call.
CC - Continuity Check [RFC7276] , Continuity Checks are used to CC - Continuity Check.[RFC7276], Continuity Checks are used to verify
verify that a destination is reachable and therefore also referred to that a destination is reachable and therefore also referred to as
as reachability verification reachability verification.
3. Overview of the Connectionless OAM Model 3. Overview of the Connectionless OAM Model
The model is augmented to "/nd:networks/nd:network/nd:node" The model augments "/networks/network/node" path defined in the ietf-
[I-D.ietf-i2rs-yang-network-topo] using 'test-point-locations' network module [I-D.ietf-i2rs-yang-network-topo] with 'test-point-
defined in Section 3.5. The tool attribute 'tp-tools' grouping locations' grouping defined in Section 3.5. The network node in
defined in this model is corresponding to technology-independent "/networks/network/node" path are used to describe the network
retrieval procedures (RPC operations) defined in hierarchies and the inventory of nodes contained in a network.
[I-D.ietf-lime-yang-connectionless-oam-methods] and supports one of
two basic types of activation: proactive and on-demand (determined by
'session-type' grouping defined in this model, see section 3.2).
At the top of the model, there is an 'cc-oper-data' container for Under the 'test-point-locations' grouping, each test point location
session statistics. Grouping is also defined for common session is chosen based on 'tp-location-type' leaf which when chosen, leads
statistics and these are only applicable for proactive OAM sessions. to a container that includes a list of 'test-point-locations'.
Multiple 'test-point-locations' keyed using technology specific keys Each 'test-point-locations' list includes a 'test-point-location-
(eg., IPv4 address for IPv4 locations) are augmented into network info' grouping. The 'test-point-location-info' grouping includes:
nodes which are defined in [I-D.ietf-i2rs-yang-network-topo] to
describe the network hierarchies and the inventory of nodes contained o 'tp-technology' grouping,
in a network. Each test point location under 'test-point-locations
'grouping is chosen based on 'tp-location-type' leaf which when o 'tp-tools' grouping,
chosen, leads to a container that includes a list of 'test-point-
locations' keyed by technology specific keys (e.g., 'ipv4-location' o and 'connectionless-oam-tps' grouping.
leaf ). Each test point location under 'test-point-locations
'grouping includes a 'test-point-location-info' grouping. The 'test- The groupings of 'tp-address' and 'tp-address-ni' are kept out of
point-location-info' grouping includes 'tp-technology' grouping, 'tp- 'test- point-location-info' grouping to make it addressing agnostic
tools' grouping, and 'connectionless-oam-tps' grouping. The and allow varied composition. Depending upon the choice of the 'tp-
groupings of 'tp-address' and 'tp-address-ni' are kept out of 'test-
point-location-info' grouping to make it addressing agnostic and
allow varied composition. Depending upon the choice of the 'tp-
location-type' (determined by the 'tp-address-ni'), the containers location-type' (determined by the 'tp-address-ni'), the containers
differ in its composition of 'test- point-locations' while the 'test- differ in its composition of 'test-point-locations' while the 'test-
point-location-info', is a common aspect of every 'test-point- point-location-info', is a common aspect of every 'test-point-
locations'. The 'tp-address-ni' grouping is used to describe the locations'.
corresponding network instance. The 'tp-technology'grouping indicate
OAM technology details. The 'tp-tools' grouping describe the OAM The 'tp-address-ni' grouping is used to describe the corresponding
tools supported. The 'connectionless-oam-tps' grouping is used to network instance. The 'tp-technology' grouping indicate OAM
technology details. The 'connectionless-oam-tps' grouping is used to
describe the relationship of one test point with other test points. describe the relationship of one test point with other test points.
The 'position' in 'oam-neighboring-tps' indicate relative position of The 'tp-tools' grouping describe the OAM tools supported.
neighboring test point corresponding to the current test point.
In addition, at the top of the model, there is an 'cc-oper-data'
container for session statistics. Grouping is also defined for
common session statistics and these are only applicable for proactive
OAM sessions.
3.1. TP Address 3.1. TP Address
In connectionless OAM, the TP address is defined with the following With connectionless OAM protocols, the TP address can be one of the
type: following types:
o MAC address [RFC6136] o MAC address [RFC6136] at link layer for TPs
o IPv4 or IPv6 address o IPv4 or IPv6 address at IP layer for TPs
o TP-attribute o TP-attribute identifying a TP associated with an application layer
function
o System-id to represent the device or o System-id to represent the device or node.
node.[I-D.ietf-spring-sr-yang] [I-D.ietf-spring-sr-yang]
To define a forwarding treatment of a test packet, the 'tp- To define a forwarding treatment of a test packet, the 'tp-address'
address'grouping needs to be associated with additional parameters, grouping needs to be associated with additional parameters, e.g.,
e.g. DSCP for IP or EXP (renamed to Traffic Classic in RFC5462) for DSCP for IP or EXP (renamed to Traffic Classic in [RFC5462]) for
MPLS. In generic connectionless OAM YANG model, these parameters are MPLS. In generic connectionless OAM YANG model, these parameters are
not explicit configured. The model user can add corresponding not explicit configured. The model user can add corresponding
parameters according to their requirements. parameters according to their requirements.
3.2. Tools 3.2. Tools
The different OAM tools may be used in one of two basic types of The different OAM tools may be used in one of two basic types of
activation: proactive and on-demand. The proactive OAM refers to OAM activation: proactive and on-demand. The proactive OAM refers to OAM
actions which are carried out continuously to permit proactive actions which are carried out continuously to permit proactive
reporting of fault. The proactive OAM method requires persistent reporting of fault. The proactive OAM method requires persistent
skipping to change at page 6, line 27 skipping to change at page 7, line 7
In connectionless OAM, the tools attribute is used to describe a In connectionless OAM, the tools attribute is used to describe a
toolset for fault detection and isolation. And it can serve as a toolset for fault detection and isolation. And it can serve as a
constraint condition when the base model be extended to specific OAM constraint condition when the base model be extended to specific OAM
technology. For example, to fulfill the ICMP PING configuration, the technology. For example, to fulfill the ICMP PING configuration, the
"../coam:continuity-check" leaf should be set to "true", and then the "../coam:continuity-check" leaf should be set to "true", and then the
lime base model should be augmented with ICMP PING specific details. lime base model should be augmented with ICMP PING specific details.
3.3. OAM neighboring test points 3.3. OAM neighboring test points
As typical networks have a multi-layer architecture, the set of OAM As typical network communication stacks have a multi-layer
protocols similarly take a multi-layer structure; each layer may have architecture, the set of associated OAM protocols may similarly have
its own OAM protocol [RFC7276] corresponding to a specific a multi-layer structure; each communication layer in the stack may
administrative domain and has associated test points. OAM have its own OAM protocol [RFC7276] that may also be linked to a
neighboring test points are referred to a list of neighboring test specific administrative domain. Management of these OAM protocols
points in the same layer that are related to the current test point. will necessitate associated test points in the nodes accessible by
This allows users to easily navigate between related neighboring appropriate management domains. Accordingly, a given network
layers to efficiently troubleshoot a defect. In this model, the interface may present several test points.
'position' leaf defines the relative position of the neighboring test
point corresponding to the current test point in the same layer, and OAM neighboring test points are referred to a list of neighboring
is provided to allow correlation of faults at different locations. test points in adjacent layers up and down the stack for the same
If there is one neighboring test point placed before the current test interface that are related to the current test point. This allows
point, the 'position' leaf is set to -1. If there is one neighboring users to easily navigate between related neighboring layers to
test point placed after the current test point, the 'position' leaf efficiently troubleshoot a defect. In this model, the 'position'
is set to 1. If there is no neighboring test point placed before or leaf defines the relative position of the neighboring test point
after the current test point, the 'position' leaf is set to 0. corresponding to the current test point, and is provided to allow
correlation of faults at different locations. If there is one
neighboring test point placed before the current test point, the
'position' leaf is set to -1. If there is one neighboring test point
placed after the current test point, the 'position' leaf is set to 1.
If there is no neighboring test point placed before or after the
current test point, the 'position' leaf is set to 0.
list oam-neighboring-tps { list oam-neighboring-tps {
key "index"; key "index";
leaf index { leaf index {
type uint16 { type uint16 {
range "0..65536"; range "0..65536";
} }
description description
"Index of a list of neighboring test points "Index of a list of neighboring test points
in the same layer "; in adjacent layers up and down the stack for
the same interface that are related to the
current test point.";
} }
leaf position { leaf position {
type int8 { type int8 {
range "-1..1"; range "-1..1";
} }
description description
"The relative position "The relative position
of neighboring test point of neighboring test point
corresponding to the current corresponding to the current
test point"; test point";
} }
description description
"List of related neighboring test points in the same layer."; "List of related neighboring test points in adjacent
layers up and down the stack for the same interface
that are related to the current test point.";
} }
3.4. Test Point Locations Information 3.4. Test Point Locations Information
This is a generic grouping for Test Point Locations Information This is a generic grouping for Test Point Locations Information
(i.e., test-point-location-info grouping). It Provide details of (i.e., test-point-location-info grouping). It Provide details of
Test Point Location using 'tp-technology','tp-tools' grouping, 'oam- Test Point Location using 'tp-technology','tp-tools' grouping, 'oam-
neighboring-tps' grouping defined above. neighboring-tps' grouping defined above.
3.5. Test Point Locations 3.5. Test Point Locations
This is a generic grouping for Test Point Locations. 'tp-location- This is a generic grouping for Test Point Locations. 'tp-location-
type 'leaf is used to define locations types, for example 'ipv4- type 'leaf is used to define locations types, for example 'ipv4-
location-type', 'ipv6-location-type', etc. Container is defined location-type', 'ipv6-location-type', etc. Container is defined
under each location type containing list keyed to test point address, under each location type containing list keyed to test point address,
Test Point Location Information defined in section above, and network Test Point Location Information defined in section above, and network
instance name(e.g.,VRF instance name) if required. instance name(e.g., VRF instance name) if required.
3.6. Path Discovery Data 3.6. Path Discovery Data
This is a generic grouping for path discovery data model that can be This is a generic grouping for path discovery data model that can be
retrieved by any data retrieval methods including RPC operations. retrieved by any data retrieval methods including RPC operations.
Path discovery data output from methods, includes 'src-test-point' Path discovery data output from methods, includes 'src-test-point'
container, 'dst-test-point' container, 'sequence-number'leaf, 'hop- container, 'dst-test-point' container, 'sequence-number'leaf, 'hop-
cnt'leaf, session statistics of various kinds, path verification and cnt'leaf, session statistics of various kinds, path verification and
path trace related information. Path discovery includes data to be path trace related information. Path discovery includes data to be
retrieved on a 'per- hop' basis via a list of 'path-trace-info- retrieved on a 'per-hop' basis via a list of 'path-trace-info-
list'list which includes information like 'timestamp'grouping, ' list'list which includes information like 'timestamp'grouping, '
ingress-intf-name ', ' egress-intf-name ' and 'app-meta-data'. The ingress-intf-name ', ' egress-intf-name ' and 'app-meta-data'. The
path discovery data model is made generic enough to allow different path discovery data model is made generic enough to allow different
methods of data retrieval. None of the fields are made mandatory for methods of data retrieval. None of the fields are made mandatory for
that reason. Noted that the retrieval methods are defined in that reason. Noted that the retrieval methods are defined in
[I-D.ietf-lime-yang-connectionless-oam-methods]. [I-D.ietf-lime-yang-connectionless-oam-methods].
3.7. Continuity Check Data 3.7. Continuity Check Data
This is a generic grouping for continuity check data model that can This is a generic grouping for continuity check data model that can
skipping to change at page 12, line 25 skipping to change at page 13, line 32
organization organization
"IETF LIME Working Group"; "IETF LIME Working Group";
contact contact
"Deepak Kumar dekumar@cisco.com "Deepak Kumar dekumar@cisco.com
Qin Wu bill.wu@huawei.com Qin Wu bill.wu@huawei.com
S Raghavan srihari@cisco.com S Raghavan srihari@cisco.com
Zitao Wang wangzitao@huawei.com Zitao Wang wangzitao@huawei.com
R Rahman rrahman@cisco.com"; R Rahman rrahman@cisco.com";
description description
"This YANG module defines the generic configuration, "This YANG module defines the generic configuration,
data model, statistics for connectionless OAM to be data model, and statistics for OAM protocols using
used within IETF in a protocol independent manner. connectionless communications, described in a
It is assumed that each protocol maps corresponding protocol independent manner.It is assumed that each
abstracts to its native format. Each protocol may protocol maps corresponding abstracts to its native
extend the YANG model defined here to include protocol format. Each protocol mayextend the YANG model defined
specific extensions"; here to include protocol specific extensions.";
revision 2017-09-06 { revision 2017-09-06 {
description description
" Base model for Connectionless " Base model for Connectionless
Operations, Administration, Operations, Administration,
and Maintenance(OAM) "; and Maintenance(OAM) ";
reference reference
" RFC XXXX: Connectionless " RFC XXXX: Connectionless
Operations, Administration, and Operations, Administration, and
Maintenance(OAM)YANG Data Model"; Maintenance(OAM)YANG Data Model";
} }
feature connection-less { feature connectionless {
description description
"This feature indicates that OAM solution is connection less."; "This feature indicates that OAM solution is connectionless.";
} }
feature continuity-check { feature continuity-check {
description description
"This feature indicates that the server supports "This feature indicates that the server supports
executing continuity check OAM command and executing continuity check OAM command and
returning a response. Servers that do not advertise returning a response. Servers that do not advertise
this feature will not support executing this feature will not support executing
continuity check command or rpc operation model for continuity check command or RPC operation model for
continuity check command."; continuity check command.";
} }
feature path-discovery { feature path-discovery {
description description
"This feature indicates that the server supports "This feature indicates that the server supports
executing path discovery OAM command and executing path discovery OAM command and
returning a response. Servers that do not advertise returning a response. Servers that do not advertise
this feature will not support executing this feature will not support executing
path discovery command or rpc operation model for path discovery command or RPC operation model for
path discovery command."; path discovery command.";
} }
feature ptp-long-format { feature ptp-long-format {
description description
"This feature indicates that timestamp is ptp long format."; "This feature indicates that timestamp is PTP long format.";
} }
feature ntp-short-format { feature ntp-short-format {
description description
"This feature indicates that timestamp is ntp short format."; "This feature indicates that timestamp is NTP short format.";
} }
feature icmp-timestamp { feature icmp-timestamp {
description description
"This feature indicates that timestamp is icmp timestamp."; "This feature indicates that timestamp is ICMP timestamp.";
} }
typedef router-id { typedef router-id {
type yang:dotted-quad; type yang:dotted-quad;
description description
"A 32-bit number in the dotted quad format assigned to each "A 32-bit number in the dotted quad format assigned to each
router. This number uniquely identifies the router within an router. This number uniquely identifies the router within an
Autonomous System."; Autonomous System.";
} }
typedef routing-instance-ref { typedef routing-instance-ref {
type leafref { type leafref {
skipping to change at page 14, line 7 skipping to change at page 15, line 13
attribute types which are ip-prefix, attribute types which are ip-prefix,
bgp, tunnel, pwe3, vpls, etc."; bgp, tunnel, pwe3, vpls, etc.";
} }
typedef address-attribute-type { typedef address-attribute-type {
type identityref { type identityref {
base address-attribute-types; base address-attribute-types;
} }
description description
"Target address attribute type."; "Target address attribute type.";
} }
typedef percentage {
type decimal64 {
fraction-digits 5;
}
description "Percentage";
}
identity time-interval-type { identity time-interval-type {
description description
"Time interval type"; "Time interval type";
} }
identity hours { identity hours {
base time-interval-type; base time-interval-type;
description description
"Time unit in Hours"; "Time unit in Hours";
} }
skipping to change at page 18, line 27 skipping to change at page 19, line 39
leaf packet-loss-count { leaf packet-loss-count {
type uint32 { type uint32 {
range "0..4294967295"; range "0..4294967295";
} }
default "0"; default "0";
description description
"Total received packet drops count. "Total received packet drops count.
If the value is 4294967295, it indicates If the value is 4294967295, it indicates
packet drops count is overrun."; packet drops count is overrun.";
} }
leaf loss-ratio{ leaf loss-ratio{
type uint8{ type percentage;
range 0..100;
}
description description
"Loss ratio of the packets. Express as percentage "Loss ratio of the packets. Express as percentage
of packets lost with respect to packets sent."; of packets lost with respect to packets sent.";
} }
leaf packet-reorder-count { leaf packet-reorder-count {
type uint32 { type uint32 {
range "0..4294967295"; range "0..4294967295";
} }
default "0"; default "0";
description description
skipping to change at page 20, line 16 skipping to change at page 21, line 26
} }
} }
grouping session-jitter-statistics { grouping session-jitter-statistics {
description description
"Grouping for per session jitter statistics"; "Grouping for per session jitter statistics";
container session-jitter-statistics { container session-jitter-statistics {
description description
"Session jitter summarised information. By default, "Session jitter summarised information. By default,
jitter is measured using IP Packet Delay Variation jitter is measured using IP Packet Delay Variation
(IPDV) as defined in RFC3393. When the other measurement (IPDV) as defined in RFC3393. When the other measurement
method is used instead(e.g.,Packet Delay Variation used in method is used instead(e.g., Packet Delay Variation used in
Y.1540, it can be indicated using protocol-id-meta-data Y.1540, it can be indicated using protocol-id-meta-data
defined in RPC operation of defined in RPC operation of
draft-ietf-lime-yang-connectionless-oam-methods. Note that draft-ietf-lime-yang-connectionless-oam-methods. Note that
only one measurement method for jitter is specified only one measurement method for jitter is specified
for interoperability reason."; for interoperability reason.";
leaf interval-value { leaf interval-value {
type identityref { type identityref {
base time-interval-type; base time-interval-type;
} }
skipping to change at page 22, line 42 skipping to change at page 24, line 4
} }
identity as-number-address-type { identity as-number-address-type {
base tp-address-technology-type; base tp-address-technology-type;
description description
"AS number address type"; "AS number address type";
} }
identity route-distinguisher-address-type { identity route-distinguisher-address-type {
base tp-address-technology-type; base tp-address-technology-type;
description description
"Route Distinguisher address type"; "Route Distinguisher address type";
} }
grouping tp-address { grouping tp-address {
leaf tp-location-type { leaf tp-location-type {
type identityref { type identityref {
base tp-address-technology-type; base tp-address-technology-type;
} }
mandatory true; mandatory true;
description description
"Test point address type."; "Test point address type.";
} }
container mac-address { container mac-address {
when "derived-from-or-self(../tp-location-type, 'cl-oam:mac-address-type')" { when "derived-from-or-self(../tp-location-type,"+
"'cl-oam:mac-address-type')" {
description description
"MAC address type"; "MAC address type";
} }
leaf mac-address { leaf mac-address {
type yang:mac-address; type yang:mac-address;
mandatory true; mandatory true;
description description
"MAC Address"; "MAC Address";
} }
description description
"MAC Address based MP Addressing."; "MAC Address based TP Addressing.";
} }
container ipv4-address { container ipv4-address {
when "derived-from-or-self(../tp-location-type, 'cl-oam:ipv4-address-type')" { when "derived-from-or-self(../tp-location-type,"+
"'cl-oam:ipv4-address-type')" {
description description
"IPv4 address type"; "IPv4 address type";
} }
leaf ipv4-address { leaf ipv4-address {
type inet:ipv4-address; type inet:ipv4-address;
mandatory true; mandatory true;
description description
"IPv4 Address"; "IPv4 Address";
} }
description description
"IP Address based MP Addressing."; "IP Address based TP Addressing.";
} }
container ipv6-address { container ipv6-address {
when "derived-from-or-self(../tp-location-type, 'cl-oam:ipv6-address-type')" { when "derived-from-or-self(../tp-location-type,"+
"'cl-oam:ipv6-address-type')" {
description description
"IPv6 address type"; "IPv6 address type";
} }
leaf ipv6-address { leaf ipv6-address {
type inet:ipv6-address; type inet:ipv6-address;
mandatory true; mandatory true;
description description
"IPv6 Address"; "IPv6 Address";
} }
description description
"ipv6 Address based MP Addressing."; "ipv6 Address based TP Addressing.";
} }
container tp-attribute { container tp-attribute {
when "derived-from-or-self(../tp-location-type, 'cl-oam:tp-attribute-type')" { when "derived-from-or-self(../tp-location-type,"+
"'cl-oam:tp-attribute-type')" {
description description
"Test point attribute type"; "Test point attribute type";
} }
leaf tp-attribute-type { leaf tp-attribute-type {
type address-attribute-type; type address-attribute-type;
description description
"Test point type."; "Test point type.";
} }
choice tp-attribute-value { choice tp-attribute-value {
description description
skipping to change at page 26, line 26 skipping to change at page 27, line 40
Switched (MPLS) Data Plane Failures"; Switched (MPLS) Data Plane Failures";
} }
} }
} }
} }
} }
description description
"Test Point Attribute Container"; "Test Point Attribute Container";
} }
container system-info { container system-info {
when "derived-from-or-self(../tp-location-type, 'cl-oam:system-id-address-type')" { when "derived-from-or-self(../tp-location-type,"+
"'cl-oam:system-id-address-type')" {
description description
"System id address type"; "System id address type";
} }
leaf system-id { leaf system-id {
type rt:router-id; type rt:router-id;
description description
"System ID assigned to this node."; "System ID assigned to this node.";
} }
description description
skipping to change at page 27, line 4 skipping to change at page 28, line 19
grouping tp-address-ni { grouping tp-address-ni {
description description
"Test point address with VRF."; "Test point address with VRF.";
leaf ni { leaf ni {
type routing-instance-ref; type routing-instance-ref;
description description
"The ni is used to describe virtual resource partitioning "The ni is used to describe virtual resource partitioning
that may be present on a network device.Example of common that may be present on a network device.Example of common
industry terms for virtual resource partitioning is VRF industry terms for virtual resource partitioning is VRF
instance."; instance.";
} }
uses tp-address; uses tp-address;
} }
grouping connectionless-oam-tps { grouping connectionless-oam-tps {
list oam-neighboring-tps { list oam-neighboring-tps {
key "index"; key "index";
leaf index { leaf index {
type uint16{ type uint16{
range "0..65535"; range "0..65535";
} }
description description
"Index of a list of neighboring test points "List of related neighboring test points in adjacent
in the same layer"; layers up and down the stack for the same interface
that are related to the current test point";
} }
leaf position { leaf position {
type int8 { type int8 {
range "-1..1"; range "-1..1";
} }
default "0"; default "0";
description description
"The relative position "The relative position
of neighboring test point of neighboring test point
corresponding to the current corresponding to the current
skipping to change at page 27, line 31 skipping to change at page 28, line 46
range "-1..1"; range "-1..1";
} }
default "0"; default "0";
description description
"The relative position "The relative position
of neighboring test point of neighboring test point
corresponding to the current corresponding to the current
test point.Level 0 indicates no neighboring test point.Level 0 indicates no neighboring
test points placed before or after the current test points placed before or after the current
test point in the same layer.-1 means there is test point in the same layer.-1 means there is
a neighboring test point placed before the current a neighboring test point placed before the current
test point in the same layer and +1 means there is test point in the same layer and +1 means there is
a neighboring test point placed after the current a neighboring test point placed after the current
test point in same layer."; test point in same layer.";
} }
choice tp-location { choice tp-location {
case mac-address { case mac-address {
leaf mac-address-location { leaf mac-address-location {
type yang:mac-address; type yang:mac-address;
description description
"MAC Address"; "MAC Address";
} }
description description
"MAC Address based MP Addressing."; "MAC Address based TP Addressing.";
} }
case ipv4-address { case ipv4-address {
leaf ipv4-address-location { leaf ipv4-address-location {
type inet:ipv4-address; type inet:ipv4-address;
description description
"Ipv4 Address"; "Ipv4 Address";
} }
description description
"IP Address based MP Addressing."; "IP Address based TP Addressing.";
} }
case ipv6-address { case ipv6-address {
leaf ipv6-address-location { leaf ipv6-address-location {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 Address"; "IPv6 Address";
} }
description description
"IPv6 Address based MP Addressing."; "IPv6 Address based TP Addressing.";
} }
case as-number { case as-number {
leaf as-number-location { leaf as-number-location {
type inet:as-number; type inet:as-number;
description description
"AS number location"; "AS number location";
} }
description description
"AS number for point to multipoint OAM"; "AS number for point to multipoint OAM";
} }
skipping to change at page 30, line 31 skipping to change at page 31, line 47
"Root for models supported per "Root for models supported per
test point"; test point";
} }
uses connectionless-oam-tps; uses connectionless-oam-tps;
description description
"Test point Location"; "Test point Location";
} }
grouping test-point-locations { grouping test-point-locations {
description description
"Group of test point locations."; "Group of test point locations.";
leaf tp-location-type { leaf tp-location-type {
type identityref { type identityref {
base tp-address-technology-type; base tp-address-technology-type;
} }
description description
"Test point location type."; "Test point location type.";
} }
container ipv4-location-type { container ipv4-location-type {
when "derived-from-or-self(../tp-location-type, 'cl-oam:ipv4-address-type')" { when "derived-from-or-self(../tp-location-type,"+
"'cl-oam:ipv4-address-type')" {
description description
"When test point location type is equal to ipv4 address."; "When test point location type is equal to ipv4 address.";
} }
container test-point-ipv4-location-list { container test-point-ipv4-location-list {
list test-point-locations { list test-point-locations {
key "ipv4-location ni"; key "ipv4-location ni";
leaf ipv4-location { leaf ipv4-location {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 Address."; "IPv4 Address.";
skipping to change at page 31, line 22 skipping to change at page 32, line 38
"List of test point locations."; "List of test point locations.";
} }
description description
"Serves as top-level container "Serves as top-level container
for test point location list."; for test point location list.";
} }
description description
"ipv4 location type container."; "ipv4 location type container.";
} }
container ipv6-location-type { container ipv6-location-type {
when "derived-from-or-self(../tp-location-type, 'cl-oam:ipv6-address-type')" { when "derived-from-or-self(../tp-location-type,"+
"'cl-oam:ipv6-address-type')" {
description description
"when test point location is equal to ipv6 address"; "when test point location is equal to ipv6 address";
} }
container test-point-ipv6-location-list { container test-point-ipv6-location-list {
list test-point-locations { list test-point-locations {
key "ipv6-location ni"; key "ipv6-location ni";
leaf ipv6-location { leaf ipv6-location {
type inet:ipv6-address; type inet:ipv6-address;
description description
skipping to change at page 32, line 5 skipping to change at page 33, line 21
"List of test point locations."; "List of test point locations.";
} }
description description
"Serves as top-level container "Serves as top-level container
for test point location list."; for test point location list.";
} }
description description
"ipv6 location type container."; "ipv6 location type container.";
} }
container mac-location-type { container mac-location-type {
when "derived-from-or-self(../tp-location-type, 'cl-oam:mac-address-type')" { when "derived-from-or-self(../tp-location-type,"+
"'cl-oam:mac-address-type')" {
description description
"when test point location type is equal to mac address."; "when test point location type is equal to mac address.";
} }
container test-point-mac-address-location-list { container test-point-mac-address-location-list {
list test-point-locations { list test-point-locations {
key "mac-address-location"; key "mac-address-location";
leaf mac-address-location { leaf mac-address-location {
type yang:mac-address; type yang:mac-address;
description description
"MAC Address"; "MAC Address";
skipping to change at page 32, line 29 skipping to change at page 33, line 46
"List of test point locations."; "List of test point locations.";
} }
description description
"Serves as top-level container "Serves as top-level container
for test point location list."; for test point location list.";
} }
description description
"mac address location type container."; "mac address location type container.";
} }
container group-as-number-location-type { container group-as-number-location-type {
when "derived-from-or-self(../tp-location-type, 'cl-oam:as-number-address-type')" { when "derived-from-or-self(../tp-location-type,"+
"'cl-oam:as-number-address-type')" {
description description
"when test point location type is equal to as-number."; "when test point location type is equal to as-number.";
} }
container test-point-as-number-location-list { container test-point-as-number-location-list {
list test-point-locations { list test-point-locations {
key "as-number-location"; key "as-number-location";
leaf as-number-location { leaf as-number-location {
type inet:as-number; type inet:as-number;
description description
"AS number for point to multi point OAM."; "AS number for point to multi point OAM.";
} }
leaf ni { leaf ni {
type routing-instance-ref; type routing-instance-ref;
skipping to change at page 33, line 12 skipping to change at page 34, line 30
"List of test point locations."; "List of test point locations.";
} }
description description
"Serves as top-level container "Serves as top-level container
for test point location list."; for test point location list.";
} }
description description
"as number location type container."; "as number location type container.";
} }
container group-system-id-location-type { container group-system-id-location-type {
when "derived-from-or-self(../tp-location-type, 'cl-oam:system-id-address-type')" { when "derived-from-or-self(../tp-location-type,"+
"'cl-oam:system-id-address-type')" {
description description
"when test point location type is equal to system-info."; "when test point location type is equal to system-info.";
} }
container test-point-system-info-location-list { container test-point-system-info-location-list {
list test-point-locations { list test-point-locations {
key "system-id-location"; key "system-id-location";
leaf system-id-location { leaf system-id-location {
type inet:uri; type inet:uri;
description description
"System Id."; "System Id.";
skipping to change at page 34, line 10 skipping to change at page 35, line 30
grouping timestamp { grouping timestamp {
description description
"Grouping for timestamp."; "Grouping for timestamp.";
leaf timestamp-type { leaf timestamp-type {
type identityref { type identityref {
base timestamp-type; base timestamp-type;
} }
description description
"Type of Timestamp, such as Truncated PTP, NTP."; "Type of Timestamp, such as Truncated PTP, NTP.";
} }
container timestamp-64bit { container timestamp-64bit {
when "derived-from-or-self(../timestamp-type, 'cl-oam:truncated-ptp')"+ when "derived-from-or-self(../timestamp-type, 'cl-oam:truncated-ptp')"+
"or derived-from-or-self(../timestamp-type,'cl-oam:ntp64')" { "or derived-from-or-self(../timestamp-type,'cl-oam:ntp64')" {
description description
"Only applies when Truncated NTP or 64bit NTP Timestamp."; "Only applies when Truncated NTP or 64bit NTP Timestamp.";
} }
leaf timestamp-sec { leaf timestamp-sec {
type uint32; type uint32;
description description
"Absolute timestamp in seconds as per IEEE1588v2 "Absolute timestamp in seconds as per IEEE1588v2
or seconds part in 64-bit NTP timestamp."; or seconds part in 64-bit NTP timestamp.";
} }
leaf timestamp-nanosec { leaf timestamp-nanosec {
type uint32; type uint32;
description description
"Fractional part in nanoseconds as per IEEE1588v2 "Fractional part in nanoseconds as per IEEE1588v2
or Fractional part in 64-bit NTP timestamp."; or Fractional part in 64-bit NTP timestamp.";
} }
description description
"Container for 64bit timestamp."; "Container for 64bit timestamp.";
} }
container timestamp-80bit { container timestamp-80bit {
when "derived-from-or-self(../timestamp-type, 'cl-oam:ptp80')"{ when "derived-from-or-self(../timestamp-type, 'cl-oam:ptp80')"{
description description
"Only applies when 80bit PTP Timestamp."; "Only applies when 80bit PTP Timestamp.";
} }
if-feature ptp-long-format; if-feature ptp-long-format;
leaf timestamp-sec { leaf timestamp-sec {
type uint64 { type uint64 {
range "0..281474976710656"; range "0..281474976710656";
} }
description description
skipping to change at page 35, line 6 skipping to change at page 36, line 25
} }
leaf timestamp-nanosec { leaf timestamp-nanosec {
type uint32; type uint32;
description description
"Fractional part in nanoseconds as per IEEE1588v2 "Fractional part in nanoseconds as per IEEE1588v2
or Fractional part in 64-bit NTP timestamp."; or Fractional part in 64-bit NTP timestamp.";
} }
description description
"Container for 64bit timestamp."; "Container for 64bit timestamp.";
} }
container ntp-timestamp-32bit { container ntp-timestamp-32bit {
when "derived-from-or-self(../timestamp-type, 'cl-oam:truncated-ntp')"{ when "derived-from-or-self(../timestamp-type, 'cl-oam:truncated-ntp')"{
description description
"Only applies when 32 bit NTP Short format Timestamp."; "Only applies when 32 bit NTP Short format Timestamp.";
} }
if-feature ntp-short-format; if-feature ntp-short-format;
leaf timestamp-sec { leaf timestamp-sec {
type uint16; type uint16;
description description
"Timestamp in seconds as per short format NTP."; "Timestamp in seconds as per short format NTP.";
} }
leaf timestamp-nanosec { leaf timestamp-nanosec {
type uint16; type uint16;
description description
"Truncated Fractional part in 16-bit NTP timestamp."; "Truncated Fractional part in 16-bit NTP timestamp.";
} }
description description
"Container for 64bit timestamp."; "Container for 64bit timestamp.";
} }
container icmp-timestamp-32bit { container icmp-timestamp-32bit {
when "derived-from-or-self(../timestamp-type, 'cl-oam:icmp-ntp')"{ when "derived-from-or-self(../timestamp-type, 'cl-oam:icmp-ntp')"{
description description
"Only applies when Truncated NTP or 64bit NTP Timestamp."; "Only applies when Truncated NTP or 64bit NTP Timestamp.";
} }
if-feature icmp-timestamp; if-feature icmp-timestamp;
leaf timestamp-millisec { leaf timestamp-millisec {
type uint32; type uint32;
description description
"timestamp in milliseconds for ICMP timestamp."; "timestamp in milliseconds for ICMP timestamp.";
} }
description description
"Container for 32bit timestamp."; "Container for 32bit timestamp.";
} }
skipping to change at page 39, line 4 skipping to change at page 40, line 24
uses cc-session-statistics; uses cc-session-statistics;
} }
container cc-ipv6-sessions-statistics { container cc-ipv6-sessions-statistics {
description description
"CC ipv6 sessions"; "CC ipv6 sessions";
uses cc-session-statistics; uses cc-session-statistics;
} }
} }
} }
<CODE ENDS> <CODE ENDS>
5. Connectionless model applicability 5. Connectionless model applicability
"ietf-connectionless-oam" model defined in this document provides The "ietf-connectionless-oam" model defined in this document provides
technology-independent abstraction of key OAM constructs for a technology-independent abstraction of key OAM constructs for
connectionless protocols. This model can be further extended to connectionless protocols. This model can be further extended to
include technology specific details, e.g., adding new data nodes with include technology specific details, e.g., adding new data nodes with
technology specific functions and parameters into proper anchor technology specific functions and parameters into proper anchor
points of the base model, so as to develop a technology-specific points of the base model, so as to develop a technology-specific
connectionless OAM model. connectionless OAM model.
This section demonstrates the usability of the connectionless YANG This section demonstrates the usability of the connectionless YANG
OAM data model to various connectionless OAM technologies, e.g., BFD, OAM data model to various connectionless OAM technologies, e.g., BFD,
LSP ping. Note that, in this section, we only present several LSP ping. Note that, in this section, several snippets of
snippets of technology-specific model extensions for illustrative technology-specific model extensions are presented for illustrative
purposes. The complete model extensions should be worked on in purposes. The complete model extensions should be worked on in
respective protocol working groups. respective protocol working groups.
5.1. BFD Extension 5.1. BFD Extension
RFC 7276 defines BFD as a connection-oriented protocol. It is used
to monitor a connectionless protocol in the case of basic BFD for IP.
5.1.1. Augment Method 5.1.1. Augment Method
The following sections shows how the "ietf-connectionless-oam" model The following sections shows how the "ietf-connectionless-oam" model
can be extended to cover BFD technology. For this purpose, a set of can be extended to cover BFD technology. For this purpose, a set of
extension are introduced such as technology-type extension and test- extension are introduced such as technology-type extension and test-
point attributes extension. point attributes extension.
Note that in BFD WG, there is a BFD YANG data model Note that a dedicated BFD YANG data model [I-D.ietf-bfd-yang] is also
[I-D.ietf-bfd-yang] to be produced. Users can choose to use "ietf- standardized. Augmentation of the "ietf-connectionless-oam" model
connectioless-oam" as basis and augment the "ietf-connectionless-oam" with BFD specific details provides an alternative approach that
model with bfd specific details. The bfd specific details can be the provides a unified view of management information across various OAM
grouping defined in the BFD model. protocols. The BFD specific details can be the grouping defined in
the BFD model avoiding duplication of effort.
5.1.1.1. Technology type extension 5.1.1.1. Technology type extension
No BFD technology type has been defined in the "ietf-connectionless- No BFD technology type has been defined in the "ietf-connectionless-
oam" model. Therefore a technology type extension is required in the oam" model. Therefore a technology type extension is required in the
model Extension. model Extension.
The snippet below depicts an example of augmenting "bfd" type into The snippet below depicts an example of adding the "bfd" type as an
the ietf-connectionless-oam": augment to the ietf-connectionless-oam" model:
augment "/nd:networks/nd:network/nd:node/" augment "/nd:networks/nd:network/nd:node/"
+"coam:location-type/coam:ipv4-location-type" +"coam:location-type/coam:ipv4-location-type"
+"/coam:test-point-ipv4-location-list/" +"/coam:test-point-ipv4-location-list/"
+"coam:test-point-locations/coam:technology" +"coam:test-point-locations/coam:technology"
{ {
leaf bfd{ leaf bfd{
type string; type string;
} }
} }
5.1.1.2. Test point attributes extension 5.1.1.2. Test point attributes extension
To support bfd technology, the "ietf-connectionless-oam" model can be To support BFD technology, the "ietf-connectionless-oam" model can be
extended and add bfd specific parameters under "test-point-locations" extended by adding specific parameters into the "test-point-
list and/or add new location type such as "bfd over MPLS-TE" under locations" list and/or adding a new location type such as "BFD over
"location-type". MPLS TE" under "location-type".
5.1.1.2.1. Define and insert new nodes into corresponding test-point- 5.1.1.2.1. Define and insert new nodes into corresponding test-point-
location location
In the "ietf-connectionless-oam" model, multiple "test-point- In the "ietf-connectionless-oam" model, multiple "test-point-
location" lists are defined under the "location-type" choice node. location" lists are defined under the "location-type" choice node.
Therefore, to derive a model for some bfd technologies ( such as ip Therefore, to derive a model for some BFD technologies ( such as ip
single-hop, ip multi-hops, etc), data nodes for bfd specific details single-hop, ip multi-hops, etc), data nodes for BFD specific details
need to be added into corresponding "test-point-locations" list. In need to be added into corresponding "test-point-locations" list. In
this section, we reuse some groupings which are defined in this section, some groupings which are defined in [I-D.ietf-bfd-yang]
[I-D.ietf-bfd-yang] as following: are reused as follow:
The snippet below shows how the "ietf-connectionless-oam" model can The snippet below shows how the "ietf-connectionless-oam" model can
be extended to support "BFD IP single-hop": be extended to support "BFD IP single-hop":
augment "/nd:networks/nd:network/nd:node/" augment "/nd:networks/nd:network/nd:node/"
+"coam:location-type/coam:ipv4-location-type" +"coam:location-type/coam:ipv4-location-type"
+"/coam:test-point-ipv4-location-list/" +"/coam:test-point-ipv4-location-list/"
+"coam:test-point-locations" +"coam:test-point-locations"
{ {
container session-cfg { container session-cfg {
skipping to change at page 41, line 41 skipping to change at page 42, line 46
technologies such as BFD IP multi-hop, BFD over MPLS, etc. technologies such as BFD IP multi-hop, BFD over MPLS, etc.
5.1.1.2.2. Add new location-type cases 5.1.1.2.2. Add new location-type cases
In the "ietf-connectionless-oam" model, If there is no appropriate In the "ietf-connectionless-oam" model, If there is no appropriate
"location type" case that can be extended, a new "location-type" case "location type" case that can be extended, a new "location-type" case
can be defined and inserted into the "location-type" choice node. can be defined and inserted into the "location-type" choice node.
Therefore, the model user can flexibly add "location-type" to support Therefore, the model user can flexibly add "location-type" to support
other type of test point which are not defined in the "ietf- other type of test point which are not defined in the "ietf-
connectionless-oam" model. In this section, we add a new "location- connectionless-oam" model. In this section, a new "location-type"
type" case and reuse some groupings which are defined in case is added and some groupings that are defined in
[I-D.ietf-bfd-yang] as follows: [I-D.ietf-bfd-yang] are reused as follows:
The snippet below shows how the "ietf-connectionless-oam" model can The snippet below shows how the "ietf-connectionless-oam" model can
be extended to support "BFD over MPLS-TE": be extended to support "BFD over MPLS-TE":
augment "/nd:networks/nd:network/nd:node/coam:location-type"{ augment "/nd:networks/nd:network/nd:node/coam:location-type"{
case te-location{ case te-location{
list test-point-location-list{ list test-point-location-list{
key "tunnel-name"; key "tunnel-name";
leaf tunnel-name{ leaf tunnel-name{
type leafref{ type leafref{
skipping to change at page 42, line 27 skipping to change at page 43, line 27
uses bfd-mpls:bfd-encap-cfg; uses bfd-mpls:bfd-encap-cfg;
} }
} }
} }
Similar augmentations can be defined to support other BFD Similar augmentations can be defined to support other BFD
technologies such as BFD over LAG, etc. technologies such as BFD over LAG, etc.
5.1.2. Schema Mount 5.1.2. Schema Mount
And another alternative method is using schema mount mechanism Another alternative method is using the schema mount mechanism [I-
[I-D.ietf-netmod-schema-mount] in the "ietf-connectionless-oam". D.ietf-netmod-schema-mount] in the "ietf-connectionless-oam" model.
Within the "test-point-locations" list, a "root" attribute is defined Within the "test-point-locations" list, a "root" attribute is defined
to provide a mounted point for models mounted per "test-point- to provide a mount point for models mounted per "test-point-
locations". Therefore, the "ietf-connectionless-oam" model can locations". Therefore, the "ietf-connectionless-oam" model can
provide a place in the node hierarchy where other OAM YANG data provide a place in the node hierarchy where other OAM YANG data
models can be attached, without any special extension in the "ietf- models can be attached, without any special extension in the "ietf-
connectionless-oam" YANG data models [I-D.ietf-netmod-schema-mount]. connectionless-oam" YANG data models [I-D.ietf-netmod-schema-mount].
Note that the limitation of the Schema Mount method is it is not Note that the limitation of the Schema Mount method is it is not
allowed to specify certain modules that are required to be mounted allowed to specify certain modules that are required to be mounted
under a mount point. under a mount point.
The snippet below depicts the definition of "root" attribute. The snippet below depicts the definition of the "root" attribute.
anydata root { anydata root {
yangmnt:mount-point root; yangmnt:mount-point root;
description description
"Root for models supported per "Root for models supported per
test point"; test point";
} }
The following section shows how the "ietf-connectionless-oam" model The following section shows how the "ietf-connectionless-oam" model
can use schema mount to support BFD technology. can use schema mount to support BFD technology.
skipping to change at page 44, line 34 skipping to change at page 45, line 34
</root> </root>
</test-point-locations> </test-point-locations>
</ietf-connectionless-oam> </ietf-connectionless-oam>
5.2. LSP ping extension 5.2. LSP ping extension
5.2.1. Augment Method 5.2.1. Augment Method
The following sections shows how the "ietf-connectionless-oam" model The following sections shows how the "ietf-connectionless-oam" model
can be extended to support LSP ping technology. For this purpose, a can be extended to support LSP ping technology. For this purpose, a
set of extension are introduced such as technology-type extension and set of extensions are introduced such as the "technology-type"
test-point attributes extension. extension and the test-point "attributes" extension.
Note that in MPLS WG, there is a LSP Ping YANG data model Note that a LSP Ping YANG data model
[I-D.zheng-mpls-lsp-ping-yang-cfg] to be produced. Users can choose [I-D.zheng-mpls-lsp-ping-yang-cfg] has been standardized. As with
to use "ietf-connectioless-oam" as basis and augment the "ietf- BFD, users can choose to use the "ietf-connectioless-oam" as basis
connectionless-oam" model with LSP Ping specific details in the model and augment the "ietf- connectionless-oam" model with LSP Ping
extension. The LSP Ping specific details can be the grouping defined specific details in the model extension to provide a unified view
in the LSP ping model. across different technologies. The LSP Ping specific details can be
the grouping defined in the LSP ping model to avoid duplication of
effort.
5.2.1.1. Technology type extension 5.2.1.1. Technology type extension
No lsp-ping technology type has been defined in the "ietf- No lsp-ping technology type has been defined in the "ietf-
connectionless-oam" model. Therefore a technology type extension is connectionless-oam" model. Therefore a technology type extension is
required in the model extension. required in the model extension.
The snippet below depicts an example of augmenting the "ietf- The snippet below depicts an example of augmenting the "ietf-
connectionless-oam" with "lsp-ping" type: connectionless-oam" with "lsp-ping" type:
skipping to change at page 49, line 21 skipping to change at page 50, line 21
Following the format in [RFC3688] the following registration is Following the format in [RFC3688] the following registration is
requested to be made: requested to be made:
URI: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam URI: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the YANG Module Names This document registers a YANG module in the YANG Module Names
registry [RFC6020]. registry [RFC7950].
name: ietf-connectionless-oam name: ietf-connectionless-oam
namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam
prefix: cl-oam prefix: cl-oam
reference: RFC XXXX reference: RFC XXXX
8. Acknowlegements 8. Acknowlegements
skipping to change at page 50, line 10 skipping to change at page 51, line 10
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
the Network Configuration Protocol (NETCONF)", RFC 6020, "Network Time Protocol Version 4: Protocol and Algorithms
DOI 10.17487/RFC6020, October 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6021, DOI 10.17487/RFC6021, October 2010,
<https://www.rfc-editor.org/info/rfc6021>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
skipping to change at page 50, line 40 skipping to change at page 51, line 44
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<https://www.rfc-editor.org/info/rfc7223>. <https://www.rfc-editor.org/info/rfc7223>.
[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981. September 1981.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
9.2. Informative References 9.2. Informative References
[G.800] "Unified functional architecture of transport networks", [G.800] "Unified functional architecture of transport networks",
ITU-T Recommendation G.800, 2016. ITU-T Recommendation G.800, 2016.
[G.8013] "OAM functions and mechanisms for Ethernet based [G.8013] "OAM functions and mechanisms for Ethernet based
skipping to change at page 51, line 29 skipping to change at page 52, line 37
for Connection Oriented Operations, Administration, and for Connection Oriented Operations, Administration, and
Maintenance(OAM) protocols", draft-ietf-lime-yang- Maintenance(OAM) protocols", draft-ietf-lime-yang-
connection-oriented-oam-model-00 (work in progress), June connection-oriented-oam-model-00 (work in progress), June
2017. 2017.
[I-D.ietf-lime-yang-connectionless-oam-methods] [I-D.ietf-lime-yang-connectionless-oam-methods]
Kumar, D., Wang, Z., Wu, Q., Rahman, R., and S. Raghavan, Kumar, D., Wang, Z., Wu, Q., Rahman, R., and S. Raghavan,
"Retrieval Methods YANG Data Model for Connectionless "Retrieval Methods YANG Data Model for Connectionless
Operations, Administration, and Maintenance(OAM) Operations, Administration, and Maintenance(OAM)
protocols", draft-ietf-lime-yang-connectionless-oam- protocols", draft-ietf-lime-yang-connectionless-oam-
methods-09 (work in progress), October 2017. methods-10 (work in progress), October 2017.
[I-D.ietf-netmod-schema-mount] [I-D.ietf-netmod-schema-mount]
Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft-
ietf-netmod-schema-mount-08 (work in progress), October ietf-netmod-schema-mount-08 (work in progress), October
2017. 2017.
[I-D.ietf-rtgwg-ni-model]
Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Network Instances", draft-ietf-rtgwg-ni-
model-04 (work in progress), September 2017.
[I-D.ietf-rtgwg-routing-types]
Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Routing Area Common YANG Data Types", draft-ietf-rtgwg-
routing-types-17 (work in progress), October 2017.
[I-D.ietf-spring-sr-yang] [I-D.ietf-spring-sr-yang]
Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG
Data Model for Segment Routing", draft-ietf-spring-sr- Data Model for Segment Routing", draft-ietf-spring-sr-
yang-07 (work in progress), July 2017. yang-07 (work in progress), July 2017.
[I-D.zheng-mpls-lsp-ping-yang-cfg] [I-D.zheng-mpls-lsp-ping-yang-cfg]
Zheng, L., Aldrin, S., Zheng, G., Mirsky, G., and R. Zheng, L., Aldrin, S., Zheng, G., Mirsky, G., and R.
Rahman, "Yang Data Model for LSP-PING", draft-zheng-mpls- Rahman, "Yang Data Model for LSP-PING", draft-zheng-mpls-
lsp-ping-yang-cfg-05 (work in progress), June 2017. lsp-ping-yang-cfg-05 (work in progress), June 2017.
[IEEE.1588]
"IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE IEEE Std 1588-2008, 2008.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>. 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual [RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual
Private Network (L2VPN) Operations, Administration, and Private Network (L2VPN) Operations, Administration, and
Maintenance (OAM) Requirements and Framework", RFC 6136, Maintenance (OAM) Requirements and Framework", RFC 6136,
DOI 10.17487/RFC6136, March 2011, DOI 10.17487/RFC6136, March 2011,
<https://www.rfc-editor.org/info/rfc6136>. <https://www.rfc-editor.org/info/rfc6136>.
 End of changes. 98 change blocks. 
218 lines changed or deleted 303 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/