Subject: [nvo3] NVO3 architecture draft - proposed OAM text

From: "Black, David" <[email-masked]>
Date: Thu, 11 Aug 2016 21:45:29 +0000

With many thanks to Greg Mirsky and Carlos Pignataro for their help,
here's proposed new OAM text for draft-ietf-nvo3-arch-06.   This is
a complete replacement for section 12 of the -06 draft, including
changing the name of the section.

As part of this activity, the correct -ashwood- draft to refer to was located, 
draft-ashwood-nvo3-oam-requirements-04, which is a current draft.
Beyond that, [M.3400] is an ITU-T recommendation, and the rest of
the citations in the new OAM text should be clear.

Comments are welcome, but *please* propose new text if you want
something changed.  I plan to post a -07 version sometime next week
with the new OAM text, plus all other changes resulting from IETF
Last Call (which ends tomorrow).

12.  Operations, Administration and Maintenance (OAM)

   The simplicity of operating and debugging overlay networks will be
   critical for successful deployment.

   Overlay networks are based on tunnels between NVEs, so the OAM
   (Operations, Administration and Maintenance) [RFC6291] framework for
   overlay networks can draw from prior IETF OAM work for tunnel-based
   networks, specifically L2VPN OAM [RFC6136].  RFC 6136 focuses on
   Fault Management and Performance Management as fundamental to L2VPN
   service delivery, leaving the Configuration, Management, Accounting
   Management and Security Management components of the OSI "FCAPS"
   taxonomy [M.3400] for further study.  This section does likewise for
   NVO3 OAM, but those three areas continue to be important parts of
   complete OAM functionality for NVO3.

   As is the case for L2VPN, there is a client/server relationship
   between the overlay and underlay networks that is a consideration for
   fault and performance management - a fault in the underlay may
   manifest as fault and/or performance issues in the overlay.
   Diagnosing and fixing such issues are complicated by NVO3 abstracting
   the underlay network away from the overlay network (e.g.,
   intermediate nodes on the underlay network path between NVEs are
   hidden from overlay VNs).

   NVO3-specific OAM techniques, protocol constructs and tools are
   needed to provide visibility beyond this abstraction to diagnose and
   correct problems that appear in the overlay.  Two examples are
   underlay-aware traceroute
   [I-D.nordmark-nvo3-transcending-traceroute], and ping protocol
   constructs for overlay networks [I-D.jain-nvo3-vxlan-ping]
   [I-D.kumar-nvo3-overlay-ping].

   NVO3-specific tools and techniques are best viewed as complements to
   (i.e., not as replacements for) single-network tools that apply to
   the overlay or underlay network.  There is a resulting need for
   coordination among the tools for each individual network (overlay,
   underlay) and the NVO3-aware dual-network tools in order to achieve
   effective monitoring and fault diagnosis.  For example, the defect
   detection intervals and performance measurement intervals ought to be
   coordinated among all the tools involved in order to provide
   consistency and comparability of results.

   For further discussion of NVO3 OAM requirements, see
   [I-D.ashwood-nvo3-oam-requirements].

Thanks, --David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953     Cell: +1 (978) 394-7754
[email-masked]        
----------------------------------------------------