One document matched: draft-ooamdt-rtgwg-ooam-requirement-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category='info' ipr='trust200902' docName='draft-ooamdt-rtgwg-ooam-requirement-00'>
<front>
<title abbrev="Overlay OAM Requirements">Overlay OAM Requirements</title>
<author initials="N." surname="Kumar" fullname="Nagendra Kumar">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709</code>
<country>US</country>
</postal>
<email>naikumar@cisco.com</email>
</address>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709-4987</code>
<country>US</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author initials="D." surname="Kumar" fullname="Deepak Kumar">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>3700 Cisco Way</street>
<city>SJ</city> <region></region> <code></code>
<country>US</country>
</postal>
<email>dekumar@cisco.com</email>
</address>
</author>
<author initials="G." surname="Mirsky" fullname="Greg Mirsky">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city></city> <region></region> <code></code>
<country></country>
</postal>
<email>gregory.mirsky@ericsson.com</email>
</address>
</author>
<author initials="M." surname="Chen" fullname="Mach Chen">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city> <region></region> <code></code>
<country></country>
</postal>
<email>mach.chen@huawei.com</email>
</address>
</author>
<author initials="E." surname="Nordmark" fullname="Eric Nordmark">
<organization>Arista Networks</organization>
<address>
<postal>
<street></street>
<city></city> <region></region> <code></code>
<country></country>
</postal>
<email>nordmark@acm.org</email>
</address>
</author>
<author initials="S." surname="Pallagatti" fullname="Santosh Pallagatti">
<organization>Juniper Networks</organization>
<address>
<postal>
<street></street>
<city></city> <region></region> <code></code>
<country></country>
</postal>
<email>santosh.pallagatti@gmail.com</email>
</address>
</author>
<author initials="D." surname="Mozes" fullname="David Mozes">
<organization>Mellanox Technologies Ltd</organization>
<address>
<postal>
<street></street>
<city></city> <region></region> <code></code>
<country></country>
</postal>
<email>davidm@mellanox.com</email>
</address>
</author>
<date />
<area>Internet</area>
<workgroup>rtgwg</workgroup>
<keyword>ooam</keyword>
<abstract><t>This document describes a list of functional requirements for Operations
Administration and Maintenance (OAM) in various Overlay and Service networks like
Service Function Chaining (SFC), Bit Index Explicit Replication (BIER), Network
Virtualization over Layer 3 (NVO3).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>We have witnessed and participated in design of new paradigms in the networking that
are aimed to address network virtualization, service function chaining, and multicast
services. New paradigms require new architectural concepts, principles and components.
<xref target="RFC7365"/> defines a framework for
Data Center Network Virtualization over Layer 3 (NVO3). <xref target="RFC7665"/> describes
the architecture for creating and maintaining Service Function Chains (SFCs) in a network.
<xref target="I-D.ietf-bier-architecture" /> defines a stateless multicast architecture for
optimal multicast packet forwarding using "Bit Index Explicit Replication" (BIER). These
frameworks are defined in a flexible manner that they are transport agnostic and may be
deployed on various underlay networks such as IPv4, IPv6 and MPLS.</t>
<t>The above mentioned new architectural concepts and principles have been combined into new
network layers with distinct encapsulation headers. For example, <xref target="I-D.ietf-sfc-nsh" /> defines an encapsulation
header as Network Service Header (NSH) to realize Service Function Path. While
<xref target="RFC7348"/> (VxLAN) and <xref target="RFC7637"/> (NVGRE) are different
encapsulation header proposed for NVO3, <xref target="I-D.ietf-nvo3-vxlan-gpe" /> extends
VxLAN further to be used for Service Function Chain (SFC). Similarly,
<xref target="I-D.ietf-bier-mpls-encapsulation" /> defines the BIER encapsulation header
over MPLS network and <xref target="I-D.xu-bier-encapsulation" /> describes the
BIER encapsulation header over IP network.</t>
<t>Introduction of the new Overlay networks, sets forth new
Operations, Administration and Maintenance (OAM) requirements that can be addressed by enhancing
the existing toolset or developing new protocols. For example, <xref target="I-D.ietf-sfc-oam-framework" />
defines the framework for SFC OAM,
<xref target="I-D.nordmark-nvo3-transcending-traceroute" /> proposes a way to perform traceroute in NVO3
networks and <xref target="I-D.kumarzheng-bier-ping" /> proposes on-demand connectivity verification
and fault isolation procedure (Ping and Trace) on BIER network.
</t>
<t>The goal of this document is to identify and list the
OAM requirements commonly applicable to new Overlay networks which can further be used to
analyze the existing OAM tools. The identified gaps can be addressed, either
through enhancing existing OAM tools and if necessary, constructing new OAM tools, that can
be used as a common unified OAM toolset to support and perform various OAM functions
including proactive and on-demand path monitoring
and service validation on the new Overlay network.</t>
</section>
<section title="Requirements notation">
<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="Terminology">
<t>ECMP: Equal Cost Multipath</t>
<t>UCMP: Unequal Cost Multipath</t>
<t>SFC: Service Function Chaining</t>
<t>BIER: Bit Index Explicit Replication</t>
<t>NVO3: Network Virtualization over L3</t>
<t>OAM: Operations, Administration and Maintenance</t>
<t>MPLS: Multiprotocol Label Switching</t>
<t>VxLAN: Virtual Extensible Local Area Network</t>
<t>NVGRE: Network Virtualization Using Generic Routing Encapsulation</t>
</section>
<section title="Detailed Requirement List">
<t>This section list the OAM requirement for different Overlay networks. The below listed requirement MUST be supported with any underlay transport network:
<list counter="req_count" hangIndent="9" style="format REQ#%d:">
<t>The listed requirements MUST be supported with any type of transport layer over which the overlay network can be realized</t>
<t>It MUST be possible to initialize Overlay OAM session from any node in the overlay network.</t>
<t>It SHOULD be possible to initialize an Overlay OAM session from a centralized controller.</t>
<t>Overlay OAM MUST support proactive and on-demand OAM monitoring and measurement methods.</t>
<t>Overlay OAM MUST support unidirectional OAM methods, both continuity check and performance measurement.</t>
<t>Overlay OAM packets SHOULD be fate sharing with data traffic, i.e. in-band with the monitored traffic, i.e. follow exactly the same path as data plane traffic, in forward direction, i.e. from ingress toward egress end point(s) of the OAM test session.</t>
<t>Overlay OAM MUST support bi-directional OAM methods. Such OAM methods MAY combine in-band monitoring or measurement in forward direction and out-of-band notification in the reverse direction, i.e. from egress to ingress end point of the OAM test session.</t>
</list>
</t>
<section title="Fault Management">
<section title="Pro-active Fault Management">
<t>Availability, not as performance metric, is understood as ability to reach the node, i.e. the fact that path between ingress and egress does exist. Such OAM mechanism also referred as Continuity Check.
<list counter="req_count" hangIndent="9" style="format REQ#%d:">
<t>Overlay OAM MUST support pro-active monitoring of any virtual node availability in the given overlay network. </t>
<t>Overlay OAM MUST support Reverse Defect Indication (RDI) notification by egress to the ingress, i.e. source of continuity checking.</t>
<t>Overlay OAM MUST support connectivity verification. Definition of mis-connectivity defect entry and exit criteria are outside the scope of this document.</t>
</list>
</t>
</section>
<section title="On-demand Fault Management">
<t>
<list counter="req_count" hangIndent="9" style="format REQ#%d:">
<t>Overlay OAM MUST support fault localization of Loss of Continuity check.</t>
<t>Overlay OAM MUST support tracing path in overlay network through the virtual nodes.</t>
<t>Overlay OAM MAY support verification of the mapping between its data plane state and client layer services.</t>
<t>Overlay OAM MUST have the ability to discover and exercise equal cost multipath (ECMP) paths in its transport network.</t>
<t>Overlay OAM MUST be able to trigger on-demand FM with responses being directed towards initiator of such proxy request.</t>
</list>
</t>
</section>
</section>
<section title="Performance Management">
<t>
<list counter="req_count" hangIndent="9" style="format REQ#%d:">
<t>Overlay OAM MUST support active one-way packet delay measurement.</t>
<t>Overlay OAM MUST support passive one-way packet delay measurement.</t>
<t>Overlay OAM MUST support active two-way packet delay measurement.</t>
<t>Overlay OAM MUST support packet delay variation measurement.</t>
<t>Overlay OAM MUST support active end to end packet loss measurement.</t>
<t>Overlay OAM MUST support passive end to end packet loss measurement.</t>
<t>Overlay OAM SHOULD support active per-segment packet delay measurement.</t>
<t>Overlay OAM SHOULD support passive per-segment packet delay measurement.</t>
<t>Overlay OAM SHOULD support active per-segment packet loss measurement.</t>
<t>Overlay OAM SHOULD support passive per-segment packet loss measurement.</t>
<t>Overlay OAM MUST support delivered packet throughput measurement.</t>
</list>
</t>
</section>
<section title="Alarm Indication Suppression">
<t>
<list counter="req_count" hangIndent="9" style="format REQ#%d:">
<t>Overlay OAM MUST support defect notification mechanism, like Alarm Indication Signal.</t>
<t>Any virtual node in the given overlay network MAY originate a defect notification addressed to any node in that network.</t>
</list>
</t>
</section>
<section title="Overlay Network Resiliency">
<t>
<list counter="req_count" hangIndent="9" style="format REQ#%d:">
<t>Overlay OAM MUST support methods to enable survivability of an overlay network. These recovery methods MAY use protection switching and restoration.</t>
</list>
</t>
</section>
</section>
<section title="IANA Considerations">
<t>This document does not propose any IANA consideration.</t>
</section>
<section title="Security Considerations">
<t>This document list the OAM requirement for various Overlay network and does not raise any security considerations.</t>
</section>
<section title="Acknowledgement">
<t> TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.7365"?>
<?rfc include="reference.RFC.7665"?>
<?rfc include="reference.RFC.7637"?>
<?rfc include="reference.RFC.7348"?>
<?rfc include="reference.I-D.ietf-bier-architecture"?>
<?rfc include="reference.I-D.ietf-sfc-nsh"?>
<?rfc include="reference.I-D.ietf-nvo3-vxlan-gpe"?>
<?rfc include="reference.I-D.ietf-bier-mpls-encapsulation"?>
<?rfc include="reference.I-D.xu-bier-encapsulation"?>
<?rfc include="reference.I-D.ietf-sfc-oam-framework"?>
<?rfc include="reference.I-D.nordmark-nvo3-transcending-traceroute"?>
<?rfc include="reference.I-D.kumarzheng-bier-ping"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-bier-oam-requirements"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:40:28 |