INTERNET-DRAFT V. Govindan
Intended status: Proposed Standard M. Mudigonda
A. Sajassi
Cisco Systems
G. Mirsky
ZTE
D. Eastlake
Futurewei Technologies
Expires: August 21, 2021 February 22, 2021
EVPN Network Layer Fault Management
draft-ietf-bess-evpn-bfd-03
Abstract
This document specifies proactive, in-band network layer OAM
mechanisms to detect loss of continuity and miss-connection faults
that affect unicast and multi-destination paths (used by Broadcast,
Unknown Unicast, and Multicast traffic) in an Ethernet VPN (EVPN)
network. The mechanisms specified in the draft are based on the
widely adopted Bidirectional Forwarding Detection (BFD) protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the authors or the BESS working group mailing list: bess@ietf.org.
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/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Govindan, et al [Page 1]
Internet-Draft EVPN Network Layer Fault Management
Table of Contents
1. Introduction............................................3
1.1 Terminology............................................3
2. Scope of this Document..................................5
3. Motivation for Running BFD at the EVPN Network Layer....6
4. Fault Detection for Unicast Traffic.....................7
5. Fault Detection for BUM Traffic.........................8
5.1 Ingress Replication....................................8
5.2 P2MP Tunnels (Label Switched Multicast)................8
6. BFD Packet Encapsulation...............................10
6.1 MPLS Encapsulation....................................10
6.1.1 Unicast MPLS Encapsulation..........................10
6.1.2 MPLS Ingress Replication (MP2P).....................11
6.1.3 MPLS LSM (Label Switched Multicast, P2MP)...........12
6.2 VXLAN Encapsulation...................................12
6.2.1 Unicast VXLAN Encapsulation.........................12
6.2.2 VXLAN Ingress Replication (MP2P)....................14
6.2.3 VXLAN LSM (Label Switched Multicast, P2MP)..........14
7. Scalability Considerations.............................15
8. IANA Considerations....................................16
8.1 Pseudowire Associated Channel Type....................16
8.2 MAC Addresses.........................................16
8.3 BFD Discriminator Attribute Type......................16
9. Security Considerations................................17
Acknowledgements..........................................17
Normative References......................................18
Informative References....................................20
Authors' Addresses........................................21
Govindan, et al [Page 2]
Internet-Draft EVPN Network Layer Fault Management
1. Introduction
[ietf-bess-evpn-oam-req-frmwk] outlines the OAM requirements of
Ethernet VPN networks (EVPN [RFC7432]). This document specifies
mechanisms for proactive fault detection at the network (overlay)
layer of EVPN. The mechanisms proposed in the draft use the widely
adopted Bidirectional Forwarding Detection (BFD [RFC5880]) protocol.
EVPN fault detection mechanisms need to consider unicast traffic
separately from Broadcast, Unknown Unicast, and Multicast (BUM)
traffic since they map to different Forwarding Equivalency Classes
(FECs) in EVPN. Hence this document proposes somewhat different fault
detection mechanisms depending on the type of traffic and the type of
tunnel used as follows:
o Using BFD [RFC5880] for unicast traffic and BUM traffic via
MP2P tunnels.
o Using BFD Multipoint Active Tails [RFC8563] [mirsky-mpls-p2mp-
bfd] for BUM traffic via a P2MP tunnel.
Packet loss and packet delay measurement are out of scope for this
document.
1.1 Terminology
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following acronyms are used in this document.
BFD - Bidirectional Forwarding Detection [RFC5880]
BUM - Broadcast, Unknown Unicast, and Multicast
CC - Continuity Check
CV - Connectivity Verification
EVI - EVPN Instance
EVPN - Ethernet VPN [RFC7432]
FEC - Forwarding Equivalency Class
GAL - Generic Associated Channel Label [RFC5586]
Govindan, et al [Page 3]
Internet-Draft EVPN Network Layer Fault Management
LSM - Label Switched Multicast (P2MP)
LSP - Label Switched Path
MP2MP - Multi-Point-to-Multi-Point
MP2P - Multi-Point-to-Point
OAM - Operations, Administration, and Maintenance
P2MP - Point-to-Multi-Point (LSM)
P2P - Point to Point.
PE - Provider Edge
VXLAN - Virtual eXtensible Local Area Network (VXLAN) [RFC7348]
Govindan, et al [Page 4]
Internet-Draft EVPN Network Layer Fault Management
2. Scope of this Document
This document specifies BFD based mechanisms for proactive fault
detection for EVPN as specified in [RFC7432] and also for EVPN using
VXLAN encapsulation [RFC8365]. It covers the following:
o Unicast traffic using Point-to-Point (P2P) and Multi-Point-to-
Point (MP2P) tunnels.
o BUM traffic using Multi-Point-to-Point (MP2P) tunnels (ingress
replication).
o BUM traffic using Point-to-Multi-Point (P2MP) tunnels (Label
Switched Multicast (LSM)).
o MPLS and VXLAN encapsulation.
This document does not discuss BFD mechanisms for:
o EVPN variants like PBB-EVPN [RFC7623]. It is intended to
address this in future versions.
o Integrated Routing and Bridging (IRB) solution based on EVPN
[ietf-bess-evpn-inter-subnet-forwarding]. It is intended to
address this in future versions.
o EVPN using other encapsulations such as NVGRE or MPLS over GRE
[RFC8365].
o BUM traffic using MP2MP tunnels.
This document specifies procedures for BFD asynchronous mode. BFD
demand mode is outside the scope of this specification except as it
is used in [RFC8563]. The use of the Echo function is outside the
scope of this specification.
Govindan, et al [Page 5]
Internet-Draft EVPN Network Layer Fault Management
3. Motivation for Running BFD at the EVPN Network Layer
The choice of running BFD at the network layer of the OAM model for
EVPN [ietf-bess-evpn-oam-req-frmwk] was made after considering the
following:
o In addition to detecting link failures in the EVPN network, BFD
sessions at the network layer can be used to monitor the
successful setup, such as label programming, of MP2P and P2MP EVPN
tunnels transporting Unicast and BUM traffic. The scope of
reachability detection covers the ingress and the egress EVPN PE
(Provider Edge) nodes and the network connecting them.
o Monitoring a representative set of path(s) or a particular path
among multiple paths available between two EVPN PE nodes could be
done by exercising entropy mechanisms such as entropy labels, when
they are used, or VXLAN source ports. However, paths that cannot
be realized by entropy variations cannot be monitored. The fault
monitoring requirements outlined by [ietf-bess-evpn-oam-req-frmwk]
are addressed by the mechanisms proposed by this draft.
BFD testing between EVPN PE nodes does not guarantee that the EVPN
service is functioning. (This can be monitored at the service level,
that is CE to CE.) For example, an egress EVPN-PE could understand
EVPN labeling received but could switch data to an incorrect
interface. However, BFD testing in the EVPN Network Layer does
provide additional confidence that data transported using those
tunnels will reach the expected egress node. When BFD testing in the
EVPN overlay fails, that can be used as an indication of a Loss-of-
Connectivity defect in the EVPN underlay that would cause EVPN
service failure.
Govindan, et al [Page 6]
Internet-Draft EVPN Network Layer Fault Management
4. Fault Detection for Unicast Traffic
The mechanisms specified in BFD for MPLS LSPs [RFC5884] [RFC7726]
are, except as otherwise provided herein, applied to test the
handling of unicast EVPN traffic. When discriminators are required
for de-multiplexing the BFD sessions, they can be advertised through
BGP using the BFD Discriminator Attribute [ietf-bess-mvpn-fast-
failover]. Discriminators are needed for MPLS since the label stack
does not contain enough information to identify the sender of the
packet.
The usage of MPLS entropy labels or various VXLAN source ports takes
care of the requirement to monitor various paths of the multi-path
server layer network [RFC6790]. Each unique realizable path between
the participating PE routers MAY be monitored separately when such
entropy is used. At least one path of multi-path connectivity
between two PE routers MUST be tracked with BFD, but in that case the
granularity of fault-detection will be coarser.
To support unicast fault management to a PE node, that PE MUST
allocate or be configured with a BFD discriminator to be used for the
BFD messages to it. By default, it advertises this discriminator with
BGP using the BFD Discriminator Attribute [ietf-bess-mvpn-fast-
failover] with BFD Mode TBD4 in an EVPN MAC/IP Advertisement Route
[RFC7432] and extracts its peer's discriminator from such an
attribute. however, these discriminators MAY be exchanged out-of-band
or through some other mechanism outside the scope of this document.
If configured to do so, once a PE knows a unicast route and
discriminator for another PE, it endeavors to bring UP and maintain a
BFD session to that other PE. Once the BFD session is UP, the ends of
the BFD session MUST NOT change the local discriminator values of the
BFD Control packets they generate, unless they first bring down the
session as specified in [RFC5884]. The BFD session is brought down
if a PE is no longer configured to maintain it or if a route and
discriminator are no longer available.
Govindan, et al [Page 7]
Internet-Draft EVPN Network Layer Fault Management
5. Fault Detection for BUM Traffic
Section 5.1 below discusses BUM traffic fault detection for MP2P
tunnels using ingress replication and Section 5.2 discusses such
fault detection for P2MP tunnels.
5.1 Ingress Replication
Ingress replication uses separate MP2P tunnels for transporting BUM
traffic from the ingress PE (head) to a set of one or more egress PEs
(tails). The fault detection mechanism specified by this document
takes advantage of the fact that the head makes a unique copy for
each tail.
Another key aspect to be considered in EVPN is the advertisement of
the Inclusive Multicast Ethernet Tag Route [RFC7432]. The BUM
traffic flows from a head node to a particular tail only after the
head receives such inclusive multicast route from the tail. This
route contains the BUM EVPN MPLS label (downstream allocated)
corresponding to the MP2P tunnel for MPLS encapsulation and contains
the IP address of the PE originating the inclusive multicast route
for use in VXLAN encapsulation. It also contains a BFD Discriminator
Attribute [ietf-bess-mvpn-fast-failover] with BFD Mode TDB4 giving
the BFD discriminator that will be used by the tail. This is the P2P
mode since a P2P BFD session is used in the MP2P case.
There MAY exist multiple BFD sessions between a head PE and an
individual tail due to (1) the usage of MPLS entropy labels [RFC6790]
or VXLAN source ports for an inclusive multicast FEC and (2) due to
multiple MP2P tunnels indicated by different tail labels or IP
addresses for MPLS or VXLAN. If configured to do so, once a PE knows
a multicast route and discriminator for another PE it endeavors to
bring UP and maintain a BFD session to that other PE. Once a BFD
session for a path is UP, the ends of the BFD session MUST NOT change
the local discriminator values of the BFD Control packets they
generate, unless they first bring down the session as specified in
[RFC5884]. The BFD session is brought down if a PE is no longer
configured to maintain it or if a route and discriminator are no
longer available.
5.2 P2MP Tunnels (Label Switched Multicast)
Fault detection for BUM traffic distributed using a P2MP tunnel uses
BFD Multipoint Active Tails in one of the three methods providing
head notification depending on configuration. Sections 5.2.2 and
5.2.3 of [RFC8563] describe two of these methods ("Head Notification
Govindan, et al [Page 8]
Internet-Draft EVPN Network Layer Fault Management
and Tail Solicitation with Multipoint Polling" and "Head Notification
with Composite Polling"). The third method ("Head Notification
without Polling") is touched on in Section 5.2.1 of [RFC8563] and
fully specified in [mirsky-mpls-p2mp-bfd]. All three of these modes
assume the existence of a unicast path from each tail to the head. In
addition, Head Notification with Composite Polling assumes a head to
tail unicast path.
The BUM traffic flows from a head node to the tails after the head
receives an Inclusive Multicast Tag Route [RFC7432]. This contains
the BUM EVPN MPLS label (upstream allocated) corresponding to the
P2MP tunnel for MPLS encapsulation. It also contains a BFD
Discriminator Attribute [ietf-bess-mvpn-fast-failover] with BFD Mode
1 and with a Source IP Address TLV giving the address associated with
the MultiPoint Head of the P2MP session. This BFD discriminator
advertised by a tail in the inclusive multicast route or otherwise
configured at or communicated to the head MUST be used in any reverse
unicast traffic so the head can determine which tail is responding.
If configured to do so, once a PE knows a P2MP multicast route and
needed discriminators, it brings UP and maintains a BFD active tails
session to the tails. The BFD session is brought down if a PE is no
longer configured to maintain it or if the multicast route and
discriminators are no longer available.
For MPLS encapsulation of the head to tails BFD, Label Switched
Multicast is used. For VXLAN encapsulation, BFD is delivered to the
tails through underlay multicast using an outer multicast IP address.
Govindan, et al [Page 9]
Internet-Draft EVPN Network Layer Fault Management
6. BFD Packet Encapsulation
The sections below discuss the MPLS and VXLAN encapsulations of BFD
for EVPN network layer fault management.
6.1 MPLS Encapsulation
This section describes use of the Generic Associated Channel Label
(GAL) for BFD encapsulation in MPLS based EVPN network layer fault
management.
6.1.1 Unicast MPLS Encapsulation
As shown in Figure 1, the packet initially contains the following
labels: LSP label (transport), the optional entropy label, the EVPN
Unicast label, and then the Generic Associated Channel label with the
G-ACh type set to TBD1. The G-ACh payload of the packet MUST contain
the destination L2 header (in overlay space) followed by the IP
header that encapsulates the BFD packet. The MAC address of the
inner packet is used to validate the <EVI, MAC> in the receiving
node.
- The destination MAC MUST be the dedicated unicast MAC TBD3 (see
Section 8) or the MAC address of the destination PE.
- The destination IP address MUST be 127.0.0.1/32 for IPv4
[RFC1812] or ::1/128 for IPv6 [RFC4291].
- The destination IP port MUST be 3784 [RFC5881].
- The source IP port MUST be in the range 49152 through 65535.
- The discriminator values for BFD are obtained through BGP as
discussed in Section 4.
Govindan, et al [Page 10]
Internet-Draft EVPN Network Layer Fault Management
<---------- 4 bytes ---------->
+-------------------------------+ -----
| LSP Label | |
+-------------------------------+ |
: entropy label indicator : |
+ (optional) + MPLS Label Stack
: entropy label : |
+-------------------------------+ |
| EVPN Unicast label |
+-------------------------------+ |
| Generic Assoc. Channel Label | |
+-------------------------------+ -----
| ACH word, Type TBD1 no TLVs |
+-------------------------------+ --- -------
| Destination MAC Address | | |
+ +---------------+ | |
| TBD2 | | | |
+---------------+ + L2 Header |
| Source MAC Address | | |
+---------------+---------------+ | |
| VLAN Ethertype| VLAN-ID | | |
+---------------+---------------+ | |
|IP4/6 Ethertype| | |
+---------------+---------------+ --- |
/ / G-ACh Payload
/... IPv4/6 Header .../ |
/ / |
+-------------------------------+ |
| | |
+ UDP Header + |
| | |
+-------------------------------+ |
| | |
+ BFD Control Packet + |
/ / |
/... .../ ---------------
Figure 1. MPLS Unicast Encapsulation
6.1.2 MPLS Ingress Replication (MP2P)
The packet initially contains the following labels: LSP label
(transport), the optional entropy label, the BUM label, and the split
horizon label [RFC7432] (where applicable). The G-ACh type is set to
TBD1. The G-ACh payload of the packet is as described in Section
6.1.1 except that the destination MAC address is the dedicated
multicast MAC TBD2.
Govindan, et al [Page 11]
Internet-Draft EVPN Network Layer Fault Management
6.1.3 MPLS LSM (Label Switched Multicast, P2MP)
The encapsulation is the same as in Section 6.1.2 for ingress
replication except that the transport label identifies the P2MP
tunnel, in effect the set of tail PEs, rather than identifying a
single destination PE at the end of an MP2P tunnel.
6.2 VXLAN Encapsulation
This section describes the use of the VXLAN [RFC7348] [RFC8365] for
BFD encapsulation in VXLAN based EVPN fault management.
6.2.1 Unicast VXLAN Encapsulation
Figure 2 below shows the unicast VXLAN encapsulation. The outer and
inner IP headers have a unicast source IP address of the BFD message
source and a destination IP address of the BFD message destination
The destination UDP port MUST be 3784 [RFC5881]. The source port MUST
be in the range 49152 through 65535. If the BFD source has multiple
IP addresses, entropy MAY be further obtained by using any of those
addresses assuming the source is prepared for responses directed to
the IP address used.
Govindan, et al [Page 12]
Internet-Draft EVPN Network Layer Fault Management
<---------- 4 bytes ---------->
+-------------------------------+ ---
| Destination MAC Address | |
+ +---------------+ |
| | | |
+---------------+ + L2 Header
| Source MAC Address | |
+-------------------------------+ |
| VLAN Ethertype| VLAN-ID | |
+---------------+---------------+ |
|IP4/6 Ethertype| |
+---------------+---------------+ ---
/ /
/... IP4/6 Header .../
/ /
+-------------------------------+
| |
+ UDP Header +
| |
+-------------------------------+
| |
+ VXLAN Header +
| |
+-------------------------------+ ---
| Destination MAC Address | |
+ +---------------+ |
| | | |
+---------------+ + L2 Header
| Source MAC Address | |
+---------------+---------------+ |
| IP4 Ethertype | |
+---------------+---------------+ ---
/ /
/... IP4 Header .../
/ /
+-------------------------------+
| |
+ UDP Header +
| |
+---------------+---------------+
| |
+ BFD Control Packet +
| |
/... .../
Figure 2. VXLAN Unicast Encapsulation
Govindan, et al [Page 13]
Internet-Draft EVPN Network Layer Fault Management
6.2.2 VXLAN Ingress Replication (MP2P)
The BFD packet construction is as given in Section 6.2.1 except as
follows:
(1) The destination IP address used by the BFD message source is that
advertised by the destination PE in its Inclusive Multicast EVPN
route for the MP2P tunnel in question; and
(2) The Your BFD discriminator used is the one advertised by the BFD
destination using BGP as discussed in Section 5.1 for the MP2P
tunnel.
6.2.3 VXLAN P2MP
The VXLAN encapsulation for the head-to-tails BFD packets uses the
multicast destination IP corresponding to the VXLAN VNI.
The destination port MUST be 3784. For entropy purposes, the source
port can vary but MUST be in the range 49152 through 65535 [RFC5881].
If the head PE has multiple IP addresses, entropy MAY be further
obtained by using any of those addresses.
The Your BFD discriminator is the value distributed for this
multicast fault management purpose as discussed in Section 5.2.
Govindan, et al [Page 14]
Internet-Draft EVPN Network Layer Fault Management
7. Scalability Considerations
The mechanisms proposed by this draft could affect the packet load on
the network and its elements especially when supporting
configurations involving a large number of EVIs. The option of
slowing down or speeding up BFD timer values can be used by an
administrator or a network management entity to maintain the overhead
incurred due to fault monitoring at an acceptable level.
Govindan, et al [Page 15]
Internet-Draft EVPN Network Layer Fault Management
8. IANA Considerations
The following IANA Actions are requested.
8.1 Pseudowire Associated Channel Type
IANA is requested to assign a channel type from the "Pseudowire
Associated Channel Types" registry in [RFC4385] as follows.
Value Description Reference
----- ------------ ------------
TBD1 BFD-EVPN OAM [this document]
8.2 MAC Addresses
IANA is requested to assign parallel multicast and unicast MAC
addresses under the IANA OUI [0x01005E900101 and 0x00005E900101
suggested] as follows:
IANA Multicast 48-bit MAC Addresses
Address Usage Reference
------- --------------------- ---------------
TBD2 EVPN Network Layer OAM [this document]
IANA Unicast 48-bit MAC Addresses
Address Usage Reference
------- --------------------- ---------------
TBD3 EVPN Network Layer OAM [this document]
8.3 BFD Discriminator Attribute Type
IANA is requested to assign a value from the IETF Review range in the
BFD Mode sub-registry on the Border Gateway Protocol Parameters
Registry web page as follows:
Value Description Reference
----- --------------- ---------------
TBD4 P2P BFD Session [this document]
Govindan, et al [Page 16]
Internet-Draft EVPN Network Layer Fault Management
9. Security Considerations
Security considerations discussed in [RFC5880], [RFC5883], and
[RFC8029] apply.
MPLS security considerations [RFC5920] apply to BFD Control packets
encapsulated in a MPLS label stack. When BPD Control packets are
routed, the authentication considerations discussed in [RFC5883]
should be followed.
VXLAN BFD security considerations in [RFC8971] apply to BFD packets
encapsulate in VXLAN.
Acknowledgements
The authors wish to thank the following for their comments and
suggestions:
Mach Chen
Govindan, et al [Page 17]
Internet-Draft EVPN Network Layer Fault Management
Normative References
[ietf-bess-mvpn-fast-failover] Morin, T., Kebler, R., Mirsky, G.,
"Multicast VPN fast upstream failover",
draft-ietf-bess-mvpn-fast-failover (in RFC Editor's queue),
February 2019.
[mirsky-mpls-p2mp-bfd] G. Mirsky, S. Mishra, "BFD for Multipoint
Networks over Point-to-Multi-Point MPLS LSP", draft-mirsky-
mpls-p2mp-bfd (work in progress), November 2020.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <http://www.rfc-editor.org/info/rfc4385>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, DOI
10.17487/RFC5586, June 2009, <https://www.rfc-
editor.org/info/rfc5586>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI
10.17487/RFC5881, June 2010, <https://www.rfc-
editor.org/info/rfc5881>.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
June 2010, <https://www.rfc-editor.org/info/rfc5883>.
Govindan, et al [Page 18]
Internet-Draft EVPN Network Layer Fault Management
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <https://www.rfc-editor.org/info/rfc5884>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L.
Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC
6790, DOI 10.17487/RFC6790, November 2012, <http://www.rfc-
editor.org/info/rfc6790>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[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, <http://www.rfc-editor.org/info/rfc7432>.
[RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S.
Aldrin, "Clarifying Procedures for Establishing BFD
Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726,
DOI 10.17487/RFC7726, January 2016, <https://www.rfc-
editor.org/info/rfc7726>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI
10.17487/RFC8365, March 2018, <https://www.rfc-
editor.org/info/rfc8365>.
[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
Ed., "Bidirectional Forwarding Detection (BFD) Multipoint
Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,
<https://www.rfc-editor.org/info/rfc8563>.
Govindan, et al [Page 19]
Internet-Draft EVPN Network Layer Fault Management
Informative References
[ietf-bess-evpn-inter-subnet-forwarding] Sajassi, A., Salam, S.,
Thoria, S., Rekhter, Y., Drake, J., Yong, L., and L.
Dunbar, "Integrated Routing and Bridging in EVPN",
draft-ietf-bess-evpn-inter-subnet-forwarding-13 (work in
progress), February 2021.
[ietf-bess-evpn-oam-req-frmwk] Salam, S., Sajassi, A., Aldrin, S., J.
Drake, and D. Eastlake, "EVPN Operations, Administration
and Maintenance Requirements and Framework",
draft-ietf-bess-evpn-oam-req-frmwk-04, work in progress,
July 2019.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Henderickx, "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
September 2015, <http://www.rfc-editor.org/info/rfc7623>.
[RFC8971] Pallagatti, S., Ed., Mirsky, G., Ed., Paragiri, S.,
Govindan, V., and M. Mudigonda, "Bidirectional Forwarding
Detection (BFD) for Virtual eXtensible Local Area Network
(VXLAN)", RFC 8971, DOI 10.17487/RFC8971, December 2020,
<https://www.rfc-editor.org/info/rfc8971>.
Govindan, et al [Page 20]
Internet-Draft EVPN Network Layer Fault Management
Authors' Addresses
Vengada Prasad Govindan
Cisco Systems
Email: venggovi@cisco.com
Mudigonda Mallik
Cisco Systems
Email: mmudigon@cisco.com
Ali Sajassi
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134, USA
Email: sajassi@cisco.com
Gregory Mirsky
ZTE Corp.
Email: gregimirsky@gmail.com
Donald Eastlake, 3rd
Futurewei Technologies
2386 Panoramic Circle
Apopka, FL 32703 USA
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Govindan, et al [Page 21]
Internet-Draft EVPN Network Layer Fault Management
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2021 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
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.
Govindan, et al [Page 22]
