Internet DRAFT - draft-vgovindan-l2vpn-evpn-bfd
draft-vgovindan-l2vpn-evpn-bfd
Network Working Group V. Govindan
Internet-Draft S. Salam
Intended status: Standards Track A. Sajassi
Expires: January 5, 2015 Cisco Systems
July 4, 2014
Proactive fault detection in EVPN
draft-vgovindan-l2vpn-evpn-bfd-02
Abstract
This document proposes a proactive, in-band network OAM mechanism to
detect connectivity faults that affect unicast and multi-destination
paths in an EVPN network. The multi-destination paths are used by
Broadcast, unknown Unicast and Multicast (BUM) traffic. The
mechanisms proposed in the draft use the principles of 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.
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 January 5, 2015.
Copyright Notice
Copyright (c) 2014 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
Govindan, et al. Expires January 5, 2015 [Page 1]
Internet-Draft Govindan July 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Motivation for running BFD at the network layer of EVPN . 3
2. Scope of fault detection mechanisms proposed in this
document . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Fault Detection of BUM traffic using ingress replication
(MP2P) . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Bootstrapping BFD sessions at the head of the MP2P
tunnel . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Bootstrapping BFD sessions at the tail nodes of the
MP2P tunnel . . . . . . . . . . . . . . . . . . . . . 5
2.2. Fault Detection of BUM traffic using P2MP tunnels (LSM) . 5
2.2.1. Bootstrapping BFD sessions at the root of the P2MP
tunnel . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Bootstrapping BFD sessions at the tail nodes of the
P2MP tunnel . . . . . . . . . . . . . . . . . . . . . 6
2.3. Fault Detection of unicast traffic . . . . . . . . . . . 6
3. BFD packet encapsulation . . . . . . . . . . . . . . . . . . 6
3.1. Using GAL/G-ACh encapsulation without IP headers . . . . 6
3.1.1. Ingress replication . . . . . . . . . . . . . . . . . 6
3.1.2. LSM . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Unicast . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Using IP headers . . . . . . . . . . . . . . . . . . . . 7
4. Scalability Considerations . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
[I-D.salam-l2vpn-evpn-oam-req-frmwk] outlines the OAM requirements of
Ethernet VPN networks [I-D.ietf-l2vpn-evpn]. This document proposes
mechanisms for proactive fault detection at the network OAM layer of
EVPN. These mechanisms could either be deployed for periodic and
proactive monitoring, or be triggered by specific events to aid
troubleshooting. EVPN fault detection mechanisms need to consider
unicast and BUM traffic separately since they map to different FECs
in EVPN. Since BUM traffic can be transported using MP2P or P2MP
Govindan, et al. Expires January 5, 2015 [Page 2]
Internet-Draft Govindan July 2014
tunnels, this document proposes slightly different fault detection
mechanisms to suit each type using the principles of BFD over MPLS
LSPs [RFC5884] and Point-to-multipoint BFD[I-D.ietf-bfd-multipoint].
Please note that this document uses the term EVPN loosely to include
[I-D.ietf-l2vpn-evpn], [I-D.ietf-l2vpn-pbb-evpn] as well as
[I-D.ietf-l2vpn-trill-evpn].
1.1. Terminology
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].
1.2. Motivation for running BFD at the network layer of EVPN
The choice of running BFD at the network layer of the OAM model for
EVPN [I-D.salam-l2vpn-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 programming of labels used for setting up MP2P and P2MP
EVPN tunnels transporting Unicast and BUM traffic. The scope of
reachability detection covers the ingress and the egress EVPN PE
nodes and the network connecting them.
o Monitoring a representative set of path(s) or a particular path
among the multiple paths available between two EVPN PE nodes could
be done by exercising the entropy labels when they are used.
However paths that cannot be realized by entropy variations cannot
be monitored. Fault monitoring requirements outlined by
[I-D.salam-l2vpn-evpn-oam-req-frmwk] are addressed by the
mechanisms proposed by this draft.
Successful establishment and maintenance of BFD sessions between EVPN
PE nodes does not fully guarantee that the EVPN service is
functioning. For example, an egress EVPN-PE can understand the EVPN
label but could switch data to incorrect interface. However, once
BFD sessions in the EVPN Network Layer reach UP state, it does
provide additional confidence that data transported using those
tunnels will reach the expected egress node. When BFD sessions in
the EVPN Network Layer exits UP state, it provides additional
confidence that data transported using those tunnels will not reach
the expected egress node.
Govindan, et al. Expires January 5, 2015 [Page 3]
Internet-Draft Govindan July 2014
2. Scope of fault detection mechanisms proposed in this document
This section proposes proactive fault detection using BFD mechanisms
for:
a. BUM traffic using MP2P tunnels (ingress replication).
b. BUM traffic using P2MP tunnels (LSM).
c. Unicast traffic.
This specification describes procedures only for BFD asynchronous
mode. BFD demand mode is outside the scope of this specification.
Further, the use of the Echo function is outside the scope of this
specification. The approach takes advantage of the inclusive
multicast route used in EVPN to advertise the multi-destination FEC
for bootstrapping the BFD sessions. Earlier approaches for P2MP BFD
[I-D.ietf-mpls-mcast-cv] have used periodic MPLS ping requests to
bootstrap P2MP BFD sessions over MPLS.
2.1. Fault Detection of BUM traffic using ingress replication (MP2P)
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 proposed by this document
takes advantage of the fact that a unique copy is made by the head
for each tail. Another key aspect to be considered in EVPN is the
advertisement of the inclusive multicast route. The BUM traffic
flows from a head node to a particular tail only after the head
receives the inclusive multicast route containing the BUM EVPN label
(downstream allocated) corresponding to the MP2P tunnel. Note that
once the BFD session for the EVPN BUM label is UP, either end of the
BFD session MUST NOT change the local discriminator values of the BFD
Control packets it generates, unless it first brings down the session
as specified in RFC 5884 [RFC5884].
2.1.1. Bootstrapping BFD sessions at the head of the MP2P tunnel
To simplify BFD session de-multiplexing, we take advantage of the
fact that the head replicates a BUM packet for each tail by using
unique sets of discriminators in each copy of the (replicated) BFD
packet. These discriminators MUST be exchanged out-of-band using
MPLS ping RFC 5884 [RFC5884] before the start of the BFD session
between the head and the tail node(s). The head PE performing
ingress replication MUST initiate an LSP ping using the inclusive
multicast FEC [I-D.jain-l2vpn-evpn-lsp-ping] upon receiving an
inclusive multicast route from a tail to bootstrap the BFD session.
This MPLS ping MUST include the BFD TLV specified in RFC 5884
Govindan, et al. Expires January 5, 2015 [Page 4]
Internet-Draft Govindan July 2014
[RFC5884]. There could exist multiple BFD sessions between a head of
the multi-destination tunnel and an individual tail due to the usage
of entropy labels RFC 6790 [RFC6790] for an inclusive multicast FEC.
For fine-grained fault detection, a BFD session MAY be bootstrapped
to monitor all unique path(s) that can be realized using entropy
labels between a head and a given tail. However, the path(s) MUST be
monitored using at least one or more number of representative BFD
session(s) to satisfy the fault monitoring requirements
[I-D.salam-l2vpn-evpn-oam-req-frmwk]. The issue of demultiplexing
(separate) BFD sessions established to monitor liveness of the
multiple paths of a <MPLS LSP, FEC> has not been fully addressed by
[RFC5884]. Procedures proposed in [ID.draft-vgovindan-mpls-extended-
bfd-disc-tlv] [1] could be used for monitoring connectivity of the
path(s) that are realized through entropy labels. The head node MAY
initiate separate BFD sessions using different instance identifiers
to verify connectivity of the different paths.
2.1.2. Bootstrapping BFD sessions at the tail nodes of the MP2P tunnel
The tail nodes MUST bootstrap a BFD session based on the incoming
MPLS ping initiated by the head [I-D.ietf-bfd-multipoint]. At the
tail node, a new BFD discriminator MUST be allocated for each unique
combination of the source IP and the attributes of the <inclusive
multicast FEC, BUM label> when a MPLS ping initiated from the head is
received. A tail node MAY include the instance identifier, if
present to support monitoring of specific paths or all realizable
paths.
2.2. Fault Detection of BUM traffic using P2MP tunnels (LSM)
The case of using P2MP tunnels for distributing BUM traffic presents
a different challenge for using BFD. Clearly, the yourDisc of the
BFD packet MUST be zero [I-D.ietf-bfd-multipoint] as the packet is
multicast from the root unlike ingress replication where individual
copies are made from the head. However the MPLS label that
identifies the P-Tunnel [I-D.ietf-l2vpn-evpn] used for forwarding the
multi-destination traffic provides a convenient method of identifying
the source and the FEC (multi-destination tree) being tracked by the
BFD session. The tails of the multi-destination tree MUST use the
MPLS label identifying the P-tunnel to de-multiplex the BFD packet.
In the case of Aggregate Inclusive trees, where the root of the
multi-destination tree reuses the same LSP label for traffic of
various EVIs, the tail node MUST use the MPLS labels of the P-Tunnel
and the upstream assigned label which the PE has bound uniquely to
the EVI. The myDisc of the BFD packet is filled with an unique value
allocated by the root to identify the multi-path session.
Govindan, et al. Expires January 5, 2015 [Page 5]
Internet-Draft Govindan July 2014
2.2.1. Bootstrapping BFD sessions at the root of the P2MP tunnel
The P2MP BFD sessions MUST be bootstrapped at the head
[I-D.ietf-bfd-multipoint] as soon as there is one receiver for the
MDT traffic.
2.2.2. Bootstrapping BFD sessions at the tail nodes of the P2MP tunnel
The P2MP BFD sessions MUST be bootstrapped at the tail upon reception
of the P2MP BFD packets from the head. The tail MUST use the P2MP
MDT label to de-multiplex the incoming BFD packet. The BFD session
MAY be destroyed immediately upon leaving Up state.
2.3. Fault Detection of unicast traffic
The mechanisms specified in BFD for MPLS LSPs RFC 5884 [RFC5884] can
be applied to bootstrap and maintain BFD sessions for unicast EVPN
traffic. The discriminators required for de-multiplexing the BFD
sessions MUST be exchanged using MPLS ping specifying the Unicast
EVPN FEC [I-D.jain-l2vpn-evpn-lsp-ping] before starting the BFD
session. This is needed since the MPLS label stack does not contain
enough information to disambiguate the sender of the packet. The
usage of MPLS entropy labels take care of addressing the requirement
of monitoring faults of the various paths of the multi-path server
layer network RFC 6790 [RFC6790]. Each unique realizable path
between the participating PE routers MAY be monitored separately when
entropy labels are used. Alternately, all paths MUST be tracked by
at least one or a fewer number of representative BFD session(s) in
which case the granularity of fault-detection would be coarser. The
PE node receiving the MPLS ping MUST allocate one BFD discriminator
for every unique combination of the source IP address and the tuple
of <unicast FEC, EVPN label>. A node MAY include the instance
identifier of the entropy label,if present to satisfy the requirement
of fault monitoring of specific paths or all realizable paths. Note
that once the BFD session for the EVPN label is UP, either end of the
BFD session MUST NOT change the local discriminator values of the BFD
Control packets it generates, unless it first brings down the session
as specified in RFC 5884 [RFC5884].
3. BFD packet encapsulation
3.1. Using GAL/G-ACh encapsulation without IP headers
3.1.1. Ingress replication
The packet contains the following labels: LSP label (transport) when
not using PHP, the optional entropy label, the BUM label and the SH
label[I-D.ietf-l2vpn-evpn] (where applicable). The G-ACh type is set
Govindan, et al. Expires January 5, 2015 [Page 6]
Internet-Draft Govindan July 2014
to TBD. The discriminator values of BFD are obtained through
negotiation through the out-of-band MPLS ping.
3.1.2. LSM
The packet contains the following labels: label identifying the
P-Tunnel, upstream label which the PE has bound uniquely to the EVI
(for aggregate inclusive trees only). The G-ACh type is set to TBD.
The yourDisc value is set to 0 and the myDisc value is uniquely
generated by the root.
3.1.3. Unicast
The packet contains the following labels: LSP label (transport) when
not using PHP, the optional entropy label and the EVPN Unicast label.
The G-ACh type is set to TBD. The discriminator values of BFD are
obtained through negotiation through the out-of-band MPLS ping.
3.2. Using IP headers
The encapsulation option using IP headers will not be suited for
EVPN, as using different values in the destination IP address for
data and OAM (BFD) packets could cause the BFD packets to follow a
different path than that of data packets. Hence this option MUST NOT
be used for EVPN.
4. 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.
5. Security Considerations
This document does not introduce any new security issues, the
security considerations defined in RFC 5880 [RFC5880] and
[I-D.ietf-bfd-multipoint] apply in this document.
6. IANA Considerations
A new G-Ach Type is requested for for GAL encapsulated BFD as the
existing type [RFC5885] specifically applies to PW-ACH encapsulation.
Govindan, et al. Expires January 5, 2015 [Page 7]
Internet-Draft Govindan July 2014
7. Acknowledgments
We thank Nobo Akiya, Tina Lam, Jose Liste, Mudigonda Mallik and
Gregory Mirsky for their valuable input, discussions and comments.
8. References
8.1. Normative References
[I-D.ietf-bfd-multipoint]
Katz, D. and D. Ward, "BFD for Multipoint Networks",
draft-ietf-bfd-multipoint-03 (work in progress), February
2014.
[I-D.jain-l2vpn-evpn-lsp-ping]
Jain, P., Boutros, S., and S. Salam, "LSP-Ping Mechanisms
for E-VPN and PBB-EVPN", draft-jain-l2vpn-evpn-lsp-ping-03
(work in progress), June 2014.
[ID.vgovindan-mpls-extended-bfd-disc-tlv]
Govindan, V. and N. Akiya, "Label Switched Path (LSP) Ping
Extended Bidirectional Forwarding Detection (BFD)
Discriminator TLV", , July 2014,
<http://tools.ietf.org/html/
draft-vgovindan-mpls-extended-bfd-disc-tlv-00>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)", RFC 5885, June 2010.
8.2. Informative References
[I-D.ietf-l2vpn-evpn]
Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.
Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
evpn-07 (work in progress), May 2014.
Govindan, et al. Expires January 5, 2015 [Page 8]
Internet-Draft Govindan July 2014
[I-D.ietf-l2vpn-pbb-evpn]
Sajassi, A., Salam, S., Bitar, N., Isaac, A., Henderickx,
W., and L. Jin, "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn-07
(work in progress), June 2014.
[I-D.ietf-l2vpn-trill-evpn]
Sajassi, A., Salam, S., Bitar, N., and S. Aldrin, "TRILL-
EVPN", draft-ietf-l2vpn-trill-evpn-01 (work in progress),
October 2013.
[I-D.ietf-mpls-mcast-cv]
Swallow, G., "Connectivity Verification for Multicast
Label Switched Paths", draft-ietf-mpls-mcast-cv-00 (work
in progress), April 2007.
[I-D.salam-l2vpn-evpn-oam-req-frmwk]
Salam, S., Sajassi, A., Aldrin, S., and J. Drake, "E-VPN
Operations, Administration and Maintenance Requirements
and Framework", draft-salam-l2vpn-evpn-oam-req-frmwk-02
(work in progress), January 2014.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012.
8.3. URIs
[1] http://tools.ietf.org/html/draft-vgovindan-mpls-extended-bfd-
disc-tlv-00
Authors' Addresses
Vengada Prasad Govindan
Cisco Systems
Email: venggovi@cisco.com
Samer Salam
Cisco Systems
Email: ssalam@cisco.com
Ali Sajassi
Cisco Systems
Email: sajassi@cisco.com
Govindan, et al. Expires January 5, 2015 [Page 9]
