<?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='std' ipr='trust200902' docName='draft-kumar-nvo3-overlay-ping-01'>

<front>
<title abbrev="Detecting NVO3 Overlay Data Plane Failures">Detecting NVO3 Overlay Data Plane failures</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="Rao" fullname="Dhananjaya Rao">
	<organization>Cisco Systems, Inc.</organization>
	<address>
		<postal>
		<street>170 W Tasman Drive</street>
		<city>San Jose</city> <region>CA</region> <code>95138</code>
		<country>US</country>
		</postal>
	<email>dhrao@cisco.com</email>
	</address>
</author>

<author initials="S." surname="Aldrin" fullname="Sam Aldrin">
	<organization>Huawei Technologies, Inc.</organization>
	<address>
		<postal>
		<street>1188 Central Express Way</street>
		<city>Santa Clara</city> <region>CA</region> <code>95051</code>
		<country>US</country>
		</postal>
	<email>aldrin.ietf@gmail.com</email>
	</address>
</author>

<date month="Jan" year="2014" />
<area>Internet</area>
<workgroup>nvo3</workgroup>

<keyword>nvo3</keyword>

		<abstract><t>This document describes a simple and efficient mechanism to perform L2 or L3 VN Context validation and to detect any data plane failures 
		in IPv4 or IPv6 based overlay network providing L2 or L3 virtualized network.</t>
		</abstract>
 
</front>

<middle>
	
	<section title="Introduction">
					<t>
					<xref target="I-D.ietf-nvo3-framework">I.D-ietf-nvo3-framework</xref> specifies a framework that defines mechanism to support large scale network 
					virtualization by connecting L2 or L3 virtualized network over L3 tunnels. Various tunneling options like
					IPv4, IPv6 or MPLS can be used in underlying network.
					</t>
					<t>
					Section 3.8 of [I.D-ietf-nvo3-dataplane-requirement] specifies the requirement of OAM tool that 
					performs connectivity verification and fault isolation along with revealing ECMP paths between NVE nodes.
					While the mechanism described in <xref target="RFC4379">RFC4379</xref> helps with satisfying this OAM requirement when MPLS tunnel is used, 
					there is no native way to achieve the same when IPv4 or IPv6 is used as tunneling option.
					</t>
					<t>
					This document describes a simple and efficient mechanism to perform L2 or L3 VN Context validation and to detect any data plane failures 
					in IPv4 or IPv6 overlay network by re-purposing and extending MPLS Ping mechanism defined in <xref target="RFC4379">RFC4379</xref>.
					This document also describes the mechanism to reveal all available paths (multi path) between any ingress and egress NVE nodes.
					</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>L2 VN: Layer 2 Virtual Network</t>
	<t>L3 VN: Layer 3 Virtual Network</t>
	<t>NVE: Network Virtualization Edge</t>
	<t>ECMP: Equal Cost multiple path</t>
	
	</section>
	<section title="Packet Format">
	<t>NVO3 PATH Ping packet is a IPv4 or IPv6 UDP packet and the basic structure of the packet remains the same as mentioned in
	  Section 3 of <xref target="RFC4379">RFC4379</xref>.</t>
	  
	<t>This document introduces a new flag in Global Flags field 
	defined in <xref target="RFC4379">RFC4379</xref>. The new format of the Global Flags field is:
	</t><figure>
						<artwork><![CDATA[

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             MBZ         |N|T|V|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	  ]]></artwork>
					</figure><t></t>
	
	<t>The V flag is described in <xref target="RFC4379">RFC4379</xref> and T flag is described in <xref target="RFC6425">RFC6425</xref>.</t>
	<t></t>
	<t>The N flag (NVO3 PATH Ping) MUST be set in echo request and reply packet only when it is used to validate NVO3 Path.</t>
	<t></t>
	<t>The Message Type is one of the following:</t>
		<figure>
				<artwork><![CDATA[
	      Value    Meaning
          -----    -------
          11    NVO3 Echo Request
          12    NVO3 Echo Reply
		  ]]></artwork> 
		</figure><t></t>
	<t>The Reply Mode can be one of the following:</t>
		<figure>
				<artwork><![CDATA[
	
		  Value    Meaning
          -----    -------
          11    Do not Reply
          12    Reply via IPv4/IPv6 UDP packet
		  ]]></artwork>
		</figure><t></t>
	<t>Return codes and Subcodes are described in section 4.1.</t>
	<t></t>
	<t>The Sender's Handle, Sequence Number, TimeStamp sent and TimeStamp Received field are as mentioned in Section 3 of <xref target="RFC4379">RFC4379</xref>.</t>
	<t></t>
	<t>The TLV format is same as mentioned in <xref target="RFC4379"></xref> and this document introduce a new TLV described later.</t>
		<section title="Return Code and Return Subcode">
		<t>Responder uses Return code field to reply with validity check or any error message to Initiator. It doesnt carry any meaning in Echo Request 
		and should be set as zero.</t>
		<t></t>
		<t>The Return Code can be one of the following:</t>
		<figure>
		<artwork><![CDATA[
	
		  Value    Meaning
          -----    -------
          100    No Return Code
          101    Malformed Echo Request Received
		  102	 One or more TLVs not understood
		  103    Egress for the Target
		  104	 No control plane mapping for the Target Object <RSC>
		  105	 Downstream Detailed Mapping mismatch
		  108	 Packet-Forward-OK
		  
		  ]]></artwork>
		</figure><t></t>
		<t>The Return Subcode contains the pointer in Target Object TLV for which the Replying node doesnt have a control plane mapping. 
		For example, when NVE receives Target Object TLV with multiple Sub-TLVs and if NVE doesnt have an entry for second Sub-TLV 
		should include 2 as RSC value.
		</t>
		</section>
		<section title="TLV Format">
		<t>The document introduces the below list of TLVs used in NVO3 Echo packets:
		</t><figure>
						<artwork><![CDATA[
           Type                   Value Field
          ------                  -----------
             101                  Target Object
			 ]]></artwork>
					</figure><t></t>
						<section title="Target Object TLV">
						<t>Target Object TLV is a list of Sub-TLVs that carries the element against which the path or control plane validation is done.
						</t>
						<t></t>
						<t>This document defines the below Target Object Sub-TLVs:</t>
						<figure>
						<artwork><![CDATA[
			Sub-Type       Length            Value Field
			--------       ------            -----------
                1            5                IPv4 prefix
                2            17               IPv6 Prefix
                3         variable            L2 VN ID
                4         variable            L3 VN ID				
			 ]]></artwork>
					</figure><t></t>
					<t>NVO3 ECHO Request MUST have a Target Object TLV with atleast one Sub-TLV which describe the egress node about the element to be validated.</t>
					<t>For example, if NVE X wanted to verify that MAC M1 is associated with VN ID VN1, it carries relevant information like VN ID and the MAC address
					in Sub-TLV type 3 and send to 
					egress NVE. Egress NVE on receiving NVO3 Echo Request will validate the Target Object and will reply back with respective Return Code.
					</t>
					<t>New Sub-TLVs can be proposed as and when required in future.</t>
						</section>
						<section title="Downstream Detailed Mapping Extension">
						<t>This document extends the Downstream Detailed Mapping TLV defined in Section 3.3 of <xref target="RFC6424">RFC6424</xref> to be used in NVO3 scenarios with IPv4 or IPv6 based core network. 
						This document introduces a new DS flag and the format is as below:</t>
						<figure>
						<artwork><![CDATA[

          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |Rsvd(MBZ)|P|I|N|
         +-+-+-+-+-+-+-+-+
		 
		       Flag  Name and Meaning
               ----  ----------------
			    P    Set when used in NVO3 Ping
	  ]]></artwork>
					</figure><t></t>
					<t>The P flag (NVO3 Path ping) MUST be set in Downstream Detailed Mapping TLV only when it is used in NVO3 scenarios. When P flag is set, I flag MUST NOT be set.</t>
					<t>For simplicity, The DDMAP with N flag set in DS flag will be referred as NVO3 DDMAP in this document.</t>
					<t>This document also defines the below new multipath types to be used in NVO3 Path ping.</t>

			<figure>
											<artwork><![CDATA[
			  Type       Meaning       Multipath information
			--------  --------------   -----------------------
                11      UDP Port Mask       UDP Port and bit mask
                12      Flow Label Mask     IPv6 Flow label and bit mask		
											]]></artwork>
										</figure><t></t>
			<t>Multipath Information
			<list><t>UDP port or IPv6 Flow label range encoded according to the Multipath type. The next section explains the encoding details.</t>
			</list></t>
			</section>
				<section title="Multipath Information Encoding">
							<t>Based on the Multipath type, the Multipath Information encodes Flow label range or UDP port range that will excercise each path.
							The Multipath encoding follows the same procedure specifies in Section 3.3.1 of <xref target="RFC4379">RFC4379</xref>. For completeness, it is explained in this
							document with UDP port range and IPv6 FLow label range.
							</t>
							<t>Multipath type 1 encodes UDP port range. The UDP prefix is formatted as a base UDP port value with non-prefix low-order 
							bits set to zero. Since the UDp port is 16 bits, the leading 16 bits are set as zeros. The maximum prefix (including leading zeros) 
							length can be 27. Following the prefix is a mask of length 
							2^(32-prefix-length) bits. Each bit set to one represents a valid UDP port. UDP port values of all the odd numbers between
							32704 and 3267 would be encoded as below:</t>
							<figure>
									<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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
								]]></artwork>
								</figure>
								<t>Multipath type 2 encoded IPv6 Fow label range. The formatting is as mentioned above for UDP port range except that the 
								leading zeros are set for leading 8 bits.
								</t>
								<t>If the received Multipath Information is non-null, the UDP ports or IPv6 Flow labels MUST be picked from the set provided. 
								if the range in received set cannot be mapped to a particular downstream interface, the type MUST be set to 0 for that interface 
								while replying. If the received Multipath type is null, the type MUST be set to 0 while replying.
								</t>
							</section>
								
								</section>
					
						</section>

		<section title="NVO3 Echo Packet Indicator">
		<t>Unlike MPLS LSP Echo, the IP destination address in NVO3 Echo packet will be the actual destination of egress node and this raises 
		a need to have an OAM indicator that can be used by transit nodes to differentiate between NVO3 Echo packet and data packet. This document 
		explains the same as below:</t>
		<section title="When the core is IPv6 network">
		<t>This document proposes the below IPv6 Extension header and the format is as below:</t>
		<figure>
									<artwork><![CDATA[
		
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |R|R|R|R|R|R|R|R|R|R|R|R|R|R|R|N|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                                                               |
    .                            Sub-TLVs                           .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
										</figure><t></t>
		<t>N flag
		<list>
		<t>NVO3 OAM Indicator</t>
		</list></t>
		<t>Any node on initiating NVO3 Echo Request MUST include IPv6 OAM Extension Header with NVO3 OAM flag set. Any node on replying 
		back with NVO3 Echo Reply MUST include IPv6 OAM Extension Header with NVO3 OAM flag set. Any transit node on receiving IPv6 destinated packet with 
		TTL=1 SHOULD interpret the payload as NVO3 ECHO packet if IPv6 OAM Extension header is present.
		</t>
		</section>
		<section title="When the core is IPv4 network">
		<t>Any transit node on receiving IPv4 destinated packet with TTL=1 SHOULD interpret the payload as NVO3 ECHO packet if UDP port is 3503.
		</t>
		</section>
		</section>
	<section title="Theory of Operation">
	<t>NVO3 Echo Request and Reply packet are UDP packet with destination port as 3503. This section describes the procedure 
	in Initiating and responding nodes.
		</t>
		<section title="Sending NVO3 Echo Request">
		<t>Initiator MUST include the respective Sub-TLV for the target(s) to be validated (L2 or L3 VNI or NVE address) in Target Object TLV. It also MUST set 
		the N flag in Global Flags (Section 4) and set the message type as 11. The Reply mode is set to the desired mode ( type 11 or 12); Return code and 
		Return Subcode are set to zero. The Sender's Handle and Sequence number are set by Initiator.
		</t>
		<t>The source UDP port can be choosen by the Initiator and the destination UDP port is set to 3503.
		The IP header is set as follows: the source IP address is a routable address of the sender; the destination IP address
		is the target egress NVE address. When the core is IPv6 network, Initiator MUST include IPv6 OAM Extension header.
		</t>
		<t>In ping mode (Connectivity check), the IP TTL is set to 255. In traceroute mode (Fault isolation), the IP TTL is set 
		successively from 1 and MUST stop sending the Request if it receives a reply with Return code 103 or 104.
		</t>
		</section>
		
		<section title="Receiving NVO3 Echo Request">
		<t>Sending an NVO3 Echo Request to control plane for payload processsing is done by IP TTL expiration in case of IPv4 and a combination of 
		IP TTL expiration and IPv6 OAM Extension header incase of IPv6. The control plane further identifies it as NVO3 Echo packet by a combination 
		of UDP destion port 3503 and N flag in Global flag field (Section 4).
		</t>
		<t>Any node on receiving NVO3 Echo Request MUST send Echo Reply with Return code "Malformed Echo Request received" to Initiator if 
		the packet fails sanity check. If the sanity check for NVO3 Echo Request is fine, Any node should store the below temporary variables:</t>
		<t>
		<list style="symbols">
		<t>Interface-I: Interface over which Echo Request is received.</t>
		<t>Address-A: Local address on Interface-I.</t>
		<t>Index-I: Interface Index for upstream node interface connected to Interface-I.</t>
		<t>Destination-D: Destination address of the NVO3 Echo Request.</t>
		</list></t>
		<t></t>
			<section title="Transit Node procedure">
				<t>Any transit node on receiving NVO3 Echo Request should perform the below:
				</t>
				<t><list style="numbers">
					<t>Transit node MUST only check the first (or top) Sub-TLV and MUST NOT iterate to other Sub-TLVs beneath. Ideally the first Sub-TLV 
					will be IPv4 prefix or IPv6 prefix Sub-TLV on which the transit node is required to act upon. It MUST set the Return code as "One or more TLVs not understood" if the first (or top) 
					Sub-TLV in Target Object TLV is not understood.</t>
					<t>If the TLV is understood, Tranit node MUST perform longest match lookup in its local forwarding table and set the Return code as "Replying node has no control plane mapping for 
					the Target Object" and Return Subcode as 1, if there is no matching entry for the prefix in Sub-TLV in its local forwarding table.</t>
					<t>If the received NVO3 Echo Request has NVO3 Downstream Detailed Mapping TLV MUST set the Return code as "Downstream Detailed Mapping mismatch" if any of the below fails:
						<list style="symbols">
							<t>When Address Type is 1, Address-A SHOULD match Downstream Interface Index and Router ID or Address-A SHOULD match Downstream Address.</t>
							<t>When Address Type is 2 or 4, Index-I SHOULD match Downstream Interface Index and Router ID SHOULD match Downstream Address.</t>
							<t>When Address Type is 3, Address-A SHOULD match Downstream Interface Index and Router ID SHOULD match Downstream Address.</t>
						</list></t>
						<t>If the IP prefix in Sub-TLV matches any entry in local forwarding table and if step 4 satisfies the received NVO3 DDMAP or if there is no NVO3 
						DDMAP received in Echo Request, Transit node MUST set the Return code as "Packet-Forward-OK" and set DDMAP field for each 
						available multipath egress interface in forwarding table.</t>
					<t>If the received NVO3 Echo Request has Multipath information sub-TLV in NVO3 DDMAP, Transit node MUST reply as mentioned section 5.5.</t>
				</list></t>
			</section>
			<section title="Edge Node procedure">
			<t>Any Edge node (NVE) on receiving NVO3 Echo Request should perform the below:
			</t>
			<t><list style="numbers">
			<t>If the sanity check is fine, NVE MUST check all the Sub-TLVs and MUST set the Return code as "One or more TLVs not understood" if any of the TLV is not understood.</t>
			<t>If the TLVs are understood, NVE node MUST send Echo Reply with Return code "Replying node has no control plane mapping for the Target Object" and 
			Return Subcode as 1, if there is no matching entry in local forwarding table to take a forwarding decision.</t>
			<t>NVE node MUST set the Return code as "Replying node is the egress for the Target" if the IP address in first (or top) Sub-TLV in Target 
			Object TLV is locally configured to this node and there is no further sub-TLV in Target Object TLV</t>
			<t>If the Target Object TLV have more than one Sub-TLV, NVE MUST validate all the Sub-TLVs and set the Return code as "Replying node has no 
			control plane mapping for the Target Object" and Return Subcode as pointer of the Sub-TLV which fails the validation.</t>
			<t>If the received Echo Request has NVO3 Downstream Detailed Mapping TLV MUST check as mentioned in step 4 of section 6.2.1.</t>
			<t>If the validation for all Sub-TLVs in Target Object TLV is fine, NVE MUST set Return code as "Replying node is the egress for the 
			Target" and SHOULD NOT include NVO3 DDMAP.</t>
			</list></t>
			</section>
		</section>
		<section title="Sending NVO3 Echo Reply">
		<t>NVO3 Echo Reply is a UDP packet and MUST be sent only in response to received NVO3 Echo Request. The format of NVO3 Echo Reply is 
		same as Echo request.</t>
		<t>Responder MUST fill the DDMAP field, Return Code and Return Subcode from previous section. It MUST also set the N flag in Global 
		Flags and set the message type as 12. The Sender's Handle, Sequence Number field MUST be copied from the received Echo Request.</t>
		<t>The source UDP port is set to 3503 and the source UDP port of received Echo Request is copied to destination UDP port of Echo Reply.
		The IP header is set as follows: the source IP address is a routable address of the responder; the destination IP address is coped from 
		source address of Echo Request and IP TTL is set to 255. When the core is IPv6 network, Responder MUST include IPv6 OAM Extension Header.</t>
	
		</section>
		<section title="Receiving NVO3 Echo Reply">
		<t>Any node should receive NVO3 Echo Reply only in response to an NVO3 Echo Request that it sent. Initiator MUST drop the packet 
		if it fails sanity check. If the sanity check is fine, the Echo Reply should be mapped with the respective Echo Request using 
		the destination port and Sender's Handle. if there is no match, the Echo Reply MUST be ignored. Else, it checks the Sequence 
		Number to match the iteration.</t>
		<t>In traceroute mode, If the Echo Reply contains NVO3 DDMAP, it SHOULD copy the same to subsequent Echo Request(s).</t>
		</section>
		<section title="Dealing with Equal-Cost-Multi-Path (ECMP)">
		<t>For redundancy and load balancing purpose, It is common to see multiple equal cost paths between ingress and egress NVE and it is a local matter 
		to transit node to decide the egress interface based on local hashing algorithm. It is common to see deployment with routers that support 
		load-balancing based on UDP ports or based on IPv6 Flow label. So it is useful to have the OAM tool to exercise all possible paths between ingress
		and egress NVEs. 
		</t>
		<t>This can be achieved using Multipath Information Sub-TLV in NVO3 DDMAP. This can be used as follows:</t>
		<t><list style="symbols">
		<t>When the core is IPv6 network, the Initiator will send Echo Request in traceroute mode (start with TTL as 1 and increment 
		for subsequent message) with Multipath type set to 2. Any transit node will include multipath encoding for each downstream interface in a way that the 
		local hashing decision based on IPv6 flow label will use the respective downstream path. Initiator will then send NVO3 Echo Request with respective 
		Flow label to excercise these paths.</t>
		<t>When the core is Ipv4 network, the Initiator will send Echo Request in traceroute mode with Multipath type set to 1. Any transit node will include 
		multipath encoding for each downstream interface in a way that local hashing decision based on UDP port will use the respective downstream path. initiator will 
		then send NVO3 Echo Request with respective UDP port as source port to excercise these paths.</t>
		</list></t>
		</section>
	</section>
	
		<section title="Connectivity verification between Tenant system">
		<t>As like other overlay ping mechanism, the approach discussed in this document
		will help with connectivity verification between NVE nodes and control plane validation
		on NVE nodes.
		</t>
		<t>Any dataplane programming corruption for VN context details in NVE nodes will be in
		different layer and may need end-to-end connectivity verification procedures.
		</t>
		</section>
		<section title="IANA Considerations">
		<t>This document reuse UDP port 3503 for NVO3 Echo packets.</t>
		<section title="Message Types, Reply Modes, Return Codes">
		<t>This document request to assign the Message Types and Reply mode mentioned in Section 4 and Return code mentioned in Section 4.1</t>
		</section>
		<section title="TLVs">
		<t>The TLVs and Sub-TLVs requested by this document for IANA consideration are the following:</t>
				<figure>
									<artwork><![CDATA[
	       Type        Sub-Type            Value Field
	      -------      --------            -----------
            101                             Target Object
                           1                IPv4 Prefix
                           2                IPv6 Prefix
                           3                L2 VN ID
                           4                L3 VN ID
]]></artwork>
										</figure><t></t>
		</section>
		</section>
        <section title="Security Considerations">
		<t>The security consideration for NVO3 Ping is similar to ICMP or LSP Ping. AS like ICMP or LSP ping, 
		NVO3 may be exposed to Denial-of-service attacks and it is RECOMMENDED to regulate the NVO3 Ping packet 
		flow to control plane. A rate limiter SHOULD be applied to avoid any attack</t>
		<t>As like ICMP or LSP Ping, a traceroute can be used to obtain network information. It is RECOMMENDED 
		that the implementation check the source address of the Echo messages against any local secured list 
		like access list before processing the message further </t>
        </section>
		<section title="Acknowledgement">
					<t>The authors would like to thank Lizhong Jin for his review and comments.</t>
		</section>
    </middle>
	
<back>

    <references title="Normative References">
	
	<?rfc include="reference.RFC.4379"?>
	
    <?rfc include="reference.RFC.6424"?>

    <?rfc include="reference.RFC.6425"?>
	
	<?rfc include="reference.RFC.2119"?>
	
	<?rfc include="reference.I-D.ietf-nvo3-framework"?>

	  
    </references>

	 <references title="Informative References">
      <?rfc include="reference.RFC.3031"?>
	  
    </references>

		</back>

</rfc>
