< draft-ietf-lime-yang-connectionless-oam-00.txt   draft-ietf-lime-yang-connectionless-oam-01.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 15, 2017 Q. Wu Expires: April 23, 2017 Q. Wu
Huawei Huawei
R. Rahman R. Rahman
S. Raghavan S. Raghavan
Cisco Cisco
September 11, 2016 October 20, 2016
Generic YANG Data Model for Connection Less Operations, Administration, Generic YANG Data Model for Connection Less Operations, Administration,
and Maintenance(OAM) protocols and Maintenance(OAM) protocols
draft-ietf-lime-yang-connectionless-oam-00 draft-ietf-lime-yang-connectionless-oam-01
Abstract Abstract
This document presents a base YANG Data model for connectionless OAM This document presents a base YANG Data model for connectionless OAM
protocols. It provides a technology-independent abstraction of key protocols. It provides a technology-independent abstraction of key
OAM constructs for connectionless protocols. The Based model OAM constructs for connectionless protocols. The Based model
presented here can be extended to include technology specific presented here can be extended to include technology specific
details. This is leading to uniformity between OAM protocols and details. This is leading to uniformity between OAM protocols and
support nested OAM workflows (i.e., performing OAM functions at support nested OAM workflows (i.e., performing OAM functions at
different or same levels through a unified interface). different or same levels through a unified interface).
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 15, 2017. This Internet-Draft will expire on April 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
3.2. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. OAM-layers . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. OAM-layers . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Test Point Locations Information . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 7
3.7. Continuity Check Data . . . . . . . . . . . . . . . . . . 8 3.7. Continuity Check Data . . . . . . . . . . . . . . . . . . 8
3.8. RPC definitions . . . . . . . . . . . . . . . . . . . . . 8 3.8. RPC definitions . . . . . . . . . . . . . . . . . . . . . 8
3.9. Relation with other OAM YANG Model . . . . . . . . . . . 11 3.9. Relation with other OAM YANG Model . . . . . . . . . . . 11
3.10. OAM data hierarchy . . . . . . . . . . . . . . . . . . . 11 3.10. OAM data hierarchy . . . . . . . . . . . . . . . . . . . 11
4. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 28 4. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 59 5. CL model applicability . . . . . . . . . . . . . . . . . . . 59
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 5.1. BFD Extension . . . . . . . . . . . . . . . . . . . . . . 59
7. Normative References . . . . . . . . . . . . . . . . . . . . 59 5.1.1. technology type extension . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 5.1.2. test point attributes extension . . . . . . . . . . . 60
5.2. LSP ping extension . . . . . . . . . . . . . . . . . . . 62
5.2.1. technology type extension . . . . . . . . . . . . . . 62
5.2.2. test point attributes extension . . . . . . . . . . . 63
6. Security Considerations . . . . . . . . . . . . . . . . . . . 64
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64
8. Normative References . . . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
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 59, line 13 skipping to change at page 59, line 13
uses coam:path-discovery-data; uses coam:path-discovery-data;
} }
} }
} }
YANG module of OAM YANG module of OAM
<CODE ENDS> <CODE ENDS>
5. Security Considerations 5. CL model applicability
ietf-connectionless-oam model defined in this document provides
technology-independent abstraction of key OAM constructs for
connectionless protocols. This model can be further extended to
include technology specific details, e.g., adding new data nodes with
technology specific functions and parameters into proper anchor
points of the base model, so as to develop a technology-specific
connectionless OAM model.
This section demonstrates the usability of the connectionless YANG
OAM data model to various connectionless OAM technologies, e.g., BFD,
LSP ping. Note that, in this section, we only present several
snippets of technology-specific model extensions for illustrative
purposes. The complete model extensions should be worked on in
respective protocol working groups.
5.1. BFD Extension
The following sections shows how the "ietf-connectionless-oam" model
can be extended to cover BFD technology. For this purpose, a set of
extension are introduced such as technology-type extension and test-
point attributes extension.
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 both BFD
model and "ietf-connectioless-oam" as basis and augment the "ietf-
connectionless-oam" model with bfd specific details. The bfd
specific details can be the grouping defined in the BFD model.
5.1.1. technology type extension
No BFD technology type has been defined in the "ietf-connectionless-
oam" model. Therefore a technology type extension is required in the
LIME BFD model.
The snippet below depicts an example of augmenting "bfd" type into
the ietf-connectionless-oam":
augment "/nd:networks/nd:network/nd:node/"
+"coam:location-type/coam:ipv4-location-type"
+"/coam:test-point-ipv4-location-list/"
+"coam:test-point-locations/coam:technology"
+"/coam:technology-string"
{
leaf bfd{
type string;
}
}
5.1.2. test point attributes extension
To derive a model for bfd technology, the "ietf-connectionless-oam"
model can be extended. Some data nodes for bfd specific parameters
can be defined and inserted into the proper "test-point-location"
list. Or some new "location-type" cases can be added to support the
some bfd technologies such as "bfd over MPLS-TE", etc.
5.1.2.1. Define and insert new nodes into corresponding test-point-
location
In the "ietf-connectionless-oam" model, multiple "test-point-
location" lists are defined under the "location-type" choice node.
Therefore, to derive model for some bfd technologies( such as ip
single-hop, ip multi-hops, etc), data nodes for bfd specific details
can be defined and inserted into corresponding "test-point-locations"
list. In this section, we reuse some groupings which are defined in
[I-D.ietf-bfd-yang] to derive following example.
The snippet below shows how the "ietf-connectionless-oam" model can
be extended to "BFD IP single-hop":
augment "/nd:networks/nd:network/nd:node/"
+"coam:location-type/coam:ipv4-location-type"
+"/coam:test-point-ipv4-location-list/"
+"coam:test-point-locations"
{
container session-cfg {
description "BFD IP single-hop session configuration";
list sessions {
key "interface dest-addr";
description "List of IP single-hop sessions";
leaf interface {
type if:interface-ref;
description
"Interface on which the BFD session is running.";
}
leaf dest-addr {
type inet:ip-address;
description "IP address of the peer";
}
uses bfd:bfd-grouping-common-cfg-parms;
uses bfd:bfd-grouping-echo-cfg-parms;
}
}
}
Edit note: To prevent new attribute to be defined in the CL extension
model,[I-D.ietf-bfd-yang] should define the attributes that are used
by CL model as grouping, then CL extension model can reuse these
grouping. We will make accordingly change when these grouping are
available in the BFD model.
Similar augmentations can be defined to support other BFD
technologies such as BFD IP multi-hop, BFD over MPLS, etc.
5.1.2.2. Add new location-type cases
In the "ietf-connectionless-oam" model, If no a proper "test-point-
locations" can be extended, new "location-type" cases can be defined
and inserted into the "location-type" choice node.
Therefore, the model user can flexible add "location-type" to support
other kinds of test point which are not defined in the "ietf-
connectionless-oam" model. In this section, we add a new "location-
type" case and reuse some groupings which are defined in
[I-D.ietf-bfd-yang] to derive the following example.
The snippet below shows how the "ietf-connectionless-oam" model can
be extended to "BFD over MPLS-TE":
augment "/nd:networks/nd:network/nd:node/coam:location-type"{
case te-location{
list test-point-location-list{
key "tunnel-name";
leaf tunnel-name{
type leafref{
path "/te:te/te:tunnels/te:tunnel/te:name";
}
description
"point to a te instance.";
}
uses bfd:bfd-grouping-common-cfg-parms;
uses bfd-mpls:bfd-encap-cfg;
}
}
}
Similar augmentations can be defined to support other BFD
technologies such as BFD over LAG, etc.
5.2. LSP ping extension
The following sections shows how the "ietf-connectionless-oam" model
can be extended to cover LSP ping technology. For this purpose, a
set of extension are introduced such as technology-type extension and
test-point attributes extension.
Note that in MPLS WG, there is a LSP Ping yang data model
[I-D.draft-zheng-mpls-lsp-ping-yang-cfg] to be produced. Users can
choose to use both LSP Ping model and "ietf-connectioless-oam" as
basis and augment the "ietf-connectionless-oam" model with LSP Ping
specific details. The LSP Ping specific details can be the grouping
defined in the LSP ping model.
5.2.1. technology type extension
No lsp-ping technology type has been defined in the "ietf-
connectionless-oam" model. Therefore a technology type extension is
required in the LIME LSP ping model.
The snippet below depicts an example of augmenting "lsp-ping" type
into the "ietf-connectionless-oam":
augment "/nd:networks/nd:network/nd:node/"
+"coam:location-type/coam:ipv4-location-type"
+"/coam:test-point-ipv4-location-list/"
+"coam:test-point-locations/coam:technology"
+"/coam:technology-string"
{
leaf lsp-ping{
type string;
}
}
5.2.2. test point attributes extension
In order to derive a model for lsp-ping, the "ietf-connectionless-
oam" model can be extended. Some data nodes for lsp-ping specific
parameters can be defined and inserted into the proper "test-point-
location" list.
User can reuse the attributes or groupings which are defined in
[I-D.draft-zheng-mpls-lsp-ping-yang-cfg] to derive the "lime lsp
ping" model.
The snippet below depicts an example of augmenting lsp ping
attributes into the "test-point-locations" list:
augment "/nd:networks/nd:network/nd:node/"
+"coam:location-type/coam:ipv4-location-type"
+"/coam:test-point-ipv4-location-list/"
+"coam:test-point-locations"
{
list lsp-ping {
key "lsp-ping-name";
leaf lsp-ping-name {
type string {
length "1..31";
}
mandatory "true";
description "LSP Ping test name.";
......
}
Edit note: To prevent new attribute to be defined in the CL extension
model,[I-D.draft-zheng-mpls-lsp-ping-yang-cfg] should define the
attributes that are used by CL model as grouping, then CL extension
model can reuse these grouping. We will make accordingly change when
these grouping are available in the LSP ping model.
6. Security Considerations
TBD. TBD.
6. 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]
[RFC3688]. Following the format in RFC 3688, the following [RFC3688]. Following the format in RFC 3688, the following
registration is requested to be made: registration is 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 [RFC6020].
name: ietf-connectionless-oam namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam name: ietf-connectionless-oam namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam
prefix: goam reference: RFC XXXX prefix: goam reference: RFC XXXX
7. Normative References 8. Normative References
[I-D.draft-ietf-i2rs-yang-network-topo] [I-D.draft-ietf-i2rs-yang-network-topo]
Clemm, A., Medved, J., Tkacik, T., Varga, R., Bahadur, N., Clemm, A., Medved, J., Tkacik, T., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", I-D draft-ietf-i2rs-yang-network- Network Topologies", I-D draft-ietf-i2rs-yang-network-
topo-05, July 2016. topo-05, July 2016.
[I-D.draft-zheng-mpls-lsp-ping-yang-cfg]
Zheng, L., Aldrin, S., Zheng, G., Mirsky, G., and R.
Rahman, "Yang Data Model for LSP-PING", I-D draft-zheng-
mpls-lsp-ping-yang-cfg-03, March 2016.
[I-D.ietf-bfd-yang]
Zheng, L., Rahman, R., Networks, J., Jethanandani, M., and
G. Mirsky, "Yang Data Model for Bidirectional Forwarding
Detection (BFD)", draft-ietf-bfd-yang-03 (work in
progress), July 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
 End of changes. 9 change blocks. 
11 lines changed or deleted 241 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/