NVO3 Tissa Senevirathne Internet Draft Norman Finn Intended status: Standards Track Deepak Kumar Samer Salam Carlos Pignataro Cisco June 10, 2014 Expires: December 2014 YANG Data Model for NVO3 Operations, Administration, and Maintenance (OAM) draft-tissa-nvo3-yang-oam-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 10, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Senevirathne Expires December 10, 2014 [Page 1] Internet-Draft YANG Data Model for NVO3 OAM June 2014 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document presents the YANG Data model for NVO3 OAM. The YANG Model presented in this document extends the Generic YANG model for OAM with NVO3 technology specifics. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 2.1. Terminology...............................................3 3. Architecture of OAM YANG Model and Relationship to NVO3 OAM....3 4. NVO3 extensions to Generic YANG Model..........................4 4.1. MEP address...............................................5 4.2. Identity technology-sub-type..............................5 4.3. Flow-entropy..............................................5 4.4. Context-id................................................5 4.5. rpc definitions...........................................6 5. OAM Data Hierarchy.............................................6 6. OAM YANG module...............................................12 7. Base Mode for NVO3 OAM........................................20 8. Security Considerations.......................................20 9. IANA Considerations...........................................20 10. References...................................................21 10.1. Normative References....................................21 10.2. Informative References..................................21 11. Acknowledgments..............................................22 1. Introduction This document presents the YANG Data model for NVO3 OAM. The YANG Model presented in this document extends the Generic YANG model for OAM defined in [GENYANGOAM]. Fault Management for NVO3 is defined in [NV03OAMFM]. NVO3 Fault Management utilizes the [8021Q] CFM model and extends CFM with technology specifics. Those technology specific extensions are flow- Senevirathne Expires December 10, 2014 [Page 2] Internet-Draft YANG Data Model for NVO3 OAM June 2014 entropy for multipath support, MEP addressing beyond MAC addresses and so on. The extensions are explained in detail in [NVO3OAMFM]. In this document we extend the YANG model defined in [GENYANGOAM] to include NVO3 OAM. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 2.1. Terminology This document leverages the terminology defined in [GENYANGOAM]. 3. Architecture of OAM YANG Model and Relationship to NVO3 OAM Generic OAM YANG model acts as the basis for other OAM YANG models. This allows users to traverse between OAM tools of different technologies at ease through a uniform API set. This is also referred to as nested OAM workflow. The following Figure depicts the relationship of NVO3 OAM YANG model to the Generic YANG Model. Within NVO3 there are different overlay types such as VxLAN, NVGRE and so on. All of the NVO3 overlay variations inherit some set of NVO3 specific definitions such as VNI, VAP etc. To avoid repetition, OAM YANG model is designed such that technology sub-types can augment the technology specific YANG model. Senevirathne Expires December 10, 2014 [Page 3] Internet-Draft YANG Data Model for NVO3 OAM June 2014 +-+-+-+-+-+ | Gen | |OAM YANG | +-+-+-+-+-+ | O | +--------------------------------------------------+ | | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | TRILL | | NVO3 | . . .| foo | |OAM YANG | |OAM YANG | |OAM YANG | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | +-+-+-+-+-+-+-+-+-+ | | | | | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | | sub-tech| |sub-tech | |sub-tech | | | VxLAN | | NVGRE | |bar | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | | | | +----------------------------------------------------+ | Uniform API | +----------------------------------------------------+ Figure 1 Relationship of NVO3 OAM YANG model to generic YANG model 4. NVO3 extensions to Generic YANG Model The Technology parameter is defined in the [GENYANGOAM] as an identity. This allows easy extension of the YANG model by other technologies. Technology specific extensions are applied only when the technology is set to the specific type. "nvo3" is defined as an identity that augments the base technology-types identity. identity nvo3 { base goam:technology-types; description "nvo3 type"; } Figure 2 NVO3 identity type. Senevirathne Expires December 10, 2014 [Page 4] Internet-Draft YANG Data Model for NVO3 OAM June 2014 4.1. MEP address In NVO3, the MEP address is either the IPv4 or IPV6 address. In [GENYANGOAM] MEP address is defined as an IP address and same definition can be used for NVO3 with no further modification. 4.2. Identity technology-sub-type In NVO3, different overlay types such as VxLAN, NVGRE can be employed. "technology-sub-type" further identifies the overlay type within the NVO3. Technology sub-type is defined as an identity type. This allows different overlay types to augment NVO3 OAM YANG model to include overlay specific extensions without redefining common NVO3 definitions. augment "/goam:domains/goam:domain/goam:MAs/goam:MA" { leaf technology-sub-type { type identityref { base technology-sub-type; } } } 4.3. Flow-entropy In NVO3, flow-entropy depends on the sub technology such as VXLAN. Technology sub-type is used to extend the YANG model to specific usage. augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:flow- entropy" { case flow-entropy-vxlan { leaf flags-vxlan { type flags-vxlan; } leaf flow-entropy-vxlan { type flow-entropy-vxlan; } } } 4.4. Context-id In NVO3 context-id is 24 bit VNI. [GENYANGOAM] defines a placeholder for context-id. This allows other technologies to easily augment that Senevirathne Expires December 10, 2014 [Page 5] Internet-Draft YANG Data Model for NVO3 OAM June 2014 to include technology specific extensions. The snippet below depicts an example of augmenting context-id to include VNI. augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:context-id" { case context-id-nvo3 { leaf vni { type vni; } } } 4.5. rpc definitions The rpc model facilitates issuing commands to a NETCONF server (in this case to the device that need to execute the OAM command) and obtaining a response. Grouping statement command-ext-nvo3, defines the input extensions for nvo3. End-Station-Locator rpc command, defined in NVO3 YANG model, is NVO3 specific and allows locating an end-station within the NVO3 deployment. 5. OAM Data Hierarchy The complete data hierarchy related to the OAM YANG model is presented below. The following notations are used within the data tree and carry the meaning as below. Each node is printed as: is one of: + for current x for deprecated o for obsolete is one of: rw for configuration data Senevirathne Expires December 10, 2014 [Page 6] Internet-Draft YANG Data Model for NVO3 OAM June 2014 ro for non-configuration data -x for rpcs -n for notifications is the name of the node If the node is augmented into the tree from another module, its name is printed as :. is one of: ? for an optional leaf or choice ! for a presence container * for a leaf-list or list [] for a list's keys is the name of the type for leafs and leaf-lists Senevirathne Expires December 10, 2014 [Page 7] Internet-Draft YANG Data Model for NVO3 OAM June 2014 module: nvo3-oam augment /goam:domains/goam:domain/goam:MAs/goam:MA: +--rw technology-sub-type? identityref augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:context-id: +--:(context-id-nvo3) +--rw vni? vni augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:flow-entropy: +--:(flow-entropy-vxlan) +--rw flags-vxlan? flags-vxlan +--rw flow-entropy-vxlan? flow-entropy-vxlan augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:flow- entropy: +--:(flow-entropy-vxlan) +--rw flags-vxlan? flags-vxlan +--rw flow-entropy-vxlan? flow-entropy-vxlan augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:context-id: +--:(context-id-nvo3) +--rw vni? vni augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam :context-id: +--:(context-id-nvo3) +--rw vni? vni augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam :flow-entropy: +--:(flow-entropy-vxlan) +--rw flags-vxlan? flags-vxlan +--rw flow-entropy-vxlan? flow-entropy-vxlan augment /goam:ping/goam:input: +--ro (context-id-nvo3)? | +--:(vni) | +--ro vni? vni +--ro (out-of-band)? +--:(ipv4-address) | +--ro ipv4-address? inet:ipv4-address +--:(ipv6-address) +--ro ipv6-address? inet:ipv6-address augment /goam:ping/goam:input: +--ro technology-sub-type? identityref augment /goam:ping/goam:input: +--:(flow-entropy-vxlan) +--ro flags-vxlan? flags-vxlan +--ro flow-entropy-vxlan? flow-entropy-vxlan Senevirathne Expires December 10, 2014 [Page 8] Internet-Draft YANG Data Model for NVO3 OAM June 2014 augment /goam:trace-route/goam:input: +--ro (context-id-nvo3)? | +--:(vni) | +--ro vni? vni +--ro (out-of-band)? +--:(ipv4-address) | +--ro ipv4-address? inet:ipv4-address +--:(ipv6-address) +--ro ipv6-address? inet:ipv6-address augment /goam:trace-route/goam:input: +--ro technology-sub-type? identityref augment /goam:trace-route/goam:input: +--:(flow-entropy-vxlan) +--ro flags-vxlan? flags-vxlan +--ro flow-entropy-vxlan? flow-entropy-vxlan rpcs: +---x mtv | +--ro input | | +--ro technology identityref | | +--ro md-name-format MD-name-format | | +--ro md-name? binary | | +--ro md-level int32 | | +--ro ma-name-format MA-name-format | | +--ro ma-name binary | | +--ro technology-sub-type? identityref | | +--ro (context-id-nvo3)? | | | +--:(vni) | | | +--ro vni? vni | | +--ro (out-of-band)? | | | +--:(ipv4-address) | | | | +--ro ipv4-address? inet:ipv4-address | | | +--:(ipv6-address) | | | +--ro ipv6-address? inet:ipv6-address | | +--ro max-hop-count? uint8 | | +--ro command-sub-type? identityref | | +--ro (flow-entropy)? | | | +--:(flow-entropy-null) | | | | +--ro flow-entropy-null? empty | | | +--:(flow-entropy-vxlan) | | | +--ro flow-entropy-vxlan? flow-entropy-vxlan | | | +--ro flags-vxlan? flags-vxlan | | +--ro scope* inet:ip-address | | +--ro ecmp-choice? goam:ecmp-choices | | +--ro outgoing-interfaces* [interface] | | | +--ro interface if:interface-ref | | +--ro source-mep | | | +--ro (mep-address)? Senevirathne Expires December 10, 2014 [Page 9] Internet-Draft YANG Data Model for NVO3 OAM June 2014 | | | | +--:(mac-address) | | | | | +--ro mac-address? yang:mac-address | | | | +--:(ipv4-address) | | | | | +--ro ipv4-address? inet:ipv4-address | | | | +--:(ipv6-address) | | | | +--ro ipv6-address? inet:ipv6-address | | | +--ro mep-id? goam:MEP-id | | +--ro destination-mep | | +--ro (mep-address)? | | | +--:(mac-address) | | | | +--ro mac-address? yang:mac-address | | | +--:(ipv4-address) | | | | +--ro ipv4-address? inet:ipv4-address | | | +--:(ipv6-address) | | | +--ro ipv6-address? inet:ipv6-address | | +--ro mep-id? goam:MEP-id | +--ro output | +--ro response* [mep-address mep-id] | +--ro hop-count? uint8 | +--ro mep-id goam:MEP-id | +--ro mep-address inet:ip-address | +--ro next-hop-device* inet:ip-address | +--ro upstream-device? inet:ip-address | +--ro multicast-receiver-count? uint32 | +--ro tx-packt-count? oam-counter32 | +--ro rx-packet-count? oam-counter32 | +--ro min-delay? oam-counter32 | +--ro average-delay? oam-counter32 | +--ro max-delay? oam-counter32 +---x End-station-locator +--ro input | +--ro technology identityref | +--ro md-name-format MD-name-format | +--ro md-name? binary | +--ro md-level int32 | +--ro ma-name-format MA-name-format | +--ro ma-name binary | +--ro (context-id-nvo3)? | | +--:(vni) | | +--ro vni? vni | +--ro (out-of-band)? | | +--:(ipv4-address) | | | +--ro ipv4-address? inet:ipv4-address | | +--:(ipv6-address) | | +--ro ipv6-address? inet:ipv6-address | +--ro source-mep | | +--ro (mep-address)? Senevirathne Expires December 10, 2014 [Page 10] Internet-Draft YANG Data Model for NVO3 OAM June 2014 | | | +--:(mac-address) | | | | +--ro mac-address? yang:mac-address | | | +--:(ipv4-address) | | | | +--ro ipv4-address? inet:ipv4-address | | | +--:(ipv6-address) | | | +--ro ipv6-address? inet:ipv6-address | | +--ro mep-id? goam:MEP-id | +--ro end-station-address? End-station-address +--ro output +--ro devices* +--ro mep-id? goam:MEP-id +--ro mep-address? inet:ip-address +--ro mep-name? string Figure 3 Data hierarchy of NVO3 OAM Senevirathne Expires December 10, 2014 [Page 11] Internet-Draft YANG Data Model for NVO3 OAM June 2014 6. OAM YANG module file "xxx.yang" module nvo3-oam { namespace "urn:cisco:params:xml:ns:yang:nvo3-oam"; prefix nvo3-oam; import gen-oam { prefix goam; } import ietf-inet-types { prefix inet; } import ietf-interfaces { prefix if; } import ietf-yang-types { prefix yang; } revision 2014-04-24 { description "Initial revision."; } identity nvo3 { base goam:technology-types; description "nvo3 type"; } identity nvo3-mtv { base goam:command-sub-type; } identity nvo3-trace-route { base goam:command-sub-type; } identity nvo3-ping { base goam:command-sub-type; } identity technology-sub-type { description "certain implementations such as nvo3 can have different encap types such as vxlan, nvgre and so on. Senevirathne Expires December 10, 2014 [Page 12] Internet-Draft YANG Data Model for NVO3 OAM June 2014 Instead of defining seperate models for each such encap we define technology sub type. Technology subtype is associated at MA level"; } identity technology-sub-type-vxlan { base technology-sub-type; description "technology subtype is vxlan"; } grouping command-ext-nvo3 { description "group the rpc command extensions for nvo3"; choice context-id-nvo3 { case vni { leaf vni { type vni; } } } choice out-of-band { case ipv4-address { leaf ipv4-address { type inet:ipv4-address; } } case ipv6-address { leaf ipv6-address { type inet:ipv6-address; } } description "presence of this node indicate out of band request needed"; } } typedef flow-entropy-vxlan { type inet:port-number; } typedef vni { type uint32; } typedef flags-vxlan { type bits { Senevirathne Expires December 10, 2014 [Page 13] Internet-Draft YANG Data Model for NVO3 OAM June 2014 bit oam { position 0; } bit r1 { position 1; } bit r2 { position 2; } bit r3 { position 3; } bit r4 { position 4; } bit r5 { position 5; } bit r6 { position 6; } bit r7 { position 7; } } } typedef End-station-address { type union { type yang:mac-address; type inet:ipv4-address; type inet:ipv6-address; } description "Defines addresses of different End stations, MAC, IPv4 or IPv6"; } augment "/goam:domains/goam:domain/goam:MAs/goam:MA" { leaf technology-sub-type { type identityref { base technology-sub-type; } } } augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:context- id" { Senevirathne Expires December 10, 2014 [Page 14] Internet-Draft YANG Data Model for NVO3 OAM June 2014 case context-id-nvo3 { leaf vni { type vni; } } } augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:flow- entropy" { case flow-entropy-vxlan { leaf flags-vxlan { type flags-vxlan; } leaf flow-entropy-vxlan { type flow-entropy-vxlan; } } } augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:flow- entropy" { case flow-entropy-vxlan { leaf flags-vxlan { type flags-vxlan; } leaf flow-entropy-vxlan { type flow-entropy-vxlan; } } } augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:context-id" { case context-id-nvo3 { leaf vni { type vni; } } } augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goa m:context-id" { case context-id-nvo3 { leaf vni { type vni; } } } Senevirathne Expires December 10, 2014 [Page 15] Internet-Draft YANG Data Model for NVO3 OAM June 2014 augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goa m:flow-entropy" { case flow-entropy-vxlan { leaf flags-vxlan { type flags-vxlan; } leaf flow-entropy-vxlan { type flow-entropy-vxlan; } } } augment "/goam:ping/goam:input" { uses command-ext-nvo3; } augment "/goam:ping/goam:input" { leaf technology-sub-type { type identityref { base technology-sub-type; } } } augment "/goam:ping/goam:input" { case flow-entropy-vxlan { leaf flags-vxlan { type flags-vxlan; } leaf flow-entropy-vxlan { type flow-entropy-vxlan; } } } augment "/goam:trace-route/goam:input" { uses command-ext-nvo3; } augment "/goam:trace-route/goam:input" { leaf technology-sub-type { type identityref { base technology-sub-type; } } } augment "/goam:trace-route/goam:input" { case flow-entropy-vxlan { leaf flags-vxlan { type flags-vxlan; } Senevirathne Expires December 10, 2014 [Page 16] Internet-Draft YANG Data Model for NVO3 OAM June 2014 leaf flow-entropy-vxlan { type flow-entropy-vxlan; } } } rpc mtv { description "Generates Trace-route and return response. Starts with TTL of one and increment by one at each hop. Untill destination reached or TTL reach max valune"; input { uses goam:maintenance-domain { description "Specifies the MA-domain"; } uses goam:ma-identifier { description "identfies the Maintenance association"; } leaf technology-sub-type { type identityref { base technology-sub-type; } } uses command-ext-nvo3 { description "defines extensions needed for nvo3 We are using this structure so mtv command is in line with ping and trace-route"; } leaf max-hop-count { type uint8; default "255"; description "Defines maximum value of hop count"; } leaf command-sub-type { type identityref { base goam:command-sub-type; } description "defines different command types"; } choice flow-entropy { case flow-entropy-null { leaf flow-entropy-null { type empty; Senevirathne Expires December 10, 2014 [Page 17] Internet-Draft YANG Data Model for NVO3 OAM June 2014 } } case flow-entropy-vxlan { leaf flow-entropy-vxlan { type flow-entropy-vxlan; } leaf flags-vxlan { type flags-vxlan; } } } leaf-list scope { type inet:ip-address; } leaf ecmp-choice { type goam:ecmp-choices; description "0 means use platform defined path selection 1 means use round robin"; } list outgoing-interfaces { key "interface"; leaf interface { type if:interface-ref; } } container source-mep { uses goam:mep-address; leaf mep-id { type goam:MEP-id; } } container destination-mep { uses goam:mep-address; leaf mep-id { type goam:MEP-id; } } } output { list response { key "mep-address mep-id"; leaf hop-count { type uint8; } leaf mep-id { type goam:MEP-id; Senevirathne Expires December 10, 2014 [Page 18] Internet-Draft YANG Data Model for NVO3 OAM June 2014 } leaf mep-address { type inet:ip-address; } leaf-list next-hop-device { type inet:ip-address; description "list of downstream devices. This is not specifically sorted it is a leaf list"; } leaf upstream-device { type inet:ip-address; } leaf multicast-receiver-count { type uint32; description "number of ports that are interested in this multicast stream"; } uses goam:monitor-stats; } } } rpc End-station-locator { description "Allows to discover where the end station is located."; input { uses goam:maintenance-domain { description "Specifies the MA-domain"; } uses goam:ma-identifier { description "identfies the Maintenance association"; } uses command-ext-nvo3; container source-mep { uses goam:mep-address; leaf mep-id { type goam:MEP-id; } } leaf end-station-address { type End-station-address; description "End station address can be MAC address, IPv4 or IPv6 address."; Senevirathne Expires December 10, 2014 [Page 19] Internet-Draft YANG Data Model for NVO3 OAM June 2014 } } output { list devices { leaf mep-id { type goam:MEP-id; } leaf mep-address { type inet:ip-address; } leaf mep-name { type string; description "End-station locator response MAY return the textual name of MEP that owns the end-station. If textual name is not available word Unknown SHOULD be returned"; } } } } } 7. Base Mode for NVO3 OAM Base Mode defines default configuration that MUST be present in the devices that comply with this document. Base Mode allows users to have zero-touch experience. Details of NVO3 Base Mode for OAM are defined in [NVO3OAMFM]. 8. Security Considerations TBD 9. IANA Considerations This document registers the following namespace URI in the IETF XML registry. URI:TBD Senevirathne Expires December 10, 2014 [Page 20] Internet-Draft YANG Data Model for NVO3 OAM June 2014 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, August, 2011. [GENYANGOAM] Senevirathne, T., et.al., "YANG Data Model for Operations, Administration and Maintenance (OAM)", Work in Progress, March, 2014. 10.2. Informative References [RFCabab] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-1583. [Y1731] ITU, "OAM functions and mechanisms for Ethernet based networks", ITU-T G.8013/Y.1731, July, 2011. [TRLOAMFRM] Salam, S., et.al., "TRILL OAM Framework", draft-ietf- trill-oam-framework, Work in Progress, November, 2012. [RFC6291] Andersson, L., et.al., "Guidelines for the use of the "OAM" Acronym in the IETF" RFC 6291, June 2011. [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. [NVO3OAMFM] Senevirathne, T., et.al., "NVO3 Fault Management", Work in Progress, February, 2014. Senevirathne Expires December 10, 2014 [Page 21] Internet-Draft YANG Data Model for NVO3 OAM June 2014 11. Acknowledgments Giles Heron came up with the idea of developing a YANG model as a way of creating a unified OAM API set (interface), work in this document is largely an inspiration of that. Alexander Clemm provided many valuable tips, comments and remarks that helped to refine the YANG model presented in this document. This document was prepared using 2-Word-v2.0.template.dot. Senevirathne Expires December 10, 2014 [Page 22] Internet-Draft YANG Data Model for NVO3 OAM June 2014 Authors' Addresses Tissa Senevirathne CISCO Systems 375 East Tasman Drive. San Jose, CA 95134 USA. Phone: 408-853-2291 Email: tsenevir@cisco.com Norman Finn CISCO Systems 510 McCarthy Blvd Milpitas, CA 95035. Email: nfinn@cisco.com Deepak Kumar CISCO Systems 510 McCarthy Blvd Milpitas, CA 95035. Email: dekumar@cisco.com Samer Salam CISCO Systems 595 Burrard St. Suite 2123 Vancouver, BC V7X 1J1, Canada Email: ssalam@cisco.com Carlos Pignataro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 EMail: cpignata@cisco.com Senevirathne Expires December 10, 2014 [Page 23]