< draft-ietf-lime-yang-connectionless-oam-08.txt   draft-ietf-lime-yang-connectionless-oam-09.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: March 3, 2018 Q. Wu Expires: March 4, 2018 Q. Wu
Huawei Huawei
R. Rahman R. Rahman
S. Raghavan S. Raghavan
Cisco Cisco
August 30, 2017 August 31, 2017
Generic YANG Data Model for Connectionless Operations, Administration, Generic YANG Data Model for Connectionless Operations, Administration,
and Maintenance(OAM) protocols and Maintenance(OAM) protocols
draft-ietf-lime-yang-connectionless-oam-08 draft-ietf-lime-yang-connectionless-oam-09
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. It
provides a technology-independent abstraction of key OAM constructs provides a technology-independent abstraction of key OAM constructs
for connectionless protocols. The base model presented here can be for connectionless protocols. The base model presented here can be
extended to include technology specific details. This is leading to extended to include technology specific details. This is leading to
uniformity between OAM protocols and support both nested OAM uniformity between OAM protocols and support both nested OAM
workflows (i.e., performing OAM functions at different or same levels workflows (i.e., performing OAM functions at different or same levels
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 March 3, 2018. This Internet-Draft will expire on March 4, 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
(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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the Connectionless OAM Model . . . . . . . . . . 4 3. Overview of the Connectionless OAM Model . . . . . . . . . . 4
3.1. TP Address . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. TP Address . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. OAM neighboring layers . . . . . . . . . . . . . . . . . 5 3.3. OAM neighboring layers . . . . . . . . . . . . . . . . . 6
3.4. Test Point Locations Information . . . . . . . . . . . . 6 3.4. Test Point Locations Information . . . . . . . . . . . . 7
3.5. Test Point Locations . . . . . . . . . . . . . . . . . . 7 3.5. Test Point Locations . . . . . . . . . . . . . . . . . . 7
3.6. Path Discovery Data . . . . . . . . . . . . . . . . . . . 7 3.6. Path Discovery Data . . . . . . . . . . . . . . . . . . . 8
3.7. Continuity Check Data . . . . . . . . . . . . . . . . . . 7 3.7. Continuity Check Data . . . . . . . . . . . . . . . . . . 8
4. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 3.8. OAM data hierarchy . . . . . . . . . . . . . . . . . . . 8
5. Connectionless model applicability . . . . . . . . . . . . . 31 4. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. BFD Extension . . . . . . . . . . . . . . . . . . . . . . 31 5. Connectionless model applicability . . . . . . . . . . . . . 35
5.1.1. Augment Method . . . . . . . . . . . . . . . . . . . 31 5.1. BFD Extension . . . . . . . . . . . . . . . . . . . . . . 36
5.1.2. Schema Mount . . . . . . . . . . . . . . . . . . . . 34 5.1.1. Augment Method . . . . . . . . . . . . . . . . . . . 36
5.2. LSP ping extension . . . . . . . . . . . . . . . . . . . 36 5.1.2. Schema Mount . . . . . . . . . . . . . . . . . . . . 38
5.2.1. Augment Method . . . . . . . . . . . . . . . . . . . 36 5.2. LSP ping extension . . . . . . . . . . . . . . . . . . . 40
5.2.2. Schema Mount . . . . . . . . . . . . . . . . . . . . 37 5.2.1. Augment Method . . . . . . . . . . . . . . . . . . . 40
6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 5.2.2. Schema Mount . . . . . . . . . . . . . . . . . . . . 41
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . . 43
8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 41 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 45
9.1. Normative References . . . . . . . . . . . . . . . . . . 41 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.2. Informative References . . . . . . . . . . . . . . . . . 42 9.1. Normative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 9.2. Informative References . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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 connections (Reachability Verification,
Continuity Check). Continuity Check).
2. Troubleshoot failures (Fault verification and localization). 2. Troubleshoot failures (Fault verification and localization).
skipping to change at page 4, line 15 skipping to change at page 4, line 15
[RFC6020]. [RFC6020].
2.1. Terminology 2.1. Terminology
TP - Test Point TP - Test Point
MAC - Media Access Control MAC - Media Access Control
BFD - Bidirectional Forwarding Detection BFD - Bidirectional Forwarding Detection
RPC - A Remote Procedure Call, as used within the NETCONF protocol RPC - A 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 that a destination is reachable and therefore also referred to verify that a destination is reachable and therefore also referred to
as reachability verification as 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" using
'test-point-locations' defined below. 'tp-tools' grouping defined in
this model supports both proactive and on-demand activation.
At the top of the model, there is an 'cc-oper-data' container for At the top of the model, there is an 'cc-oper-data' container for
session statistics. Grouping is also defined for common session session statistics. Grouping is also defined for common session
statistics and these are applicable for proactive OAM sessions. statistics and these are only applicable for proactive OAM sessions.
Multiple 'test-point-locations' keyed using technology specific keys Multiple 'test-point-locations' keyed using technology specific keys
(eg., IPv4 address for IPv4 locations) are possible by augmented (eg., IPv4 address for IPv4 locations) are augmented into network
network nodes which are defined in [I-D.ietf-i2rs-yang-network-topo] nodes which are defined in [I-D.ietf-i2rs-yang-network-topo] to
to describe the network hierarchies and the inventory of nodes describe the network hierarchies and the inventory of nodes contained
contained in a network. Each 'test-point-location' is chosen based in a network. Each test point location under 'test-point-locations
on 'location-type' which when chosen, leads to a container that 'grouping is chosen based on 'tp-location-type' leaf which when
includes a list of 'test-point-locations' keyed by technology chosen, leads to a container that includes a list of 'test-point-
specific keys. Each test point location includes a 'test-point- locations' keyed by technology specific keys(e.g.,
location-info'. The 'test-point-location-info' includes 'tp- 'ipv4-location'leaf). Each test point location under 'test-point-
technology', 'tp-tools', and 'connectionless-oam-layers'. The locations 'grouping includes a 'test-point-location-info' grouping.
groupings of 'tp-address' and 'tp-address-vrf' are kept out of 'test- The 'test-point-location-info' grouping includes 'tp-technology'
point-location-info' to make it addressing agnostic and allow varied grouping, 'tp-tools' grouping, and 'connectionless-oam-layers'
composition. Depending upon the choice of the 'location-type' grouping. The groupings of 'tp-address' and 'tp-address-ni' are kept
(determined by the 'tp-address-vrf'), the containers differ in its out of 'test-point-location-info' grouping to make it addressing
composition of 'test-point-locations' while the 'test-point-location- agnostic and allow varied composition. Depending upon the choice of
info', is a common aspect of every 'test-point-location'. The vrf is the 'tp-location-type' (determined by the 'tp-address-ni'), the
used to describe the corresponding network instance. The 'tp- containers differ in its composition of 'test- point-locations' while
technology' indicate OAM technology details. The 'tp-tools' describe the 'test-point-location-info', is a common aspect of every 'test-
the OAM tools supported. The 'connectionless-oam-layers' is used to point-location'. The 'tp-address-ni' grouping is used to describe
describe the relationship of one test point with other test points. the corresponding network instance. The 'tp-technology'grouping
The level in 'oam-layers' indicate whether related OAM test point is indicate OAM technology details. The 'tp-tools' grouping describe
The level in oam-layers indicate whether related oam test point is in the OAM tools supported. The 'connectionless-oam-layers' grouping is
client layer(lower layer described in section 3.3), server layer used to describe the relationship of one test point with other test
(upper layer described in section 3.3) or the same layer as the points. The 'technology-level' in 'oam-neighboring-layers'indicate
current test point under Test point Locations. The model is relative technology level of neighboring test point corresponding to
augmented to "/nd:networks/nd:network/nd:node" using 'test-point- the current test point.
locations' defined below.
3.1. TP Address 3.1. TP Address
In connectionless OAM, the tp address is defined with the following In connectionless OAM, the TP address is defined with the following
type: type:
o MAC address [RFC6136] o MAC address [RFC6136]
o IPv4 or IPv6 address o IPv4 or IPv6 address
o TP-attribute o TP-attribute
o System-id to represent the device or o System-id to represent the device or
node.[I-D.ietf-spring-sr-yang] node.[I-D.ietf-spring-sr-yang]
To define a forwarding treatment of a test packet, the 'tp-address' To define a forwarding treatment of a test packet, the 'tp-
needs to be associated with additional parameters, e.g. DSCP for IP address'grouping needs to be associated with additional parameters,
or TC for MPLS. In generic connectionless OAM YANG model, these e.g. DSCP for IP or EXP for MPLS. In generic connectionless OAM
parameters are not explicit configured. The model user can add YANG model, these parameters are not explicit configured. The model
corresponding parameters according to their requirements. user can add corresponding 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
configuration. The on-demand OAM refers to OAM actions which are configuration. The on-demand OAM refers to OAM actions which are
initiated via manual intervention for a limited time to carry out initiated via manual intervention for a limited time to carry out
diagnostics. The on-demand OAM method requires only transient diagnostics. The on-demand OAM method requires only transient
configuration.[RFC7276] [G.8013]. In connectionless OAM, 'session- configuration.[RFC7276] [G.8013]. In connectionless OAM, 'session-
type' is defined to indicate which kind of activation will be used by type' grouping is defined to indicate which kind of activation will
the current session. be used by the current session.
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" should be set to "true", and then the lime "../coam:continuity-check" leaf should be set to "true", and then the
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 layers 3.3. OAM neighboring layers
As typical networks have a multi-layer architecture, the set of OAM As typical networks have a multi-layer architecture, the set of OAM
protocols similarly take a multi-layer structure; each layer may has protocols similarly take a multi-layer structure; each layer may has
its own OAM protocol [RFC7276] and is corresponding to specific its own OAM protocol [RFC7276] and is corresponding to specific
administrative domain and has associated test points. OAM- - administrative domain and has associated test points. OAM-
neighboring-layers is referred to a list of neighboring test points neighboring-layers is referred to a list of neighboring test points
in the upstream layer and/or downstream layer that are related to in the upstream layer and/or downstream layer and the same layer that
current test point. This allows users to easily navigate between are related to current test point. This allows users to easily
related neighboring layer to efficiently troubleshoot a defect. In navigate between related neighboring layer to efficiently
this model, we have kept level default as 0, when a list of troubleshoot a defect. In this model, we have kept level default as
neighboring test points under oam-neighboring-layer are located at 0, when a list of neighboring test points under 'oam-neighboring-
the same layer as the current test point. 'Technology-Level' defines layers' list are located at the same layer as the current test point.
the relative technology level of neighboring test point corresponding 'Technology-Level'leaf defines the relative technology level of
to the current test point in multi-layer and multi-technology neighboring test point corresponding to the current test point in
networks , and is provided to allow correlation of faults at multi-layer and multi-technology networks , and is provided to allow
different administrative and technology layers . If there is one correlation of faults at different administrative and technology
neighboring test point at higher layer of the current test point, layers . If there is one neighboring test point at higher layer of
?Technology-level? is set to 1. If there is one neighboring test the current test point, 'Technology-level'leaf is set to 1. If there
point at lower layer of the current test point, ?Technology-level? is is one neighboring test point at lower layer of the current test
set to -1. point, 'Technology-level'leaf is set to -1.
list oam-neighboring-layers { list oam-neighboring-layers {
key "index"; key "index";
leaf index { leaf index {
type uint16 { type uint8 {
range "0..65535"; range "0..128";
} }
description description
?index?; "Index of a list of neighboring test points
in the upstream layer and/or downstream layer
and/or same layer ";
} }
leaf technology-level { leaf technology-level {
type int32 { type int8 {
range "-1..1"; range "-1..1";
} }
description description
"Level"; "The relative technology level
of neighboring test point
corresponding to the current
test point";
} }
description description
"List of related neighboring test points at upstream layer and or downstream layer or at the same layer."; "List of related neighboring test points at upstream layer
and or downstream layer or at the same layer.";
} }
3.4. Test Point Locations Information 3.4. Test Point Locations Information
This is a generic grouping for Test Point Locations Information. It This is a generic grouping for Test Point Locations Information
Provide details of Test Point Location using Tools, 'OAM-Layers' (i.e., test-point-location-info grouping). It Provide details of
grouping defined above. Test Point Location using 'tp-technology','tp-tool'grouping, 'OAM-
neighboring Layers' grouping defined above.
3.5. Test Point Locations 3.5. Test Point Locations
This is a generic grouping for Test Point Locations. Choice This is a generic grouping for Test Point Locations. 'tp-location-
statement 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 routing Test Point Location Information defined in section above, and network
instance VRF 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 RPCs. Path retrieved by any data retrieval methods including RPC operations.
discovery data output from methods, includes 'src-test-point', 'dst- Path discovery data output from methods, includes 'src-test-point'
test-point', 'sequence-number', 'hop-cnt', session statistics of container, 'dst- test-point' container, 'sequence-number'leaf, 'hop-
various kinds, path verification and path trace related information. cnt'leaf, session statistics of various kinds, path verification and
Path discovery includes data to be retrieved on a 'per-hop' basis via path trace related information. Path discovery includes data to be
a list of 'path-trace-info-list' which includes information like retrieved on a 'per- hop' basis via a list of 'path-trace-info-
'timestamps', 'ingress-interface', 'egress-interface' and 'app-meta- list'list which includes information like 'timestamp'grouping, '
data'. The path discovery data model is made generic enough to allow ingress-intf-name ', ' egress-intf-name ' and 'app-meta-data'. The
different methods of data retrieval. None of the fields are made path discovery data model is made generic enough to allow different
mandatory for that reason. Noted that the retrieval methods are methods of data retrieval. None of the fields are made mandatory for
defined in [I-D.ietf-lime-yang-connectionless-oam-methods]. that reason. Noted that the retrieval methods are defined in
[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
be retrieved by any data retrieval methods including RPCs. be retrieved by any data retrieval methods including RPC operations.
Continuity check data output from methods, includes 'src-test-point', Continuity check data output from methods, includes 'src-test-
'dst-test-point', 'sequence-number', 'hop-cnt' and session statistics point'container, 'dst-test-point'container, 'sequence-number' leaf,
of various kinds. The continuity check data model is made generic 'hop-cnt'leaf and session statistics of various kinds. The
enough to allow different methods of data retrieval. None of the continuity check data model is made generic enough to allow different
fields are made mandatory for that reason. Noted that the retrieval methods of data retrieval. None of the fields are made mandatory for
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.8. OAM data hierarchy
The complete data hierarchy related to the OAM YANG model is
presented below.
module: ietf-connectionless-oam
+--ro cc-session-statistics-data {continuity-check}?
+--ro cc-ipv4-sessions-statistics
| +--ro cc-session-statistics
| +--ro session-count? uint32
| +--ro session-up-count? uint32
| +--ro session-down-count? uint32
| +--ro session-admin-down-count? uint32
+--ro cc-ipv6-sessions-statistics
+--ro cc-session-statistics
+--ro session-count? uint32
+--ro session-up-count? uint32
+--ro session-down-count? uint32
+--ro session-admin-down-count? uint32
augment /nd:networks/nd:network/nd:node:
+--rw tp-location-type? identityref
+--rw location-type
+--rw ipv4-location-type
| +--rw test-point-ipv4-location-list
| +--rw test-point-locations* [ipv4-location ni]
| +--rw ipv4-location inet:ipv4-address
| +--rw ni routing-instance-ref
| +--rw (technology)?
| | +--:(technology-null)
| | +--rw tech-null? empty
| +--rw tp-tools
| | +--rw continuity-check boolean
| | +--rw path-discovery boolean
| +--rw root?
| +--rw oam-neighboring-layers* [index]
| +--rw index uint8
| +--rw level? int8
| +--rw (tp-location)?
| +--:(mac-address)
| | +--rw mac-address-location? yang:mac-address
| +--:(ipv4-address)
| | +--rw ipv4-address-location? inet:ipv4-address
| +--:(ipv6-address)
| | +--rw ipv6-address-location? inet:ipv6-address
| +--:(as-number)
| | +--rw as-number-location? inet:as-number
| +--:(system-id)
| +--rw system-id-location? router-id
+--rw ipv6-location-type
| +--rw test-point-ipv6-location-list
| +--rw test-point-locations* [ipv6-location ni]
| +--rw ipv6-location inet:ipv6-address
| +--rw ni routing-instance-ref
| +--rw (technology)?
| | +--:(technology-null)
| | +--rw tech-null? empty
| +--rw tp-tools
| | +--rw continuity-check boolean
| | +--rw path-discovery boolean
| +--rw root?
| +--rw oam-neighboring-layers* [index]
| +--rw index uint8
| +--rw level? int8
| +--rw (tp-location)?
| +--:(mac-address)
| | +--rw mac-address-location? yang:mac-address
| +--:(ipv4-address)
| | +--rw ipv4-address-location? inet:ipv4-address
| +--:(ipv6-address)
| | +--rw ipv6-address-location? inet:ipv6-address
| +--:(as-number)
| | +--rw as-number-location? inet:as-number
| +--:(system-id)
| +--rw system-id-location? router-id
+--rw mac-location-type
| +--rw test-point-mac-address-location-list
| +--rw test-point-locations* [mac-address-location]
| +--rw mac-address-location yang:mac-address
| +--rw (technology)?
| | +--:(technology-null)
| | +--rw tech-null? empty
| +--rw tp-tools
| | +--rw continuity-check boolean
| | +--rw path-discovery boolean
| +--rw root?
| +--rw oam-neighboring-layers* [index]
| +--rw index uint8
| +--rw level? int8
| +--rw (tp-location)?
| +--:(mac-address)
| | +--rw mac-address-location? yang:mac-address
| +--:(ipv4-address)
| | +--rw ipv4-address-location? inet:ipv4-address
| +--:(ipv6-address)
| | +--rw ipv6-address-location? inet:ipv6-address
| +--:(as-number)
| | +--rw as-number-location? inet:as-number
| +--:(system-id)
| +--rw system-id-location? router-id
+--rw group-as-number-location-type
| +--rw test-point-as-number-location-list
| +--rw test-point-locations* [as-number-location]
| +--rw as-number-location inet:as-number
| +--rw ni? routing-instance-ref
| +--rw (technology)?
| | +--:(technology-null)
| | +--rw tech-null? empty
| +--rw tp-tools
| | +--rw continuity-check boolean
| | +--rw path-discovery boolean
| +--rw root?
| +--rw oam-neighboring-layers* [index]
| +--rw index uint8
| +--rw level? int8
| +--rw (tp-location)?
| +--:(mac-address)
| | +--rw mac-address-location? yang:mac-address
| +--:(ipv4-address)
| | +--rw ipv4-address-location? inet:ipv4-address
| +--:(ipv6-address)
| | +--rw ipv6-address-location? inet:ipv6-address
| +--:(as-number)
| | +--rw as-number-location? inet:as-number
| +--:(system-id)
| +--rw system-id-location? router-id
+--rw group-system-id-location-type
+--rw test-point-system-info-location-list
+--rw test-point-locations* [system-id-location]
+--rw system-id-location inet:uri
+--rw ni? routing-instance-ref
+--rw (technology)?
| +--:(technology-null)
| +--rw tech-null? empty
+--rw tp-tools
| +--rw continuity-check boolean
| +--rw path-discovery boolean
+--rw root?
+--rw oam-neighboring-layers* [index]
+--rw index uint8
+--rw level? int8
+--rw (tp-location)?
+--:(mac-address)
| +--rw mac-address-location? yang:mac-address
+--:(ipv4-address)
| +--rw ipv4-address-location? inet:ipv4-address
+--:(ipv6-address)
| +--rw ipv6-address-location? inet:ipv6-address
+--:(as-number)
| +--rw as-number-location? inet:as-number
+--:(system-id)
+--rw system-id-location? router-id
4. OAM YANG Module 4. OAM YANG Module
<CODE BEGINS> file "ietf-connectionless-oam@2017-08-30.yang" <CODE BEGINS> file "ietf-connectionless-oam@2017-08-30.yang"
module ietf-connectionless-oam { module ietf-connectionless-oam {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-connectionless-oam"; namespace "urn:ietf:params:xml:ns:yang:ietf-connectionless-oam";
prefix coam; prefix coam;
import ietf-yang-schema-mount { import ietf-yang-schema-mount {
skipping to change at page 8, line 31 skipping to change at page 12, line 31
"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, statistics for connectionless OAM to be
used within IETF in a protocol indpendent manner, used within IETF in a protocol independent manner.
Also Functional level abstraction is independent with It is assumed that each protocol maps corresponding
YANG modeling. It is assumed that each protocol maps abstracts to its native format.Each protocol may
corresponding abstracts to its native format. extend the YANG model defined here to include protocol
Each protocol may extend the YANG model defined specific extensions";
here to include protocol specific extensions";
revision 2017-08-30 { revision 2017-08-30 {
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";
skipping to change at page 9, line 4 skipping to change at page 12, line 51
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 connection-less {
description description
"This feature indicates that OAM solution is connection less."; "This feature indicates that OAM solution is connection less.";
} }
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 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 model for path discovery command or rpc operation model for
path discovery command."; path discovery command.";
} }
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.";
} }
skipping to change at page 15, line 6 skipping to change at page 19, line 4
description description
"Grouping for per session path verification statistics"; "Grouping for per session path verification statistics";
container session-path-verification-statistics { container session-path-verification-statistics {
description description
"OAM per session path verification statistics."; "OAM per session path verification statistics.";
leaf verified-count { leaf verified-count {
type uint32; type uint32;
description description
"Total number of OAM packets that "Total number of OAM packets that
went through a path as intended."; went through a path as intended.";
} }
leaf failed-count { leaf failed-count {
type uint32; type uint32;
description description
"Total number of OAM packets that "Total number of OAM packets that
went through an unintended path."; went through an unintended path.";
} }
} }
} }
grouping session-type { grouping session-type {
description description
"This object indicates the current session "This object indicatesindicate which kind
definition."; of activation will be used by the current
session.";
leaf session-type { leaf session-type {
type enumeration { type enumeration {
enum "proactive" { enum "proactive" {
description description
"The current session is proactive"; "The current session is proactive session.";
} }
enum "on-demand" { enum "on-demand" {
description description
"The current session is on-demand."; "The current session is on-demand session.";
} }
} }
default "on-demand"; default "on-demand";
description description
"Session type enum"; "Indicate which kind of activation will be used
by the current session";
} }
} }
identity tp-address-technology-type { identity tp-address-technology-type {
description description
"Test point address type"; "Test point address type";
} }
identity mac-address-type { identity mac-address-type {
base tp-address-technology-type; base tp-address-technology-type;
skipping to change at page 16, line 48 skipping to change at page 20, line 48
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 address type."; "Test point address type.";
} }
container tp-address { container tp-address {
container mac-address { container mac-address {
when "derived-from-or-self(../tp-location-type, 'mac-address-type')" { when "derived-from-or-self('../tp-location-type', '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;
description description
"MAC Address"; "MAC Address";
} }
description description
"MAC Address based MP Addressing."; "MAC Address based MP Addressing.";
} }
container ipv4-address { container ipv4-address {
when "derived-from-or-self(../tp-location-type, 'ipv4-address-type')" { when "derived-from-or-self('../tp-location-type', '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;
description description
"IPv4 Address"; "IPv4 Address";
} }
description description
"IP Address based MP Addressing."; "IP Address based MP Addressing.";
} }
container ipv6-address { container ipv6-address {
when "derived-from-or-self(../tp-location-type, 'ipv6-address-type')" { when "derived-from-or-self('../tp-location-type', '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;
description description
"IPv6 Address"; "IPv6 Address";
} }
description description
"ipv6 Address based MP Addressing."; "ipv6 Address based MP Addressing.";
} }
container tp-attribute { container tp-attribute {
when "derived-from-or-self(../tp-location-type, 'tp-attribute-type')" { when "derived-from-or-self('../tp-location-type', '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 20, line 14 skipping to change at page 24, line 14
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, 'system-id-address-type')" { when "derived-from-or-self('../tp-location-type', 'system-id-address-type')" {
description description
"System id address type"; "System id address type";
} }
leaf system-id { leaf system-id {
type router-id; type router-id;
description description
"System ID assigned to this node."; "System ID assigned to this node.";
} }
description description
"system ID container."; "system ID container.";
skipping to change at page 20, line 39 skipping to change at page 24, line 39
description description
"TP Address"; "TP Address";
} }
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 the "The ni is used to describe virtual resource partitioning
corresponding network instance"; that may be present on a network device.Example of common
industry terms for virtual resource partitioning is VRF
instance.";
} }
uses tp-address; uses tp-address;
} }
grouping connectionless-oam-layers { grouping connectionless-oam-layers {
list oam-neighboring-layers { list oam-neighboring-layers {
key "index"; key "index";
leaf index { leaf index {
type uint16; type uint8{
range "0..128";}
description description
"Index"; "Index of a list of neighboring test points
in the upstream layer and/or downstream layer
and/or same layer";
} }
leaf level { leaf technology-level {
type int32 { type int8 {
range "-1..1"; range "-1..1";
} }
default "0"; default "0";
description description
"Level 0 indicates default level, "The relative technology level
of neighboring test point
corresponding to the current
test point.Level 0 indicates default level,
-1 means downstream layer related to current layer and +1 -1 means downstream layer related to current layer and +1
means upstream layer related to current layer. means upstream layer related to current layer.
In relationship 0 means same layer."; In relationship 0 means 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";
skipping to change at page 23, line 43 skipping to change at page 28, line 4
for the Internet Protocol Version 6 (IPv6) Specification. for the Internet Protocol Version 6 (IPv6) Specification.
RFC 4884: Extended ICMP to Support Multi-part Message. RFC 4884: Extended ICMP to Support Multi-part Message.
RFC 5837:Extending ICMP for Interface RFC 5837:Extending ICMP for Interface
and Next-Hop Identification. and Next-Hop Identification.
RFC 4379: LSP-PING."; RFC 4379: LSP-PING.";
} }
description description
"Container for test point OAM tools set."; "Container for test point OAM tools set.";
} }
} }
grouping test-point-location-info { grouping test-point-location-info {
uses tp-technology; uses tp-technology;
uses tp-tools; uses tp-tools;
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";
} }
uses connectionless-oam-layers; uses connectionless-oam-layers;
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 location-type { container location-type {
container ipv4-location-type { container ipv4-location-type {
when "derived-from-or-self(../tp-location-type, 'ipv4-address-type')" { when "derived-from-or-self('../tp-location-type', '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 25, line 4 skipping to change at page 29, line 12
"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, 'ipv6-address-type')" { when "derived-from-or-self('../tp-location-type', '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
"IPv6 Address."; "IPv6 Address.";
skipping to change at page 25, line 35 skipping to change at page 29, line 43
"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, 'mac-address-type')" { when "derived-from-or-self('../tp-location-type', '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 29, line 4 skipping to change at page 33, line 12
uses session-error-statistics; uses session-error-statistics;
uses session-delay-statistics; uses session-delay-statistics;
uses session-jitter-statistics; uses session-jitter-statistics;
container path-verification { container path-verification {
description description
"Optional path verification related information."; "Optional path verification related information.";
leaf flow-info { leaf flow-info {
type string; type string;
description description
"Informations that refers to the flow."; "Informations that refers to the flow.";
} }
uses session-path-verification-statistics; uses session-path-verification-statistics;
} }
container path-trace-info { container path-trace-info {
description description
"Optional path trace per-hop test point information. "Optional path trace per-hop test point information.
The list has typically a single element for per-hop The list has typically a single element for per-hop
cases like path-discovery RPC but allows a list of cases like path-discovery RPC operation but allows
hop related information for other types of a list of hop related information for other types of
data retrieval methods."; data retrieval methods.";
list path-trace-info-list { list path-trace-info-list {
key "index"; key "index";
description description
"Path trace information list."; "Path trace information list.";
leaf index { leaf index {
type uint32; type uint32;
description description
"Trace information index."; "Trace information index.";
} }
skipping to change at page 31, line 49 skipping to change at page 36, line 14
5.1. BFD Extension 5.1. BFD Extension
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 in BFD WG, there is a BFD YANG data model
[I-D.ietf-bfd-yang] to be produced. Users can choose to use "ietf- [I-D.ietf-bfd-yang] to be produced. Users can choose to use "ietf-
connectioless-oam" as basis and augment the "ietf-connectionless-oam" connectioless-oam" as basis and augment the "ietf-connectionless-oam"
model with bfd specific details. The bfd specific details can be the model with bfd specific details. The bfd specific details can be the
grouping defined in the BFD model. grouping defined in the BFD model.
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 augmenting "bfd" type into
the ietf-connectionless-oam": the ietf-connectionless-oam":
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"
+"/coam:technology-string"
{ {
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-location" extended and add bfd specific parameters under "test-point-location"
skipping to change at page 36, line 37 skipping to change at page 40, line 37
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 extension are introduced such as technology-type extension and
test-point attributes extension. test-point attributes extension.
Note that in MPLS WG, there is a LSP Ping yang data model Note that in MPLS WG, there is 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] to be produced. Users can choose
to use "ietf-connectioless-oam" as basis and augment the "ietf- to use "ietf-connectioless-oam" as basis and augment the "ietf-
connectionless-oam" model with LSP Ping specific details in the model connectionless-oam" model with LSP Ping specific details in the model
extension. The LSP Ping specific details can be the grouping defined extension. The LSP Ping specific details can be the grouping defined
in the LSP ping model. in the LSP ping model.
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:
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"
+"/coam:technology-string"
{ {
leaf lsp-ping{ leaf lsp-ping{
type string; type string;
} }
} }
5.2.1.2. Test point attributes extension 5.2.1.2. Test point attributes extension
To support lsp-ping, the "ietf-connectionless-oam" model can be To support lsp-ping, the "ietf-connectionless-oam" model can be
extended and add lsp-ping specific parameters can be defined and extended and add lsp-ping specific parameters can be defined and
skipping to change at page 39, line 24 skipping to change at page 43, line 24
foo foo
...... ......
</lsp-pings> </lsp-pings>
</ietf-lspping> </ietf-lspping>
</root> </root>
</test-point-locations> </test-point-locations>
</ietf-connectionless-oam> </ietf-connectionless-oam>
6. Security Considerations 6. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module defined in this document is designed to be accessed
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the via network management protocols such as NETCONF [RFC6241] or
secure transport layer and the mandatory-to-implement secure RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport
transport is SSH [RFC6242]. The NETCONF access control model layer, and the mandatory-to-implement secure transport is Secure
[RFC6536] provides the means to restrict access for particular Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the
NETCONF users to a pre-configured subset of all available NETCONF mandatory-to-implement secure transport is TLS [RFC5246].
protocol operations and content.
There are a number of data nodes defined in the YANG module which are The NETCONF access control model [RFC6536] provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g. <edit-config>) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. effect on network operations.
The vulnerable "config true" subtrees and data nodes are the The vulnerable "config true" subtrees and data nodes are the
following: following:
/nd:networks/nd:network/nd:node/coam:location-type/coam:ipv4- /nd:networks/nd:network/nd:node/coam:location-type/coam:ipv4-
location-type/coam:test-point-ipv4-location-list/coam:test-point- location-type/coam:test-point-ipv4-location-list/coam:test-point-
locations/ locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:ipv6-
location-type/coam:test-point-ipv6-location-list/coam:test-point-
locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:mac-location-
type/coam:test-point-mac-address-location-list/coam:test-point-
locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:tunnel-
location-type/coam:test-point-tunnel-address-location-list/coam:test-
point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:ip-prefix-
location-type/coam:test-point-ip-prefix-location-list/coam:test-
point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:route-
distinguisher-location-type/coam:test-point-route-dist-location-list/
coam:test-point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:group-ip-
address-location-type/coam:test-point-group-ip-address-location-list/
coam:test-point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:group-as- /nd:networks/nd:network/nd:node/coam:location-type/coam:ipv6-
number-location-type/coam:test-point-as-number-location-list/ location-type/coam:test-point-ipv6-location-list/coam:test-point-
coam:test-point-locations/ locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:mac-
location-type/coam:test-point-mac-address-location-list/coam:test-
point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:group-lsp-id- /nd:networks/nd:network/nd:node/coam:location-type/coam:group-as-
location-type/coam:test-point-lsp-id-location-list/coam:test-point- number-location-type/coam:test-point-as-number-location-list/
locations/ coam:test-point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:group-system- /nd:networks/nd:network/nd:node/coam:location-type/coam:group-
id-location-type/coam:test-point-system-info-location-list/coam:test- system-id-location-type/coam:test-point-system-info-location-list/
point-locations/ coam:test-point-locations/
Unauthorized access to any of these lists can adversely affect OAM Unauthorized access to any of these lists can adversely affect OAM
management system handling of end-to-end OAM and coordination of OAM management system handling of end-to-end OAM and coordination of OAM
within underlying network layers. This may lead to inconsistent within underlying network layers. This may lead to inconsistent
configuration, reporting, and presentation for the OAM mechanisms configuration, reporting, and presentation for the OAM mechanisms
used to manage the network. used to manage the network.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
/coam:cc-session-statistics-data/coam:cc-ipv4-sessions-statistics/
coam:cc-session-statistics/coam:session-count/
/coam:cc-session-statistics-data/coam:cc-ipv4-sessions-statistics/
coam:cc-session-statistics/coam:session-up-count/
/coam:cc-session-statistics-data/coam:cc-ipv4-sessions-statistics/
coam:cc-session-statistics/coam: session-down-count/
/coam:cc-session-statistics-data/coam:cc-ipv4-sessions-statistics/
coam:cc-session-statistics/coam:session-admin-down-count/
/coam:cc-session-statistics-data/coam:cc-ipv6-sessions-statistics/
coam:cc-session-statistics/coam:session-count/
/coam:cc-session-statistics-data/coam:cc-ipv6-sessions-statistics/
coam:cc-session-statistics/coam:session-up-count//
/coam:cc-session-statistics-data/coam:cc-ipv6-sessions-statistics/
coam:cc-session-statistics/coam:session-down-count/
/coam:cc-session-statistics-data/coam:cc-ipv6-sessions-statistics/
coam:cc-session-statistics/coam:session-admin-down-count/
7. IANA Considerations 7. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688]. This document registers a URI in the IETF XML registry [RFC3688].
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.
skipping to change at page 41, line 33 skipping to change at page 45, line 48
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
editor.org/info/rfc3688>. editor.org/info/rfc3688>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
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
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
editor.org/info/rfc5246>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, <https://www.rfc- DOI 10.17487/RFC6020, October 2010, <https://www.rfc-
editor.org/info/rfc6020>. editor.org/info/rfc6020>.
[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>.
skipping to change at page 42, line 16 skipping to change at page 46, line 35
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.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
9.2. Informative References 9.2. Informative References
[G.8013] "OAM functions and mechanisms for Ethernet based [G.8013] "OAM functions and mechanisms for Ethernet based
networks", ITU-T Recommendation G.8013/Y.1731, 2013. networks", ITU-T Recommendation G.8013/Y.1731, 2013.
[I-D.ietf-bfd-yang] [I-D.ietf-bfd-yang]
Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and
G. Mirsky, "YANG Data Model for Bidirectional Forwarding G. Mirsky, "YANG Data Model for Bidirectional Forwarding
Detection (BFD)", draft-ietf-bfd-yang-06 (work in Detection (BFD)", draft-ietf-bfd-yang-06 (work in
progress), June 2017. progress), June 2017.
skipping to change at page 44, line 4 skipping to change at page 48, line 22
Email: dekumar@cisco.com Email: dekumar@cisco.com
Michael Wang Michael Wang
Huawei Technologies,Co.,Ltd Huawei Technologies,Co.,Ltd
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing 210012 Nanjing 210012
China China
Email: wangzitao@huawei.com Email: wangzitao@huawei.com
Qin Wu Qin Wu
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
Reshad Rahman Reshad Rahman
CISCO Systems Cisco Systems
2000 Innovation Drive 2000 Innovation Drive
KANATA, ONTARIO K2K 3E8 Kanata, Ontario K2K 3E8
CANADA Canada
Email: rrahman@cisco.com Email: rrahman@cisco.com
Srihari Raghavan Srihari Raghavan
CISCO Systems Cisco Systems
TRIL INFOPARK SEZ, Ramanujan IT City Tril Infopark Sez, Ramanujan IT City
NEVILLE BLOCK, 2nd floor, Old Mahabalipuram Road Neville Block, 2nd floor, Old Mahabalipuram Road
CHENNAI, TAMIL NADU 600113 Chennai, Tamil Nadu 600113
INDIA India
Email: srihari@cisco.com Email: srihari@cisco.com
 End of changes. 72 change blocks. 
199 lines changed or deleted 394 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/