Internet DRAFT - draft-tissa-nvo3-yang-oam
draft-tissa-nvo3-yang-oam
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:
<status> <flags> <name> <opts> <type>
<status> is one of:
+ for current
x for deprecated
o for obsolete
<flags> 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
<name> is the name of the node
If the node is augmented into the tree from another module, its
name is printed as <prefix>:<name>.
<opts> is one of:
? for an optional leaf or choice
! for a presence container
* for a leaf-list or list
[<keys>] for a list's keys
<type> 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
<CODE BEGINS> 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";
}
}
}
}
}
<CODE ENDS>
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]
