E-VPN Ping Mechanism for Virtual eXtensible Local Area Network (VXLAN)
draft-vji-evpn-ping-vxlan-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | 季祥 , Jaganbabu Rajamanickam , Hicham Ouahid , Chuanfa Wang , Xianlei Du | ||
| Last updated | 2018-05-08 (Latest revision 2018-05-04) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vji-evpn-ping-vxlan-01
Network Working Group V. Ji
Internet Draft J. Rajamanickam
Intended status: Informational H. Ouahid
Expires: November 7, 2018 C. Wang
X. Du
Cisco Systems, Inc.
May 7, 2018
E-VPN Ping Mechanism for Virtual eXtensible Local Area Network
(VXLAN)
draft-vji-evpn-ping-vxlan-01.txt
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 7, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Ji Expires Nov 7, 2018 [Page 1]
Internet-Draft E-VPN Ping Mechanism for VXLAN May 2018
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.
Abstract
Ping is a widely deployed Operation, Administration, and Maintenance
(OAM) mechanism in networks. This document describes a mechanism
for detecting data-plane failures using Ping in RFC7348 VXLAN based
EVPN networks.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................3
3. Acronyms and Definitions.......................................3
4. IP ping and trace route extension for VXLAN....................4
5. VXLAN OAM header format........................................4
5.1. VXLAN EVPN OAM Header:....................................5
5.2. EVPN MAC/IP TLV...........................................7
5.3. EVPN Inclusive Multicast TLV..............................8
5.4. EVPN Auto-Discovery TLV...................................9
5.5. EVPN IP Prefix TLV.......................................10
6. E-VPN Context Validation procedure............................10
7. Security Considerations.......................................11
8. IANA Considerations...........................................11
9. References....................................................11
9.1. Normative References.....................................11
9.2. Informative References...................................13
10. Acknowledgments..............................................13
1. Introduction
RFC7348 Virtual eXtensible Local Area Network (VXLAN): A Framework
for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks
defines means to support data center layer 2 E-VPN over an IP core
network.
draft-jain-bess-evpn-lsp-ping defines procedures to detect data-
plane failures using LSP Ping in MPLS networks deploying EVPN and
PBB-EVPN, which is an extension of RFC6426.
This document outlines how OAM data fields are encapsulated and how
connectivity check and fault isolation is performed from edge to
Ji Expires November 7, 2018 [Page 2]
Internet-Draft E-VPN Ping Mechanism for VXLAN May 2018
edge for VXLAN networks using RFC792 ICMP based ping and traceroute
solution.
2. Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 RFC 2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying significance described in RFC 2119.
In this document, the characters ">>" preceding an indented line(s)
indicates a statement using the key words listed above. This
convention aids reviewers in quickly identifying or finding the
portions of this RFC covered by these keywords.
3. Acronyms and Definitions
AD Auto Discovery
CE Customer Edge Device
ECMP Equal-Cost Multipath
ESI Ethernet Segment Identifier
EVPN Ethernet Virtual Private Network
OAM Operations, Administration and Maintenance
PE Provider Edge Device
VLAN Virtual Local Area Network
VNI VXLAN Network Identifier (or VXLAN Segment ID)
VTEP VXLAN Tunnel End Point. An entity that originates
and/or terminates VXLAN tunnels
VXLAN Virtual eXtensible Local Area Network
Ji Expires November 7, 2018 [Page 3]
Internet-Draft E-VPN Ping Mechanism for VXLAN May 2018
VXLAN Segment VXLAN Layer 2 overlay network over which VMs
communicate
VXLAN Gateway an entity that forwards traffic between VXLANs
4. IP ping and trace route extension for VXLAN
In IP network ICMP, UDP or HTTP based ping and traceroute provide
ways to perform reachability check and fault isolation, this can be
used for OAM purpose for the IP underlay network. E-VPN extension
for the existing ping and traceroute operations make it control-
plane aware and add additional capability to validate the E-VPN
forwarding context, detect data-plane errors and measure PE to PE
performance.
5. VXLAN OAM header format
IPv4 underlay OAM information is encoded in the VXLAN header as
below.
VXLAN Header
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|O|I|R|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 RFC7348 VXLAN header OAM extension
New O bit is selected for OAM purpose, value 1 for OAM packets, 0
for regular VXLAN traffic. This bit is temporarily declared as
bit3, subject to be changed
Ji Expires November 7, 2018 [Page 4]
Internet-Draft E-VPN Ping Mechanism for VXLAN May 2018
5.1. VXLAN EVPN OAM Header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Class = OAM_ECHO | Type |R|R|R| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Return Subcode| Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds fraction) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds fraction) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. TLVs .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 VXLAN EVPN OAM header
Type: 0 for echo request; 1 for echo reply.
Return Code and Return sub-code must be zero for the ping or
traceroute request. For ping or traceroute reply, the value is
defined as:
Return Code # Value Field
------------- -----------
0 Success
1 Context Not Found
2 Context Found but IP address Mis-Match
Return sub-code is reserved for future use.
The Sender's Handle is filled in by the sender and returned
unchanged by the receiver in the echo reply (if any). There are no
Ji Expires November 7, 2018 [Page 5]
Internet-Draft E-VPN Ping Mechanism for VXLAN May 2018
semantics associated with this handle, although a sender may find
this useful for matching up requests with replies.
The Sequence Number is assigned by the sender of the echo request
and can be (for example) used to detect missed replies.
The TimeStamp Sent is the time of day (according to the sender's
clock) in 64-bit NTP timestamp format [RFC5905] when the echo
request is sent. The TimeStamp Received in an echo reply is the
time of day (according to the receiver's clock) in 64-bit NTP
timestamp format in which the corresponding echo request was
received. TimeStamp Received must be zero for the request. Value 0
means the time is not measured or available, shall be ignored.
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 |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 TLV format
Ji Expires November 7, 2018 [Page 6]
Internet-Draft E-VPN Ping Mechanism for VXLAN May 2018
TLV type values use the same value of corresponding BGP route type
when advertised the route, defined in [RFC7432], [draft-ietf-bess-
evpn-prefix-advertisement] and [draft-ietf-bess-evpn-igmp-mld-
proxy].
Type # Value Field
-------- -----------
1 Ethernet Auto-Discovery (A-D) TLV
2 MAC/IP TLV
3 Inclusive Multicast TLV
4 Ethernet Segment TLV (format to be defined)
5 IP Prefix TLV
6 Selective Multicast Ethernet Tag TLV (format to be
defined)
5.2. EVPN MAC/IP TLV
The EVPN MAC/IP TLV is used to identify the MAC for an EVI under
test at a peer PE.
The EVPN MAC TLV fields are derived from the MAC/IP advertisement
route defined in [RFC7432] Section 7.2 and has the format as shown
in Figure 4. This TLV is included in the Echo Request sent to the
Peer PE by the PE that is the originator of the request.
Ji Expires November 7, 2018 [Page 7]
Internet-Draft E-VPN Ping Mechanism for VXLAN May 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Segment Identifier |
| (10 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | must be zero | MAC Addr Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+ (6 Octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Must be zero | IP Addr Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (0, 4 or 16 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2VNI (3 Octets) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3VNI (3 Octets) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 EVPN MAC TLV format
The ping echo request is sent using the EVPN VNI(s) associated with
the MAC route announced by a remote PE to reach the remote PE.
5.3. EVPN Inclusive Multicast TLV
The EVPN Inclusive Multicast sub-TLV fields are based on the EVPN
Inclusive Multicast route defined in [RFC7432] Section 7.3. The EVPN
Inclusive Multicast TLV has the format as shown in Figure 5. This
TLV is included in the echo request sent to the EVPN peer PE by the
originator of request to verify the multicast connectivity state on
the peer PE(s) in EVPN and PBB-EVPN.
Ji Expires November 7, 2018 [Page 8]
Internet-Draft E-VPN Ping Mechanism for VXLAN May 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Addr Len | |
+-+-+-+-+-+-+-+ |
~ Originating Router's IP Addr ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VNI (3 Octets) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 EVPN Inclusive Multicast TLV format
Broadcast, multicast and unknown unicast traffic can be sent using
ingress replication or P2MP P-tree in EVPN network.
5.4. EVPN Auto-Discovery TLV
The EVPN Auto-Discovery (AD) TLV fields are based on the Ethernet AD
route advertisement defined in [RFC7432] Section 7.1. EVPN AD TLV
applies to only EVPN. The EVPN AD sub-TLV has the format shown in
Figure 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Segment Identifier |
| (10 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | must be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VNI (3 Octets) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 EVPN Auto-Discovery TLV format
Ji Expires November 7, 2018 [Page 9]
Internet-Draft E-VPN Ping Mechanism for VXLAN May 2018
5.5. EVPN IP Prefix TLV
The EVPN IP Prefix TLV is used to identify the IP Prefix for an EVI
under test at a peer PE. The EVPN IP Prefix sub-TLV fields are
derived from the IP Prefix Route (RT-5) advertisement defined in [I-
D.ietf-bess-evpn-prefix-advertisement] and has the format as shown
in Figure 7. This TLV is included in the Echo Request sent to the
Peer PE by the PE that is the originator of the request.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Segment Identifier |
| (10 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | must be zero | IP Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP Prefix (4 or 16 Octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ GW IP Address (4 or 16 Octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3VNI (3 Octets) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 EVPN IP Prefix TLV format
6. E-VPN Context Validation procedure
The TLVs in the EVPN OAM header is collect from the control-plane of
the ping or traceroute initiator PE, and to be validated by control-
plane of the peer PE, mid-node transmit routers may ignore it. For
traceroute, when the packet is punted to OAM for each TTL expiry
event, transmitter router may update the TimeStamp field in the
header to provide performance measurement.
This procedure do not have preference of protocol selection of ping
or trace route. Typically, ICMP echo request and ICMP echo reply is
used for ping; while ICMP echo request, UDP, HTTP or other protocols
may be used for traceroute. There is no change to these upper level
protocols.
Ji Expires November 7, 2018 [Page 10]
Internet-Draft E-VPN Ping Mechanism for VXLAN May 2018
7. Security Considerations
The proposal introduced in this document does not introduce any new
security considerations beyond that already apply to [RFC7432],
[RFC7348], [RFC7623] and [RFC6425] and draft-jain-bess-evpn-lsp-
ping.
8. IANA Considerations
8.1. Sub-TLV Type
This document defines 6 new TLV types, which is intend to use the
same value as RT types defined in [RFC7432], [draft-ietf-bess-
evpn-prefix-advertisement] and [draft-ietf-bess-evpn-igmp-mld-
proxy].
IANA is requested to assign a sub-TLV type value to the following
8.2. Proposed new Return Codes
[RFC8029] defines values for the Return Code field of Echo Reply.
This document proposes two new Return Codes, which SHOULD be
included in the Echo Reply message by a PE in response to LSP Ping
Echo Request message:
1. The FEC exists on the PE and the behavior is to drop the packet
because of not DF.
2. The FEC exists on the PE and the behavior is to drop the packet
because of Split Horizon Filtering.
9. References
9.1. Normative References
[RFC7348] M. Mahalingam, Storvisor, D. Dutt, K. Duda, P. Agarwal, L.
Kreeger, T. Sridhar, M. Bursell, C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, August 2014, <https://www.rfc-
editor.org/info/rfc7348>.
Ji Expires November 7, 2018 [Page 11]
Internet-Draft E-VPN Ping Mechanism for VXLAN May 2018
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[draft-ietf-bess-evpn-prefix-advertisement] Rabadan, J., Henderickx,
W., Drake, J., Lin, W., and A. Sajassi, "IP Prefix
Advertisement in EVPN", draft-ietf-bess-evpn-prefix-
advertisement-10 (work in progress), February 27, 2018.
[draft-ietf-bess-evpn-igmp-mld-proxy] Ali Sajassi, Samir Thoria,
Keyur Patel, Derek Yeung, John Drake and Wen Lin "IGMP and
MLD Proxy for EVPN", draft-ietf-bess-evpn-igmp-mld-proxy-
00 (work in progress), March 2017.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Failures in Point-to-Multipoint MPLS - Extensions to LSP
Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
<https://www.rfc-editor.org/info/rfc6425>.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing",
RFC 6426, DOI 10.17487/RFC6426, November 2011,
<https://www.rfc-editor.org/info/rfc6426>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029, DOI
10.17487/RFC8029, March 2017, <https://www.rfc-
editor.org/info/rfc8029>.
[draft-jain-bess-evpn-lsp-ping] P. Jain, Ed., S. Salam, A. Sajassi,
S. Boutros and G. Mirsky, "LSP-Ping Mechanisms for EVPN
and PBB-EVPN", draft-jain-bess-evpn-lsp-ping-06 (work in
progress), January, 2018
[RFC5905] D. Mills, J. Martin, Ed., J. Burbank, W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", June 2010, <https://www.rfc-
editor.org/info/rfc5905>.
Ji Expires November 7, 2018 [Page 12]
Internet-Draft E-VPN Ping Mechanism for VXLAN May 2018
9.2. Informative References
[RFC792] J. Postel, "INTERNET CONTROL MESSAGE PROTOCOL", RFC792,
September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC7623] A. Sajassi, Ed., S. Salam, N. Bitar, A. Isaac, W.
Henderickx, "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", September 2015,
<https://www.rfc-editor.org/info/rfc7623>.
10. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Victor Ji
Cisco Systems, Inc.
Email: vji@cisco.com
Jaganbabu Rajamanickam
Cisco Systems, Inc.
Email: jrajaman@cisco.com
Hicham Ouahid
Cisco Systems, Inc.
Email: houahid@cisco.com
Chuanfa Wang
Cisco Systems, Inc.
Email: chuanwan@cisco.com
Xianlei Du
Cisco Systems, Inc.
Email: xiandu@cisco.com
Ji Expires November 7, 2018 [Page 13]