One document matched: draft-ooamdt-rtgwg-demand-cc-cv-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!--
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC4379 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4379.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
-->
<!--
<!ENTITY RFC6374 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6374.xml">
<!ENTITY RFC5880 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml">
<!ENTITY RFC5882 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5882.xml">
<!ENTITY RFC5883 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5883.xml">
<!ENTITY RFC5884 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5884.xml">
<!ENTITY RFC5885 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5885.xml">
<!ENTITY RFC7726 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7726.xml">
<!ENTITY RFC5357 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml">
<!ENTITY RFC6038 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6038.xml">
<!ENTITY RFC7750 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7750.xml">
<!ENTITY RFC6428 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6428.xml">
<!ENTITY RFC7276 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml">
<!ENTITY RFC7746 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7746.xml">
<!ENTITY RFC7594 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7594.xml">
<!ENTITY I-D.ietf-bfd-multipoint SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-bfd-multipoint-07.xml">
<!ENTITY I-D.ietf-bfd-multipoint-active-tail SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-bfd-multipoint-active-tail-01.xml">
<!ENTITY I-D.ietf-bfd-seamless-base SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-bfd-seamless-base-08.xml">
<!ENTITY I-D.ietf-bfd-seamless-ip SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-bfd-seamless-ip-03.xml">
<!ENTITY I-D.ietf-mpls-rfc6374-udp-return-path SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mpls-rfc6374-udp-return-path-04.xml">
<!ENTITY I-D.kumarzheng-bier-ping SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-kumarzheng-bier-ping-02.xml">
<!ENTITY I-D.tempia-ippm-p3m SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-tempia-ippm-p3m-03.xml">
<!ENTITY I-D.mirsky-bier-pmmm-oam SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-mirsky-bier-pmmm-oam-01.xml">
<!ENTITY I-D.lapukhov-dataplane-probe SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-lapukhov-dataplane-probe-00.xml">
<!ENTITY I-D.ashwood-nvo3-oam-requirements SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ashwood-nvo3-oam-requirements-04.xml">
<!ENTITY I-D.nordmark-nvo3-transcending-traceroute SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-nordmark-nvo3-transcending-traceroute-02.xml">
<!ENTITY I-D.saum-nvo3-pmtud-over-VXLAN SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-saum-nvo3-pmtud-over-VXLAN-02.xml">
<!ENTITY I-D.singh-nvo3-VXLAN-router-alert SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-singh-nvo3-VXLAN-router-alert-02.xml">
<!ENTITY I-D.spallagatti-bfd-VXLAN SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-spallagatti-bfd-VXLAN-02.xml">
<!ENTITY I-D.ietf-rtgwg-dt-encap SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-dt-encap-02.xml">
-->
]>
<?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="std" ipr="trust200902" docName="draft-ooamdt-rtgwg-demand-cc-cv-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev='On-demand CC/CV for Overlay Networks'>On-demand Continuity Check (CC) and Connectivity Verification(CV) for Overlay Networks</title>
<author initials='G.' surname="Mirsky" fullname='Greg Mirsky'>
<organization></organization>
<address>
<email>gregimirsky@gmail.com</email>
</address>
</author>
<author initials='E.' surname="Nordmark" fullname='Erik Nordmark'>
<organization>Arista Networks</organization>
<address>
<email>nordmark@acm.org</email>
</address>
</author>
<!--
<author initials='C.' surname="Pignataro" fullname='Carlos Pignataro'>
<organization>Cisco Systems, Inc.</organization>
<address>
<email>cpignata@cisco.com</email>
</address>
</author>
-->
<author initials='N.' surname="Kumar" fullname='Nagendra Kumar'>
<organization>Cisco Systems, Inc.</organization>
<address>
<email>naikumar@cisco.com</email>
</address>
</author>
<author initials='D.' surname="Kumar" fullname='Deepak Kumar'>
<organization>Cisco Systems, Inc.</organization>
<address>
<email>dekumar@cisco.com</email>
</address>
</author>
<author initials='M.' surname="Chen" fullname='Mach Chen'>
<organization>Huawei Technologies</organization>
<address>
<email>mach.chen@huawei.com</email>
</address>
</author>
<author initials='Y.' surname="Li" fullname='Yizhou Li'>
<organization>Huawei Technologies</organization>
<address>
<email>liyizhou@huawei.com</email>
</address>
</author>
<author initials='D.' surname="Mozes" fullname='David Mozes'>
<organization>Mellanox Technologies Ltd.</organization>
<address>
<email>davidm@mellanox.com</email>
</address>
</author>
<!--
<author initials='S' surname="Pallagatti" fullname='Santosh Pallagatti'>
<organization></organization>
<address>
<email>santosh.pallagatti@gmail.com</email>
</address>
</author>
-->
<author initials='D' surname="Dolson" fullname='David Dolson'>
<organization>Sandvine</organization>
<address>
<email>ddolson@sandvine.com</email>
</address>
</author>
<author initials='I' surname="Bagdonas" fullname='Ignas Bagdonas'>
<organization></organization>
<address>
<email>ibagdona@gmail.com</email>
</address>
</author>
<date day="24" month="October" year="2016" />
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>OAM</keyword>
<abstract>
<t>
This document defines Overlay Echo Request and Echo Reply that enable on-demand
Continuity Check, Connectivity Verification among other operations in overlay networks.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Operations, Administration, and Maintenance (OAM) toolset provides methods for fault management
and performance monitoring in each layer of the network,
in order to improve their ability to support services with guaranteed
and strict Service Level Agreements (SLAs) while reducing
operational costs.
</t>
<section title="Conventions used in this document">
<section title="Terminology">
<t>
Term "Overlay OAM" used in this document interchangeably with longer version
"set of OAM protocols, methods and tools for Overlay networks".
And "Overlay ping" is used
intercheangeably with longer version Ovelay Echo Request/Reply.
</t>
<t>CC Continuity Check </t>
<t>CV Connectivity Verification </t>
<t>FM Fault Management </t>
<!--
<t>G-ACh Generic Associated Channel </t>
-->
<t>Geneve Generic Network Virtualization Encapsulation </t>
<t>GUE Generic UDP Encapsulation </t>
<t>MPLS Multiprotocol Label Switching </t>
<t>NVO3 Network Virtualization Overlays </t>
<t>
OAM Operations, Administration, and Maintenance</t>
<t>SFC Service Function Chaining</t>
<t>SFP Service Function Path</t>
<t>VXLAN Virtual eXtensible Local Area Network</t>
<t>VXLAN-GPE Generic Protocol Extension for VXLAN</t>
</section>
<section title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119"></xref>.
</t>
</section>
</section>
</section>
<section anchor="on-demand-cc-cv" title="On-demand Continuity Check and Connectivity Verification">
<t>
The format of the Echo Request/Echo Reply control packet is to support
ping and traceroute functionality in overlay networks <xref target="ooam-ping-pic"/>
resembles the format of MPLS LSP Ping <xref target="RFC4379"/> with some exceptions.
<figure align="left" anchor="ooam-ping-pic"
title="Overlay OAM Ping format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return S.code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
The interpretation of the fields is
as following:
<list style="empty">
<t>
The Version reflects the current version. The version number is to
be incremented whenever a change is made that affects the ability of
an implementation to correctly parse or process control packet.
</t>
<t>The Global Flags is a bit vector field </t>
<t>The Message Type filed reflects the type of the packet. Value TBA2 identifies Echo Request and TBA3 - Echo Reply</t>
<t>The Reply Mode defines the type of the return path requested by the sender of the Echo Request. </t>
<t>Return Codes and Subcodes can be used to inform the sender about result of processing its request. </t>
<t>The Sender's Handle is filled in by the sender, and returned unchanged by the receiver in the Echo Reply. </t>
<t>The Sequence Number is assigned by the sender and can be (for example) used to detect missed replies. </t>
<t>TLVs (Type-Length-Value tuples) have the two octets long Type field, two
octets long Length field that is length of the Value field in octets.</t>
</list>
</t>
<section anchor="echo-request-send" title="Overlay Echo Request Transmission">
<t>
Overlay Echo Request control packet MUST use the appropriate encapsulation of the monitored
overlay network. Overlay network encpsulation MUST identify Echo Request as OAM packet.
Overlay encapsulation uses different methods to identify OAM payload <xref target="I-D.ietf-nvo3-vxlan-gpe"/>,
<xref target="I-D.ietf-nvo3-gue"/>, <xref target="I-D.ietf-nvo3-geneve"/>,
<xref target="I-D.ietf-sfc-nsh"/>,<xref target="I-D.ietf-bier-mpls-encapsulation"/>. Overlay network's header MUST
be immediately followed by the Overlay OAM Header <xref target="I-D.ooamdt-rtgwg-ooam-header"/>. Message Type field
in the Overlay OAM Header MUST be set to Overlay Echo Request value (TBA2).
</t>
<t>
Value of the Reply Mode field MAY be set to:
<list style="symbols">
<t>
Do Not Reply (TBA4) if one-way monitoring is desired. If Echo Request is used to measure synthetic packet loss,
the receiver MAY report loss measurement results to a remote node.
</t>
<t>
Reply via an IPv4/IPv6 UDP Packet (TBA5) value likely will be the most used.
</t>
<t>
Reply via Application Level Control Channel (TBA6) value if the overlay
network MAY have bi-directional paths.
</t>
<t>
Reply via Specified Path (TBA7) value in order to enforce use of the particular
return path specified in the included TLV to verify bi-directional continuity and
also increase robustness of the monitoring by selecting more stable path.
</t>
</list>
</t>
</section>
<section anchor="echo-request-recieve" title="Overlay Echo Request Reception">
<t>
</t>
</section>
<section anchor="echo-reply-send" title="Overlay Echo Reply Transmission">
<t>
The Reply Mode field directs whether and how the Echo Reply message should be sent.
The sender of the Echo Request MAY use TLVs to request that corresponding Echo Reply
be sent using the specified path. Value TBA3 is referred as "Do not reply" mode and
suppresses transmission of Echo Reply packet. Default value (TBA5) for the Reply mode field requests
the responder to send the Echo Reply packet out-of-band as IPv4 or IPv6 UDP packet.
[Selection of destination and source IP addresses and UDP port numbers to be provided in the next update.]
</t>
</section>
<section anchor="echo-reply-recieve" title="Overlay Echo Reply Reception">
<t>
</t>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<section anchor="iana-overlay-echo-type" title="Overlay Echo Request/Echo Reply Type">
<t>
IANA
is requested to assign new type from the Overlay OAM Protocol Types registry as follows:
</t>
<texttable anchor="iana-overlay-echo-tbl" title="Overlay Echo Request/Echo Reply Type">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>TBA1</c>
<c>Overlay Echo Request/Echo Reply</c>
<c>This document</c>
</texttable>
</section>
<section anchor="iana-overlay-ping-parameters" title="Overlay Ping Parameters">
<t>
IANA
is requested to create new Overlay Echo Request/Echo Reply Parameters registry.
</t>
</section>
<section anchor="iana-overlay-echo-mesasage-type" title="Overlay Echo Request/Echo Reply Message Types">
<t>
IANA
is requested to create in the Overlay Echo Request/Echo Reply
Parameters registry the new sub-registry Message Types.
All code points in the range 1 through 191 in this registry shall be allocated
according to the "IETF Review" procedure as specified in <xref target="RFC5226"/>
and assign values as follows:
</t>
<texttable anchor="iana-overlay-echo-message-type-tbl" title="Overlay Echo Request/Echo Reply Message Types">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c></c>
<c>TBA2</c>
<c>Overlay Echo Request</c>
<c>This document</c>
<c>TBA3</c>
<c>Overlay Echo Reply</c>
<c>This document</c>
<c>TBA3+1-191</c>
<c>Unassigned</c>
<c>IETF Review</c>
<c>192-251</c>
<c>Unassigned</c>
<c>First Come First Served</c>
<c>252-254</c>
<c>Unassigned</c>
<c>Private Use</c>
<c>255</c>
<c>Reserved</c>
<c></c>
</texttable>
</section>
<section anchor="iana-overlay-ping-reply-mode" title="Overlay Echo Reply Modes">
<t>
IANA
is requested to create in the Overlay Echo Request/Echo Reply
Parameters registry the new sub-registry Reply Modes
All code points in the range 1 through 191 in this registry shall be allocated
according to the "IETF Review" procedure as specified in <xref target="RFC5226"/>
and assign values as follows:
</t>
<texttable anchor="iana-overlay-ping-reply-mode-tbl" title="Overlay Echo Reply Modes">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c></c>
<c>TBA4</c>
<c>Do Not Reply</c>
<c>This document</c>
<c>TBA5</c>
<c>Reply via an IPv4/IPv6 UDP Packet</c>
<c>This document</c>
<c>TBA6</c>
<c>Reply via Application Level Control Channel</c>
<c>This document</c>
<c>TBA7</c>
<c>Reply via Specified Path</c>
<c>This document</c>
<c>TBA7+1-191</c>
<c>Unassigned</c>
<c>IETF Review</c>
<c>192-251</c>
<c>Unassigned</c>
<c>First Come First Served</c>
<c>252-254</c>
<c>Unassigned</c>
<c>Private Use</c>
<c>255</c>
<c>Reserved</c>
<c></c>
</texttable>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>
Overlay EchoRequest/Replay operates withing the domain of the overlay network and thus inherits
any security considerations that apply to the use of that overlay technology and, consequently, underlay data plane.
Also, the security needs for Overlay Echo Request/Reply are similar to those of ICMP ping <xref target="RFC0792"/>, <xref target="RFC4443"/>
and MPLS LSP ping <xref target="I-D.ietf-mpls-rfc4379bis"/>.
</t>
<t>
There are at least three approaches of attacking a node in the overlay network using the
mechanisms defined in the document. One is a Denial-of-Service attack, by
sending Overlay ping to overload a node in the overlay network.
The second may use spoofing, hijacking, replaying, or otherwise
tampering with Overlay Echo Requests and/or Replies to
misrepresent, alter operator's view of the state of the overlay
network. The third is an unauthorized source using an Overlay
Echo Request/Reply to obtain information about the
overlay and/or underlay network.
</t>
<t>
To mitigate potential Denial-of-Service attacks, it is RECOMMENDED that
implementations throttle the Overlay ping traffic going to the control
plane.
</t>
<t>
Replay and spoofing attacks involving faking or
replaying Overlay Echo Reply messages would have to
match the Sender's Handle and Sequence Number of
an outstanding Overlay Echo Request message which is highl unlikely.
Thus the non-matching replay would be discarded. But since "even a broken clock is right twice a day"
implementions MAY use Timestamp control block <xref target="I-D.ooamdt-rtgwg-ooam-header"/>
to validate the TimeStamp Sent by requiring an exact match on this field.
</t>
<t>
To protect against unauthorized sources trying to obtain information about the overlay and/or underlay
an implementation MAY check that the source of the Echo Request is indeed part of the overlay domain.
</t>
</section>
<section anchor="ack" title="Acknowledgement">
<t>
TBD
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!--
&RFC2119;
-->
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.I-D.ietf-nvo3-vxlan-gpe"?>
<?rfc include="reference.I-D.ietf-nvo3-gue"?>
<?rfc include="reference.I-D.ietf-nvo3-geneve"?>
<?rfc include="reference.I-D.ietf-sfc-nsh"?>
<?rfc include="reference.I-D.ietf-bier-mpls-encapsulation"?>
<?rfc include="reference.I-D.ooamdt-rtgwg-ooam-header"?>
</references>
<references title="Informative References">
<!--
&RFC4379;
&RFC5226;
-->
<?rfc include="reference.RFC.4379"?>
<?rfc include="reference.RFC.5226"?>
<?rfc include="reference.RFC.0792"?>
<?rfc include="reference.RFC.4443"?>
<?rfc include="reference.I-D.ietf-mpls-rfc4379bis"?>
<!--
&RFC6374;
&RFC5880;
&RFC5884;
&RFC5882;
&RFC5883;
&RFC5885;
&RFC6428;
&RFC7726;
&RFC5357;
&RFC6038;
&RFC7750;
&RFC7276;
&RFC7746;
&RFC7594;
&I-D.ietf-bfd-multipoint;
&I-D.ietf-bfd-multipoint-active-tail;
&I-D.ietf-bfd-seamless-base;
&I-D.ietf-bfd-seamless-ip;
&I-D.kumarzheng-bier-ping;
&I-D.ietf-mpls-rfc6374-udp-return-path;
&I-D.mirsky-bier-pmmm-oam;
&I-D.tempia-ippm-p3m;
&I-D.lapukhov-dataplane-probe;
&I-D.ashwood-nvo3-oam-requirements;
&I-D.nordmark-nvo3-transcending-traceroute;
&I-D.saum-nvo3-pmtud-over-VXLAN;
&I-D.singh-nvo3-VXLAN-router-alert;
&I-D.spallagatti-bfd-VXLAN;
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:02:20 |