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 protected] ---------------------------------------------------- _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
