One document matched: draft-ashwood-nvo3-oam-requirements-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6136 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6136.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ashwood-nvo3-oam-requirements-01"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title>NVO3 Operations, Administration, and Maintenance
Requirements</title>
<author fullname="Peter Ashwood-Smith" initials="P."
surname="Ashwood-Smith">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>303 Terry Fox Drive, Suite 400</street>
<!-- Reorder these if your country does things differently -->
<city>Kanata</city>
<region>Ontario</region>
<country>Canada</country>
<code>K2K 3J1</code>
</postal>
<phone>+1 613 595-1900</phone>
<email>Peter.AshwoodSmith@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Liang Xia (Frank)" initials="L." surname="Xia">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street/>
<!-- Reorder these if your country does things differently -->
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<email>Frank.xialiang@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Ranga Iyengar" initials="R." surname="Iyengar">
<organization>Huawei Technologies USA</organization>
<address>
<postal>
<street>2330 Central Expy</street>
<!-- Reorder these if your country does things differently -->
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone/>
<email>ranga.Iyengar@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization>Huawei Technologies USA</organization>
<address>
<postal>
<street>2330 Central Expy</street>
<!-- Reorder these if your country does things differently -->
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone/>
<email>Tina.Tsou.Zouting@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Ali Sajassi" initials="A." surname="Sajassi">
<organization>Cisco Technologies</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<!-- Reorder these if your country does things differently -->
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone/>
<email>sajassi@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street/>
<!-- Reorder these if your country does things differently -->
<city>Rennes</city>
<region/>
<code>35000</code>
<country>France</country>
</postal>
<phone/>
<email>mohamed.boucadair@orange.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>France Telecom</organization>
<address>
<postal>
<street/>
<!-- Reorder these if your country does things differently -->
<city>Rennes</city>
<region/>
<code>35000</code>
<country>France</country>
</postal>
<phone/>
<email>christian.jacquenet@orange.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Masahiro Daikoku" initials="M." surname="Daikoku">
<organization>KDDI corporation</organization>
<address>
<postal>
<street>3-10-10, Iidabashi, Chiyoda-ku</street>
<!-- Reorder these if your country does things differently -->
<city/>
<region>Tokyo</region>
<code>1028460</code>
<country>Japan</country>
</postal>
<phone/>
<email>ms-daikoku@kddi.com</email>
</address>
</author>
<author fullname="Anoop Ghanwani" initials="A." surname="Ghanwani">
<organization>Dell</organization>
<address>
<postal>
<street>5450 Great America Pkwy</street>
<!-- Reorder these if your country does things differently -->
<city/>
<region>Santa Clara, CA</region>
<code/>
<country>USA</country>
</postal>
<phone/>
<email>anoop@alumni.duke.edu</email>
</address>
</author>
<author fullname="Ram Krishnan" initials="R." surname="Krishnan">
<organization>Brocade</organization>
<address>
<postal>
<street>130 Holger Way</street>
<!-- Reorder these if your country does things differently -->
<city/>
<region>San Jose, CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone/>
<email>ramk@brocade.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2014"/>
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current year is
specified, xml2rfc will fill in the current day and month for you. If the
year is not the current one, it is necessary to specify at least a month
(xml2rfc assumes day="1" if not specified for the purpose of calculating
the expiry date). With drafts it is normally sufficient to specify just
the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>network virtualization over layer 3</keyword>
<keyword>NVO3</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document provides framework and requirements for Network
Virtualization Overlay (NVO3) Operations, Administration, and
Maintenance (OAM). This document for the most part gathers requirements
from existing IETF drafts and RFCs which have already extensively
studied this subject for different data planes and layering. As a result
this draft is high level and broad. We begin to ask which are truly
required for NVO3 and expect the list to be narrowed by the working
group as subsequent versions of this draft are created.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document provides framework and requirements for Network
Virtualization Overlay (NVO3) Operations, Administration, and
Maintenance (OAM). Given that this OAM subject is far from new and has
been under extensive investigation by various IETF working groups (and
several other standards bodies) for many years, this document draws from
existing work, starting with <xref target="RFC6136"/>. As a result,
sections of <xref target="RFC6136"/> have been reused with minor changes
with the permission of the authors.</t>
<t>NVO3 OAM requirements are expected to be a subset of IETF/IEEE etc.
work done so far; however, we begin with a full set of requirements and
expect to prune them through several iterations of this document.</t>
<section anchor="OSIdef" title="OSI Definitions of OAM">
<t>The scope of OAM for any service and/or transport/network
infrastructure technologies can be very broad in nature. OSI has
defined the following five generic functional areas commonly
abbreviated as "FCAPS" [NM-Standards]: <list style="symbols">
<t>Fault Management,</t>
<t>Configuration Management,</t>
<t>Accounting Management,</t>
<t>Performance Management, and</t>
<t>Security Management.</t>
</list></t>
<t>This document focuses on the Fault, Performance and to a limited
extent the Configuration Management aspects. Other functional aspects
of FCAPS and their relevance (or not) to NVO3 are for further
study.</t>
<t>Fault Management can typically be viewed in terms of the following
categories: <list style="symbols">
<t>Fault Detection;</t>
<t>Fault Verification;</t>
<t>Fault Isolation;</t>
<t>Fault Notification and Alarm Suppression;</t>
<t>Fault Recovery.</t>
</list></t>
<t>Fault detection deals with mechanism(s) that can detect both hard
failures such as link and device failures, and soft failures, such as
software failure, memory corruption, misconfiguration, etc. Fault
detection relies upon a set of mechanisms that first allow the
observation of an event, then the use of a protocol to dynamically
notify a network/system operator (or management system) about the
event occurrence, then the use of diagnostic tools to assess the
nature and severity of the fault.</t>
<t>After verifying that a fault has occurred along the data path, it
is important to be able to isolate the fault to the level of a given
device or link. Therefore, a fault isolation mechanism is needed in
Fault Management. A fault notification mechanism should be used in
conjunction with a fault detection mechanism to notify the devices
upstream and downstream to the fault detection point. The fault
notification mechanism should also notify NMS systems. <list
style="empty">
<t>The terms "upstream" and "backward" are used here to denote the
direction(s) from which data traffic is flowing. The terms
"downstream" and "forward" denote the direction(s) to which data
traffic is forwarded.</t>
</list></t>
<t>For example, when there is a client/server relationship between two
layered networks (e.g., the NVO3 layer is a client of the outer IP
server layer, while the inner IP layer is a client of the NVO3 server
layer 2), fault detection at the server layer may result in the
following fault notifications: <list style="symbols">
<t>Sending a forward fault notification from the server layer to
the client layer network(s) using the fault notification format
appropriate to the client layer.</t>
<t>Sending a backward fault notification to the server layer, if
applicable, in the reverse direction.</t>
<t>Sending a backward fault notification to the client layer, if
applicable, in the reverse direction.</t>
</list></t>
<t>Finally, fault recovery deals with recovering from the detected
failure by switching to an alternate available data path (depending on
the nature of the fault) using alternate devices or links. In fact,
the controller can provision another virtual network, thus
automatically resolving the reported problem.</t>
<t>The controller may also directly monitor the status of virtual
network components such as Network Virtualization Edge elements (NVEs)
<xref target="NVO3-framework"/> in order to respond to their failures.
In addition to forward and backward fault notifications, the
controller may deliver notifications to a higher level orchestration
component, e.g., one responsible for Virtual Machine (VM) provisioning
and management.</t>
<t>Note, given that the IP network on which NVO3 resides is usually
self healing, it is expected that recovery by the NVO3 layer would not
normally be required, although there may be a requirement for that
layer to log that the problem has been detected and resolved. The
special cases of a static IP overlay network, or possibly of a
centrally controlled IP overlay network, may, however, require NVO3
involvement in fault recovery.</t>
<t>Performance Management deals with mechanism(s) that allow
determining and measuring the performance of the network/services
under consideration. Performance Management can be used to verify the
compliance to both the service-level and network-level metric
objectives/specifications. Performance Management typically consists
of measuring performance metrics, e.g., Frame Loss, Frame Delay, Frame
Delay Variation (aka Jitter), Frame Throughput, Frame Discard, etc.,
across managed entities when the managed entities are in available
state. Performance Management is suspended across unavailable managed
entities.</t>
</section>
<!-- OSIdef -->
<section title="Requirements Language">
<t>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 <xref
target="RFC2119"/>.</t>
</section>
<section title="Relationship with Other OAM Work">
<t>This document leverages requirements that originate with other OAM
work, specifically the following: <list style="symbols">
<t><xref target="RFC6136"/> provides a template and some of the
high level requirements and introductory wording.</t>
<t><xref target="IEEE802.1Q-2011"/> is expected to provide a
subset of the requirements for NVO3 both at the Tenant level and
also within the L3 Overlay network.</t>
<t><xref target="Y.1731"/> is expected to provide a subset of the
requirements for NVO3 at the Tenant level.</t>
<t>Section 3.3.2.1 of <xref target="NVO3-DP-Reqs"/> lists several
requirements specifically concerning ECMP/LAG.</t>
</list></t>
</section>
</section>
<!-- Introduction -->
<section title="Terminology">
<t>The terminology defined in <xref target="NVO3-framework"/> and <xref
target="NVO3-DP-Reqs"/> is used throughout this document. We introduce
no new terminology.</t>
</section>
<section anchor="refModel" title="NVO3 Reference Model">
<t><xref target="fig1"/> below reproduces the generic NVO3 reference
model as per <xref target="NVO3-framework"/>.</t>
<figure anchor="fig1"
title="Generic reference model for DC network virtualization over a Layer3 infrastructure">
<artwork>
+--------+ +--------+
| Tenant | | Tenant |
| End +--+ +---| End |
| System | | | | System |
+--------+ | ................... | +--------+
| +-+--+ +--+-+ |
| | NV | | NV | |
+--|Edge| |Edge|--+
+-+--+ +--+-+
/ . L3 Overlay . \
+--------+ / . Network . \ +--------+
| Tenant +--+ . . +----| Tenant |
| End | . . | End |
| System | . +----+ . | System |
+--------+ .....| NV |........ +--------+
|Edge|
+----+
|
|
+--------+
| Tenant |
| End |
| System |
+--------+
</artwork>
</figure>
<t><xref target="fig2"/> below, reproduces the Generic reference model
for the NV Edge (NVE) as per <xref target="NVO3-DP-Reqs"/>.</t>
<figure anchor="fig2" title="Generic reference model for NV Edge">
<artwork>
+------- L3 Network ------+
| |
| Tunnel Overlay |
+------------+---------^-+ +--------+-------------^-+
| +----------+------+ | | | +------+----------+ | |
| | Overlay Module | | | | | Overlay Module | | |
| +--------+--------+ | | | +--------+--------+ | |
| | VNID | | | | VNID | |
| | OAM | | | OAM |
| +-------+-------+ | | | +-------+-------+ | |
| | VNI | | | | | VNI | | |
NVE1 | +-+-----------+-+ | | NVE2 | +-+-----------+-+ | |
| | VAPs | | | | | VAPs | | |
+----+-----------+-----V-+ +----+-----------+-----V-+
| | | |
-------+-----------+--------------------+-----------+-----_--
| | Tenant | |
| | Service IF | |
Tenant End Systems Tenant End Systems
</artwork>
</figure>
</section>
<!-- refModel -->
<section anchor="frame" title="OAM Framework for NVO3">
<t><xref target="fig1"/> showed the generic reference model for a DC
network virtualization over an L3 (or L3VPN) infrastructure while <xref
target="fig2"/> showed the generic reference model for the Network
Virtualization (NV) Edge.</t>
<t>L3 network(s) or L3 VPN networks (either IPv6 or IPv4, or a
combination thereof), provide transport for an emulated layer 2 created
by NV Edge devices. Unicast and multicast tunneling methods
(de-multiplexed by Virtual Network Identifier (VNID)) are used to
provide connectivity between the NV Edge devices. The NV Edge devices
then present an emulated layer 2 network to the Tenant End Systems at a
Virtual Network Interface (VNI) through Virtual Access Points (VAPs).
The NV Edge devices map layer 2 unicast to layer 3 unicast
point-to-point tunnels and may either map layer 2 multicast to layer 3
multicast tunnels or may replicate packets onto multiple layer 3 unicast
tunnels.</t>
<section title="OAM Layering">
<t>The emulated layer 2 network is provided by the NV Edge devices to
which the Tenant End Systems are connected. This network of NV Edges
can be operated by a single service provider or can span across
multiple administrative domains. Likewise, the L3 Overlay Network can
be operated by a single service provider or span across multiple
administrative domains.</t>
<t>While each of the layers is responsible for its own OAM, each layer
may consist of several different administrative domains. <xref
target="fig3"/> shows an example.</t>
<figure anchor="fig3" title="OAM layers in an NVO3 network">
<artwork>
OAM
---
TENANT |----------------------------| TENANT {all IP/ETH}
NV Edge |----------------------| NV Edge {t.b.d.}
IP(VPN) |---| IP (VPN) |---| IP(VPN) {IP(VPN)/ETH}
</artwork>
</figure>
<t>For example, at the bottom, at the L3 IP overlay network layer
IP(VPN) and/or Ethernet OAM mechanisms are used to probe link by link,
node to node etc. OAM addressing here means physical node loopback or
interface addresses.</t>
<t>Further up, at the NV Edge layer, NVO3 OAM messages are used to
probe the NV Edge to NV Edge tunnels and NV Edge entity status. OAM
addressing here likely means the physical node loopback together with
the VNI (to de-multiplex the tunnels).</t>
<t>Finally, at the Tenant layer, the IP and/or Ethernet OAM mechanisms
are again used but here they are operating over the logical L2/L3
provided by the NV-Edge through the VAP. OAM addressing at this layer
deals with the logical interfaces on Vswitches and Virtual
Machines.</t>
</section>
<!-- layering -->
<section title="OAM Domains">
<t>Complex OAM relationships exist as a result of the hierarchical
layering of responsibility and of breaking up of end-to-end
responsibility.</t>
<t>The OAM domain above NVO3, is expected to be supported by existing
IP and L2 OAM methods and tools.</t>
<t>The OAM domain below NVO3, is expected to be supported by existing
IP/L2 and MPLS OAM methods and tools. Where this layer is actually
multiple domains spliced together, the existing methods to deal with
these boundaries are unchanged. Note however that exposing LAG/ECMP
detailed behavior may result in additional requirements to this
domain, the details of which will be specified in the future versions
of this draft.</t>
<t>When we refer to an OAM domain in this document, or just 'domain',
we therefore refer to a closed set of NV Edges or MEPs and the tunnels
which interconnect them.</t>
<t>Note, whether for the scenario of inter-domain or multi-layer, each
domain (or layer) is responsible for its own OAM, no correlation of
OAM function exists between each domain (or layer). When an E2E
connection in Tenant layer spans across multiple domains and has
multiple underlay layers of NV Edge layer and L3 IP (VPN) layer,
current OAM implementation for the E2E connection of Tenant layer such
as Fault or Performance Management can only be performed per domain
and layer manually and more manual labor is needed. An automatic
coordination process among OAM functions of each domain or layer may
be useful here for improving efficiency and intelligence.</t>
<t>In the case where a gateway device is use to connect two different
domains (whether for changing the encapsulation or other reasons), it
is necessary to provide mechanisms to monitor the path through the
gateway which involves the removal of one overlay header and the
creation of a new one.</t>
</section>
</section>
<!-- frame -->
<section title="NVO3 OAM Requirements">
<t>The following numbered requirements originate from <xref
target="RFC6136"/>. All are included however where they seem obviously
not relevant (to the present authors) an explanation as to why is
included.</t>
<section title="Discovery">
<t>R1) NVO3 OAM MUST allow an NV Edge device to dynamically discover
other NV Edge devices that share the same VNI within a given NVO3
domain. This may be based on a discovery mechanism used to set up data
path forwarding between NVEs.</t>
</section>
<section title="Connectivity Fault Management">
<section title="Connectivity Fault Detection">
<t>R2) NVO3 OAM MUST allow proactive connectivity monitoring between
two or more NV Edge devices that support the same VNIs within a
given NVO3 domain. NVO3 OAM MAY act as a protection trigger. That
is, automatic recovery from transmission facility failure by
switchover to a redundant replacement facility may be triggered by
notifications from NVO3 OAM.</t>
<t>R3) NVO3 OAM MUST allow monitoring/tracing of all possible paths
in the underlay network between a specified set of two or more NV
Edge devices. Using this feature, equal cost paths that traverse LAG
and/or ECMP may be differentiated.</t>
</section>
<section title="Connectivity Fault Verification">
<t>R4) NVO3 OAM MUST allow connectivity fault verification between
two or more NV Edge devices that support the same VNI within a given
NVO3 domain.</t>
</section>
<section title="Connectivity Fault localization">
<t>R5) NVO3 OAM MUST allow connectivity fault localization between
two or more NV Edge devices that support the same VNI within a given
NVO3 domain.</t>
</section>
<section title="Connectivity Fault Notification and Alarm Suppression">
<t>R6) NVO3 OAM MUST support fault notification to be triggered as a
result of the faults occurring in the underneath network
infrastructure. This fault notification SHOULD be used for the
suppression of redundant service-level alarms.</t>
</section>
</section>
<!-- Connect fault mgmt -->
<section title="Frame Loss">
<t>R7) NVO3 OAM MUST support measurement of per VNI frame loss between
two NV Edge devices that support the same VNI within a given NVO3
domain.</t>
</section>
<section title="Frame Delay">
<t>R8) NVO3 OAM MUST support measurement of per VNI two-way frame
delay between two NV edge devices that support the same VNI within a
given NVO3 domain.</t>
<t>R9) NVO3 OAM MUST support measurement of per VNI one-way frame
delay between two NV Edge devices that support the same VNI within a
given NVO3 domain.</t>
</section>
<section title="Frame Delay Variation">
<t>R10) NVO3 OAM MUST support measurement of per VNI frame delay
variation between two NV Edge devices that support the same VNI within
a given NVO3 domain.</t>
</section>
<section title="Frame Throughput">
<t>R11) NVO3 OAM MAY [*** Should this be stronger? ***] support
measurement of per VNI frame throughput (in frames and bytes) between
two NV Edge devices that support the same VNI within a given NVO3
domain. This feature could be an effective way to confirm whether or
not assigned path bandwidth conforms to service level agreement before
providing the path between two NV Edge devices.</t>
</section>
<section title="Frame Discard">
<t>R12) NVO3 OAM MAY support measurement of per VNI frame discard
between two NV Edge devices that support the same VNI within a given
NVO3 domain. This feature MAY be effective to monitor bursty traffic
between two NV Edge devices.</t>
</section>
<section title="Availability">
<t>A service may be considered unavailable if the service
frames/packets do not reach their intended destination (e.g.,
connectivity is down) or the service is degraded (e.g., frame loss
and/or frame delay and/or delay variation threshold is exceeded).
Entry and exit conditions may be defined for the unavailable state.
Availability itself may be defined in the context of a service type.
Since availability measurement may be associated with connectivity,
frame loss, frame delay, and frame delay variation measurements, no
additional requirements are specified currently.</t>
</section>
<section title="Data Path Forwarding">
<t>R13) NVO3 OAM frames MUST be forwarded along the same path (i.e.,
links (including LAG members) and nodes) as the NVO3 data frames.</t>
<t>R14) NVO3 OAM frames MUST provide a mechanism to exercise/trace all
data paths that result due to ECMP/LAG hops in the underlay
network.</t>
</section>
<section title="Scalability">
<t>R15) NVO3 OAM MUST be scalable such that an NV edge device can
support proactive OAM for each VNI that is supported by the device.
(Note - Likely very hard to achieve with hash based ECMP/LAG).</t>
</section>
<section title="Extensibility">
<t>R16) NVO3 OAM should be extensible such that new functionality and
information elements related to this functionality can be introduced
in the future.</t>
<t>R17) NVO3 OAM MUST be defined such that devices not supporting the
OAM are able to forward the OAM frames in a similar fashion as the
regular NVO3 data frames/packets.</t>
</section>
<section title="Security">
<t>R18) NVO3 OAM frames MUST be prevented from leaking outside their
NVO3 domain.</t>
<t>R19) NVO3 OAM frames from outside an NVO3 domain MUST be prevented
from entering the said NVO3 domain when such OAM frames belong to the
same level or to a lower-level OAM. (Trivially met because
hierarchical domains are independent technologies.)</t>
<t>R20) NVO3 OAM frames from outside an NVO3 domain MUST be
transported transparently inside the NVO3 domain when such OAM frames
belong to a higher-level NVO3 domain. (Trivially met because
hierarchical domains are independent technologies).</t>
</section>
<section title="Transport Independence">
<t>Similar to transport requirement from <xref target="RFC6136"/>, we
expect NVO3 OAM will leverage the OAM capabilities of the transport
layer (e.g., IP underlay).</t>
<t>R21) NVO3 OAM MAY allow adaptation/interworking with its IP
underlay OAM functions. For example, this would be useful to allow
fault notifications from the IP layer to be sent to the NVO3 layer and
likewise exposure of LAG / ECMP will require such
non-independence.</t>
</section>
<section title="Application Independence">
<t>R22) NVO3 OAM MUST [*** discuss -- is this too strong? ***] be
independent of the application technologies and specific application
OAM capabilities.</t>
<t>[Comment -- ECM: Noticed Nicira implementation has a dedicated NVP
manager node to play the role of FCAPS here. It is both application
layer and OAM layer. May not meet this requirement. In reality, due to
the nature of overlay network, very often, vendors are going to make
everything all together to a dedicated manager node.]</t>
</section>
<section title="Prioritization">
<t>R23) NVO3 OAM messages MUST be preferentially treated in NVE and
between NVEs, since NVO3 OAM MAY be used to trigger protection
switching. As noted above (R2), protection switching is the automatic
replacement of a failed transmission facility with a working one
providing equal or greater capacity, typically within a few tens of
milliseconds from fault detection.</t>
<t>[Comment -- ECM: giving NVO3 OAM messages priority treatment may
interfere with measurements of frame delay and jitter.]</t>
</section>
<!-- -->
<section anchor="logging" title="Logging and Traceability Requirements">
<t>Logging is required at the Network Virtualization Authority (NVA)
and the Network Virtualization Edge (NVE) [and the NVO3 Gateway, but
the framework does not mention such a beast] in support of fault
management and configuration management.</t>
<t>R24) All logs MUST contain a timestamp of sufficient accuracy and
precision to allow accurate determination of the sequence of events at
the reporting functional instance (i.e., NVA, NVE). Clocks on
different functional instances SHOULD be synchronized to allow similar
accuracy when comparing logs from different devices.</t>
<t>R25) All logs MUST identify the reporting functional instance.</t>
<t>R26) Implementations MUST be capable of reporting the following
fault- related events: <list style="numbers">
<t>Loss and resumption of connectivity <vspace blankLines="1"/>
These reports SHOULD identify the affected VNI(s), but when the
loss affects a large number of VNIs simultaneously the report
SHOULD identify the underlying entity (e.g., route) if
available.</t>
<t>Loss and resumption of NVE responsiveness <vspace
blankLines="1"/> These reports will be generated by adjacent NVAs
or NVEs. They MUST identify the NVE concerned.</t>
<t>NVA or NVE change of operational state <vspace blankLines="1"/>
These reports will be generated by the NVA or NVE concerned. They
MUST indicate the old and new operational states and the
cause.</t>
<t>Loss and resumption of a VAP</t>
</list> [What else?]</t>
<t>R27) Implementations MUST be capable of reporting the following
events in support of configuration management and auditing. It MUST be
possible to generate the reports at both the originating and executing
entities. The report generated at the originating entity MUST identify
the executing entity and the report at the executing entity MUST
identify the originating entity. Both reports MUST indicate the result
of the transaction. <list style="numbers">
<t>Virtual Access Point (VAP) creation or deletion <vspace
blankLines="1"/> These reports MUST identify the VAP, the Tenant
System, and the port supporting the VAP.</t>
<t>VNI creation or deletion <vspace blankLines="1"/> These reports
MUST identify the VNI and the VAP.</t>
<t>VNI renumbering <vspace blankLines="1"/> These reports MUST
identify the VAP and the old and new VNI numbers.</t>
<t>Reachability and forwarding information update <vspace
blankLines="1"/> These reports MUST identify the previous and new
file identifiers. (Assumption: reachability and forwarding
information is passed as files, which are retained at the
originating and executing entities for a fixed period for auditing
purposes.)</t>
</list> [What else?]</t>
<t>R28) As a general requirement, implementations MUST provide a means
whereby the operator can impose rate limits on the generation of
specific reports. Implementations MUST further permit the operator to
totally suppress reporting of specific events. However, if any report
types have been suppressed, non-suppressible reports MUST be generated
at regular intervals (e.g., once an hour) indicating what report types
have been suppressed.</t>
</section>
<!-- logging -->
</section>
<!-- OAM reqs -->
<section title="Items for Further Discussion">
<t>This section identifies a set of operational items which may be
elaborated further if these items fall within the scope of the NVO3.
<list style="symbols">
<t>VNID renumbering support <list style="symbols">
<t>Means to change the VNID assigned to a given instance MUST
[*** discuss: is this too strong? ***] be supported.</t>
<t>System convergence subsequent to VNID renumbering MUST NOT
take longer than a few seconds, to minimize impact on the tenant
systems.</t>
<t>A NVE MUST be able to map a VNID with a virtual network
context.</t>
</list></t>
<t>VNI migration and management operations <list style="symbols">
<t>Means to delete an existing VNI MUST be supported.</t>
<t>Means to add a new VNI MUST be supported.</t>
<t>Means to merge several VNIs MAY be supported.</t>
<t>Means to retrieve reporting data per VNI MUST be
supported.</t>
<t>Means to monitor the network resources per VNI MUST be
supported.</t>
</list></t>
<t>Support of planned maintenance operations on the NVO3
infrastructure <list style="symbols">
<t>Graceful procedure to allow for planned maintenance operation
on NVE MUST be supported. This includes undoing any
configuration changes made for maintenance purposes after
completion of the maintenance.</t>
</list></t>
<t>Support for communication among virtual networks <list
style="symbols">
<t>For global reachability purposes, communication among virtual
networks MUST be supported. This can be enforced using a NAT
function.</t>
</list></t>
<t>Activation of new network-related services to the NVO3 <list
style="symbols">
<t>Means to assist in activating new network services (e.g.,
multicast) without impacting running service SHOULD be
supported.</t>
</list></t>
<t>Inter-operator NVO3 considerations <list style="symbols">
<t>As NVO3 may be deployed over inter-operator infrastructure,
coordinating OAM actions in each individual domain are required
to ensure an end-to-end OAM. In particular, this assumes
existence of agreements on the measurement and monitoring
methods, fault detection and repair actions, extending QoS
classes (e.g., DSCP mapping policies), etc. <list>
<t>[[DISCUSSION NOTE: Should inter-operator issues be
declared out of scope?]]</t>
</list></t>
</list></t>
<t>An automatic coordination process among OAM functions of
different domains or layers which an E2E connection in Tenant layer
is tunnelled on<list style="symbols">
<t>NVO3 OAM MAY support the automatic coordination of OAM
functions among different domains or layers which belong to one
Tenant layer E2E connection. The automatic coordination means
OAM function in client layer or one domain triggers associated
OAM functions in server layer or neighbouring domain. This
triggered action performs at the domain boundaries, which is
also the MEPs of the domain. Which OAM function in client layer
or one domain can trigger Which OAM functions in server layer or
neighbouring domain depends on specific condition, and can be
very flexible. But the basic rule is that the OAM functions
performed simultaneously in different domains or layers can be
synthesized together to get the final result.</t>
<t>The OAM MEPs of domains MUST have the capability to know if
it needs to perform the above automatic coordination process.
This can be achieved by many ways, i.e., by configuration, by
checking the flag field in OAM frames.</t>
<t>When the OAM MEPs perform the automatic coordination, a
specific global characteristic information MUST be carried and
mapped between OAM frames used in different domains or layers,
and be kept the same alone the whole tenant layer E2E
connection. The global characteristic information can be the
tenant network identifier (e.g., VNID), ICMP sequence number,
etc. It is used for identifying a set of correlated OAM results
obtained from these domains or layers. This set of OAM results
is then synthesized together to get the final diagnose
result.</t>
<t>NVO3 OAM MUST support a Collection Point for collecting all
the OAM results and synthesizing them. It can be the SDN
controller, NVA, or NMS. An E2E OAM function in tenant network
can trigger several OAM functions in different underlay
networks, a Collection Point is needed to collect all the OAM
results from different OAM MEPs of different domains or layers
and synthesizes them.</t>
</list></t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>The authors are grateful for the contributions of David Black, Dennis
Qin, Erik Smith and Ziye Yang to this latest version.</t>
</section>
<!-- ack -->
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC6136;
<reference anchor="NVO3-framework">
<front>
<title>Framework for DC Network Virtualization</title>
<author initials="M." surname="Lasserre">
<organization>Alcatel-Lucent</organization>
</author>
<author initials="F." surname="Balus">
<organization>Alcatel-Lucent</organization>
</author>
<author initials="T." surname="Morin">
<organization>France Telecom Orange</organization>
</author>
<author initials="N." surname="Bitar">
<organization>Verizon</organization>
</author>
<author initials="Y." surname="Rekhter">
<organization>Juniper</organization>
</author>
<date month="June" year="2014"/>
</front>
</reference>
<reference anchor="NVO3-DP-Reqs">
<front>
<title>NVO3 Data Plane Requirements</title>
<author initials="N." surname="Bitar">
<organization>Verizon</organization>
</author>
<author initials="M." surname="Lasserre">
<organization>Alcatel-Lucent</organization>
</author>
<author initials="F." surname="Balus">
<organization>Alcatel-Lucent</organization>
</author>
<author initials="T." surname="Morin">
<organization>France Telecom Orange</organization>
</author>
<author initials="L." surname="Jin">
<organization>ZTE</organization>
</author>
<author initials="B." surname="Khasnabish">
<organization>ZTE</organization>
</author>
<date month="April" year="2014"/>
</front>
</reference>
<reference anchor="IEEE802.1Q-2011">
<front>
<title>IEEE Standard for Local and metropolitan area networks -
Media Access Control (MAC) Bridges and Virtual Bridged Local Area
Networks</title>
<author initials="" surname="">
<organization>IEEE</organization>
</author>
<date year="2011"/>
</front>
</reference>
<reference anchor="Y.1731">
<front>
<title>ITU-T Recommendation Y.1731 (02/08) - OAM functions and
mechanisms for Ethernet based networks</title>
<author initials="" surname="">
<organization>ITU-T</organization>
</author>
<date month="February" year="2008"/>
</front>
</reference>
<reference anchor="NM-Standards">
<front>
<title>ITU-T Recommendation M.3400 (02/2000) - TMN Management
Functions</title>
<author initials="" surname="">
<organization>ITU-T</organization>
</author>
<date month="February" year="2000"/>
</front>
</reference>
<reference anchor="I2RS-trace">
<front>
<title>Interface to the Routing System (I2RS) Traceability:
Framework and Information Model</title>
<author initials="J." surname="Clark"/>
<author initials="G." surname="Salgueiro"/>
<author initials="C." surname="Pignataro"/>
<date month="December" year="2013"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:24:58 |