Internet DRAFT - draft-jain-nvo3-vxlan-ping

draft-jain-nvo3-vxlan-ping






NVO3                                                             P. Jain
Internet-Draft                                                  K. Singh
Intended status: Standards Track                                F. Balus
Expires: December 8, 2013                                 Nuage Networks
                                                           W. Henderickx
                                                          Alcatel-Lucent
                                                               V. Bannai
                                                                  PayPal
                                                           June 06, 2013


                    Detecting VXLAN Segment Failure
                     draft-jain-nvo3-vxlan-ping-00

Abstract

   This proposal describes a mechanism that can be used to detect Data
   Path Failures and sanity of VXLAN Control and Data Plane for a given
   VXLAN Segment.  This document defines the following:

   o  Information carried in a VXLAN "Echo Request", and

   o  "Echo Reply" for the purposes of fault detection and isolation,
      and mechanisms for reliably sending the Echo Request and reply.


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 8, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Jain, et al.            Expires December 8, 2013                [Page 1]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Need for VXLAN Ping  . . . . . . . . . . . . . . . . . . . . .  6

   4.  Packet Format  . . . . . . . . . . . . . . . . . . . . . . . .  8

   5.  Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . 11

   6.  Procedure for VXLAN Ping . . . . . . . . . . . . . . . . . . . 12
     6.1.  Sending VXLAN Echo Request . . . . . . . . . . . . . . . . 12
     6.2.  Receiving VXLAN Echo Request . . . . . . . . . . . . . . . 13
     6.3.  Sending VXLAN Echo Reply . . . . . . . . . . . . . . . . . 13
     6.4.  Receiving VXLAN Echo Reply . . . . . . . . . . . . . . . . 14

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15

   8.  Management Considerations  . . . . . . . . . . . . . . . . . . 16

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17

   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     11.2. Informative References . . . . . . . . . . . . . . . . . . 19

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20









Jain, et al.            Expires December 8, 2013                [Page 2]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


   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 RFC2119 [RFC2119].

   When used in lower case, these words convey their typical use in
   common language, and are not to be interpreted as described in
   RFC2119 [RFC2119].












































Jain, et al.            Expires December 8, 2013                [Page 3]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


1.  Introduction

   VXLAN [I-D.draft-mahalingam-dutt-dcops-vxlan]is a tunneling mechanism
   to overlay Layer 2 networks on top of Layer 3 networks.  In most
   cases the end point of the tunnel (VTEP) is intended to be at the
   edge of the network, typically connecting an access switch to an IP
   transport network.  The access switch could be a physical or a
   virtual switch located within the hypervisor on the server which is
   connected to End System which is a VM.

   This document describes a mechanism that can be used to detect Data
   Plane failures and sanity of VXLAN Control and Data Plane for a given
   VXLAN Segment.

   There proposal describes:

   o  Information carried in VXLAN "Echo Request",

   o  Information carried in VXLAN "Echo Reply", and

   o  the mechanism to transport the "Echo Request" and "Echo Reply".

   The proposal defines the information to check correct operation of
   the Data Plane, as well as a mechanism to verify the Data Plane
   against the Control Plane for a given VXLAN Segment.

   Its is important consideration in this proposal to carry VXLAN Echo
   Request along same data path that normal VXLAN Packets would
   traverse.

   The tenants VM(s) are not aware of the Virtualization Overlays and as
   such the need for the verification of the Data Path MUST solely rest
   with the Cloud Provider.  The use cases where the Tenant VM(s) need
   to be aware of the Data Plane failures is beyond the scope of this
   document.
















Jain, et al.            Expires December 8, 2013                [Page 4]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


2.  Terminology

   Terminology used in this document:

   VXLAN: Virtual eXtensible Local Area Network.

   VTEP: VXLAN Tunnel End Point.

   VM: Virtual Machine.

   VNI: VXLAN Network Identifier (or VXLAN Segment ID)

   NVE: Network Virtulalized Edge

   End System: Could be VM etc. - System whose data is expected to go
   over VXLAN Segment.

   Other terminologies are as defined in
   [I-D.draft-mahalingam-dutt-dcops-vxlan].
































Jain, et al.            Expires December 8, 2013                [Page 5]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


3.  Need for VXLAN Ping

   When a VXLAN Segment fails to deliver user traffic, there is a need
   to provide a tool that would enable users, as Cloud Providers to
   detect such failures, and a mechanism to isolate faults.  It may also
   be desirable to test the data path before mapping End System traffic
   to the VXLAN Segment.

   The basic idea is to facilitate following verifications:-

   o  Packets that are expected to go over a particular VXLAN Segment
      actually ends up going over the correct VXLAN Segment to the
      correct VXLAN Terminating VTEP.

   o  To verify the correct value of VXLAN VN-ID is programmed at
      Originating and Terminating VXLAN VTEP(s) for a given VXLAN
      Segment.

   To facilitate verification of the above requirements, this document
   proposes sending of a Packet (called an "VXLAN Echo Request") along
   the same data path as other Packets belonging to this Segment.  VXLAN
   Echo Request also carries information about the VXLAN Segment whose
   Data Path is to be verified.  This Echo Request is forwarded just
   like any other End System Data Packet belonging to that VXLAN
   Segment, as it contains the same VXLAN Encapsulation as regular End
   System's data which uses the given VXLAN Segment.

   On receiving VXLAN Echo Request at the end of the VXLAN Segment, it
   is sent to the Control Plane of the Terminating VTEP, which in-turn
   would respond with VXLAN Echo Reply.


                          +------- L3 Network ------+
                          |                         |
                          |       Tunnel Overlay    |
             +------------+---------+       +---------+------------+
             | +----------+-------+ |       | +---------+--------+ |
             | |  Overlay Module  | |       | |  Overlay Module  | |
        NVE1 | |   +-----------+  | |       | |   +-----------+  | | NVE2
             | |   | OAM Module|  | |       | |   | OAM Module|  | |
             | |   +-----------+  | |       | |   +-----------+  | |
             | +------------------+ |       | +------------------+ |
             +----+------------+----+       +----+-----------+-----+
                  |            |                 |           |
           -------+------------+-----------------+-----------+-------
                  |            |                 |           |
                  |            |                 |           |
                 Tenant Systems                 Tenant Systems



Jain, et al.            Expires December 8, 2013                [Page 6]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


                                                                   Fig 1

   As depicted in Fig 1, VXLAN OAM Module SHOULD reside at NVE device
   and Echo Request and Reply SHOULD be handled at the NVE.















































Jain, et al.            Expires December 8, 2013                [Page 7]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


4.  Packet Format

   VXLAN Echo Request/Reply is a IPv4 UDP Packet.  Following is the
   format of VXLAN Echo Packet:



        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Message Type |   Reply mode  |  Return Code  | Return Subcode|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Originator Handle                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Sequence Number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    TimeStamp Sent (seconds)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  TimeStamp Sent (microseconds)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  TimeStamp Received (seconds)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                TimeStamp Received (microseconds)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            TLVs ...                           |
       .                                                               .
       .                                                               .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                The Message Type is one of the following:-

                         Value What it means
                         ----- ------------------
                         1     VXLAN Echo Request

                         2     VXLAN Echo Reply












Jain, et al.            Expires December 8, 2013                [Page 8]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


                            Reply Mode Values:-

                  Value What it means
                  ----- ---------------------------------
                  1     Do not reply

                  2     Reply via an IPv4/IPv6 UDP Packet

   VXLAN Echo Request with 1 (Do not reply) in the Reply Mode field may
   be used for one-way connectivity tests; the receiving node may log
   gaps in the Sequence Numbers and/or maintain delay/jitter statistics.
   For normal operation VXLAN Echo Request would have 2 (Reply via an
   IPv4 UDP Packet) in the Reply Mode field.

   The Originator's Handle is filled in by the Originator, and returned
   unchanged by the receiver in the Echo Reply (if any).  There value
   used for this field can be implementation dependent, this MAY be used
   by the Originator for matching up requests with replies.

   The Sequence Number is assigned by the sender of the VXLAN echo
   request and can be (for example) used to detect missed replies.

   The TimeStamp Sent is the time-of-day (in seconds and microseconds,
   according to the sender's clock) in NTP format [NTP] when the VXLAN
   Echo Request is sent.  The TimeStamp Received in an Echo Reply is the
   time-of-day (according to the receiver's clock) in NTP format that
   the corresponding Echo Request was received.

   TLVs (Type-Length-Value tuples) have the following format:


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Value                             |
       .                                                               .
       .                                                               .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Types are defined below; Length is the length of the Value field in
   octets.  The Value field depends on the Type; it is zero padded to
   align to a 4-octet boundary.




Jain, et al.            Expires December 8, 2013                [Page 9]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


   Example of the TLV for VXLAN ping is as follows.


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type = 1 (VXLAN ping)    |          Length                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          VXLAN VNI                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     IPv4 Sender Address                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        TLV if Sender Address is IPv4

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type = 1 (VXLAN ping)    |          Length                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          VXLAN VNI                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                     IPv6 Sender Address                       |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                            TLV if Sender Address is IPv6




















Jain, et al.            Expires December 8, 2013               [Page 10]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


5.  Return Codes

   Sender MUST always set the Return Code set to zero.  The receiver can
   set it to one of the values listed below when replying back to Echo-
   Request.

               Following are the Return Codes (Suggested):-

                   Value What it means
                   ----- -------------------------------
                   0     No return code

                   1     Malformed Echo Request Received

                   2     No VN-ID Present

                   3     Return-Code-OK


































Jain, et al.            Expires December 8, 2013               [Page 11]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


6.  Procedure for VXLAN Ping

   VXLAN Echo Request is used to test Data Plane and its view of Control
   Plane for particular VXLAN Segment.  The VXLAN Segment to be verified
   is identified by the "VN-ID".  For the Data Plane verification, the
   complete VXLAN Echo Request Packet would be encapsulated with the
   VXLAN header of the given VXLAN Segment.  For control plane's view of
   the given VXLAN Segment at the Terminating VTEP, the TLV will be
   encoded under Echo Request Packet, to identify presence of given
   VXLAN Segment.

   When VXLAN Echo Request is received, the Terminating VTEP is expected
   to verify the consistency of the Control Plane and Data Plane for the
   VXLAN Segment identified by the VN-ID.

6.1.  Sending VXLAN Echo Request

   Inner Ethernet Header for the VXLAN Echo Request Packet should have
   the Destination Mac set to 00-00-5E-90-XX-XX (to be assigned IANA);
   the Source Mac is set to Mac Address of the Originating VTEP.  In the
   payload portion of this VXLAN Frame.  The IP header is set as
   follows: the source IP Address is a routable Address of the sender;
   the destination IP Address is a (randomly chosen) IPv4 Address from
   the range 127/8, IPv6 addresses are chosen from the range 0:0:0:0:0:
   FFFF:127/104.  The IP TTL is set to 255.  The UDP header is set as
   follows: the source UDP port is chosen by the sender.  It is desired
   to choose the Source UDP port so as to exercise the entropy for ECMP/
   load balancing across the VXLAN Overlay, and it left to the
   implementation; the destination UDP port is set to xxxx (assigned by
   IANA for VXLAN Echo Requests).  The rest of the Echo Request is
   encoded as define in above section "Packet Format", VN-ID in the TLV
   for Echo Request MUST be same as the VN-ID for the VXLAN Segment.
   The IPv4 Sender Address is set to the Address of Originating VTEP's
   IP Address.  The VXLAN Router Alert option
   [I-D.draft-singh-nvo3-vxlan-router-alert] MUST be set in the VXLAN
   header as shown below.  A VXLAN Echo Request is sent encapsulated
   with the VXLAN header corresponding to the VXLAN Segment being
   tested.

    VXLAN Header:
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |R|R|R|R|I|R|R|RA|           Reserved                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                VXLAN Network Identifier (VNI) |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       RA: Router Alter Bit (Proposed)




Jain, et al.            Expires December 8, 2013               [Page 12]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


   The sender chooses a Originator's Handle and a Sequence Number.  When
   sending subsequent VXLAN Echo Requests, the sender SHOULD increment
   the Sequence Number by 1.

   The TimeStamp Sent is set to the time-of-day (in seconds and
   microseconds) that the Echo Request is sent.  The TimeStamp Received
   is set to zero.  Also, the Reply Mode must be set to the desired
   reply mode.  The Return Code and Subcode are set to zero.

6.2.  Receiving VXLAN Echo Request

   At the Terminating VTEP, sending VXLAN Echo Request to the Control
   Plane is triggered by one of the following Packet processing
   exceptions: VXLAN Router Alert option,
   [I-D.draft-singh-nvo3-vxlan-router-alert] the Inner Destination MAC
   Address of 00-00-5E-90-XX-XX as defined in above section, and the
   Destination IP Address in the 127/8 Address range for IPv4 Address,
   or 0:0:0:0:0:FFFF:127/104 for IPv6 Address.  The Control Plane
   further identifies the VXLAN Echo Request by UDP destination port
   xxxx.

   Once the VXLAN Echo Request Packed is identified at Control Plane, it
   is processed as follows:-

   o  General Packet sanity is verified.  If the Packet is not well-
      formed, VTEP SHOULD send VXLAN Echo Reply with the Return Code set
      to "Malformed Echo Request received" and the Subcode to zero.  The
      header fields Originator's Handle, Sequence Number, and Timestamp
      Sent are not examined, but are included in the VXLAN Echo Reply
      message

   o  VNI Validation: If there is no entry for VN-ID, it indicates that
      there could be a transient or permanent disconnect between Control
      Plane and data palne and VTEP needs to report an error with Return
      Code of "No VN-ID Present" and a Return Subcode of Zero.  If the
      mapping exists then send VXLAN Echo Reply with a Return Code of
      "Return-Code-OK", and a Return Subcode of Zero.  The procedures
      for sending the Echo Reply are found in subsection below section.

6.3.  Sending VXLAN Echo Reply

   VXLAN Echo Reply is a UDP Packet.  It MUST ONLY be sent in response
   to VXLAN Echo Request.  The Source IP Address is a routable Address
   of the replier; the source port is the well-known UDP port for VXLAN
   ping.  The Destination IP Address and UDP port are copied from the
   Source IP Address and UDP port of the Echo Request.  The IP TTL is
   set to 255.




Jain, et al.            Expires December 8, 2013               [Page 13]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


   The format of the Echo Reply is the same as the Echo Request.  The
   Originator Handle, the Sequence Number, and TimeStamp Sent are copied
   from the Echo Request; the TimeStamp Received is set to the time-of-
   day that the Echo Request is received (note that this information is
   most useful if the time-of-day clocks on the requester and the
   replier are synchronized).The replier MUST fill in the Return Code
   and Subcode, as determined in the previous subsection.

6.4.  Receiving VXLAN Echo Reply

   An Originating VTEP should only receive VXLAN Echo Reply in response
   to an VXLAN Echo Request that it sent.  Thus, on receipt of VXLAN
   echo reply, Originating VTEP should parse the Packet to ensure that
   it is well-formed, then attempt to match up the Echo Reply with an
   Echo Request that it had previously sent, using the destination UDP
   port and the Originator Handle.  If no match is found, then VTEP
   should drop the Echo Reply Packet; otherwise, it checks the Sequence
   Number to see if it matches.

































Jain, et al.            Expires December 8, 2013               [Page 14]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


7.  Security Considerations

   TBD
















































Jain, et al.            Expires December 8, 2013               [Page 15]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


8.  Management Considerations

   None
















































Jain, et al.            Expires December 8, 2013               [Page 16]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


9.  Acknowledgements

   This document is the outcome of many discussions among many people,
   including Diego Garcia Del Rio, Saurabh Shrivastava and Suresh
   Boddapati of Nuage Networks and Jorge Rabadan of Alcatel-Lucent, Inc.














































Jain, et al.            Expires December 8, 2013               [Page 17]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


10.  IANA Considerations

   Action-1: This specification reserves a IANA UDP Port Number to be
   used when sending the VXLAN Echo Request Packet.

   Action-2: This specification reserves a IANA Ethernet unicast Address
   for VXLAN Exception handling.  This Address needs to be reserved from
   the block.  "IANA Ethernet Address block - Unicast Use"











































Jain, et al.            Expires December 8, 2013               [Page 18]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


11.  References

11.1.  Normative References

   [I-D.draft-lasserre-nvo3-framework]
              Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
              Rekhter, "Framework for DC Network Virtualization",
              September 2011.

   [I-D.draft-mahalingam-dutt-dcops-vxlan]
              Mahalingam, M., Dutt, D., Agarwal, P., Kreeger, L.,
              Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A
              Framework for Overlaying Virtualized Layer 2  Networks
              over Layer 3 Networks", May 2013.

   [I-D.draft-singh-nvo3-vxlan-router-alert]
              Singh, K., Jain, P., Balus, F., and W. Henderickx, "VxLAN
              Router Alert Option", May 2013.

11.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4330]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
              for IPv4, IPv6 and OSI", RFC 4330, January 2006.

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.





















Jain, et al.            Expires December 8, 2013               [Page 19]

Internet-Draft       Detecting VXLAN Segment Failure           June 2013


Authors' Addresses

   Pradeep Jain
   Nuage Networks
   755 Ravendale Drive
   Mountain View, CA  94043
   USA

   Email: pradeep@nuagenetworks.net


   Kanwar Singh
   Nuage Networks
   755 Ravendale Drive
   Mountain View, CA  94043
   USA

   Email: kanwar@nuagenetworks.net


   Florin Balus
   Nuage Networks
   755 Ravendale Drive
   Mountain View, CA  94043
   USA

   Email: florin@nuagenetworks.net


   Wim Henderickx
   Alcatel-Lucent
   Copernicuslaan 50
   Antwerp  2018
   Belgium

   Email: wim.henderickx@alcatel-lucent.be


   Vinay Bannai
   PayPal
   2211 N. First St,
   San Jose  95131
   USA

   Email: vbannai@paypal.com






Jain, et al.            Expires December 8, 2013               [Page 20]