Proactive fault detection in E-VPN
draft-vgovindan-l2vpn-evpn-bfd-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
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 | Vengada Prasad Govindan , Samer Salam , Ali Sajassi | ||
| Last updated | 2013-10-19 | ||
| 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-vgovindan-l2vpn-evpn-bfd-00
INTERNET-DRAFT Vengada Prasad Govindan
Intended Status: Standards Track Samer Salam
Expires: April 22, 2014 Ali Sajassi
Cisco
October 19, 2013
Proactive fault detection in E-VPN
draft-vgovindan-l2vpn-evpn-bfd-00
Abstract
This document proposes a proactive, in-band network OAM mechanism to
detect connectivity faults that affect unicast and multi-destination
paths in an E-VPN 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 to IETF 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 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
Govindan et al Expires April 22, 2014 [Page 1]
INTERNET DRAFT Proactive fault detection in E-VPN October 19, 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope of fault detection mechanisms proposed in this
document . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Fault Detection of BUM traffic using ingress replication
(MP2P) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Fault Detection of BUM traffic using P2MP tunnels (LSM) . . 4
2.2.1 Bootstrapping BFD sessions at the root of the P2MP
tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Bootstrapping BFD sessions at the tail nodes of the
P2MP tunnel . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Fault Detection of unicast traffic (P2P) . . . . . . . . . . 5
3 BFD packet encapsulation . . . . . . . . . . . . . . . . . . . . 5
3.1 Encapsulation using IP headers . . . . . . . . . . . . . . . 5
3.1.1 Ingress replication . . . . . . . . . . . . . . . . . . 5
3.1.2 LSM . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.3 Unicast . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Using GAL/G-Ach encapsulation without IP headers . . . . . . 6
3.2.1 Ingress replication . . . . . . . . . . . . . . . . . . 6
3.2.2 LSM . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.3 Unicast . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Scalability Considerations . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Normative References . . . . . . . . . . . . . . . . . . . 7
8.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1 Introduction
Govindan et al Expires April 22, 2014 [Page 2]
INTERNET DRAFT Proactive fault detection in E-VPN October 19, 2013
[EVPNOAM] outlines the OAM requirements of Ethernet VPN networks
[EVPN]. This document proposes mechanisms for proactive fault
detection at the network OAM layer of E-VPN. These mechanisms could
either be deployed for periodic and proactive monitoring, or be
triggered by specific events to aid troubleshooting. E-VPN fault
detection mechanisms need to consider unicast and BUM traffic
separately since they map to different FECs in E-VPN. Since BUM
traffic can be transported using MP2P or P2MP tunnels, this document
proposes slightly different fault detection mechanisms to suit each
type using the principles of Point-to-multipoint BFD[P2MPBFD]. Please
note that this document uses the term E-VPN loosely to include [E-
VPN], [PBB-EVPN] as well as [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].
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
The approach takes advantage of the inclusive multicast route used
in E-VPN to advertise the multi-destination FEC for bootstrapping
the BFD sessions. Earlier approaches for P2MP BFD [MPLSCVBFD] 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 E-
VPN 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.
Govindan et al Expires April 22, 2014 [Page 3]
INTERNET DRAFT Proactive fault detection in E-VPN October 19, 2013
2.1.1 Bootstrapping BFD sessions at the head of the MP2P tunnel
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 [MPLSEL] for an inclusive multicast FEC. A P2MP BFD
session could be identified at the tail node using the source IP
(if present in the BFD packet) and the attributes of the inclusive
multicast FEC (the BUM label, label stack and optionally the
entropy label). To simplify such a lookup, we take advantage of the
fact that the head replicates a BUM packet for each tail by
inserting unique discriminators in each copy of the (replicated)
BFD packet. These discriminators are exchanged out-of-band using
MPLS ping [BFD-MPLS] before the start of the BFD session. The head
PE performing ingress replication MUST initiate the LSP ping using
the inclusive multicast FEC [EVPNPING] upon receiving an inclusive
multicast route from a tail. The receiving tail MUST generate a
unique discriminator to identify the tuple of inclusive multicast
FEC and the source IP address. This discriminator MUST be
communicated back to the head using the response to the MPLS ping.
The head MUST insert the corresponding discriminator generated by
the tail for each copy of the BFD packet in the yourDisc field of
the BFD header. It is obvious that the MPLS ping to perform
discriminator exchange is required only once to bootstrap the
session.
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 [P2MPBFD].
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 [P2MPBFD] 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 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 multipath session.
Govindan et al Expires April 22, 2014 [Page 4]
INTERNET DRAFT Proactive fault detection in E-VPN October 19, 2013
2.2.1 Bootstrapping BFD sessions at the root of the P2MP tunnel
The P2MP BFD sessions MUST be bootstrapped at the head [P2MPBFD] 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 PMP 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.
2.3 Fault Detection of unicast traffic (P2P)
The mechanisms specified in BFD for MPLS LSPs [BFD-MPLS] can be
applied to bootstrap and maintain BFD sessions for unicast EVPN
traffic. The discriminators required for de-multiplexing the BFD
sessions can be exchanged using MPLS 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 [MPLSEL].
3 BFD packet encapsulation
Two BFD encapsulations are possible [VCCV-BFD].
3.1 Encapsulation using IP headers
3.1.1 Ingress replication
The packet contains the following labels: LSP label (transport)
when not using PHP, BUM label, SH label (where applicable) and the
optional entropy label. The source IP of the packet is set to that
of the originating PE. The destination IP MUST be 127/8 for IPv4 or
0:0:0:0:0:FFFF: to 127.0.0.0/104 for IPv6. The UDP port indicates
the type of the payload as BFD control packet. 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: P-Tunnel label, upstream
allocated label which the PE has bound uniquely to the EVI
(aggregate inclusive tress only). The source IP of the packet is
set to that of the originating PE. The destination IP MUST be 127/8
for IPv4 or 0:0:0:0:0:FFFF: to 127.0.0.0/104 for IPv6. The UDP port
Govindan et al Expires April 22, 2014 [Page 5]
INTERNET DRAFT Proactive fault detection in E-VPN October 19, 2013
indicates the type of the payload as BFD control packet. 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, E-VPN Unicast label and the optional entropy
label. The source IP of the packet is set to that of the
originating PE. The destination IP MUST be 127/8 for IPv4 or
0:0:0:0:0:FFFF: to 127.0.0.0/104 for IPv6. The UDP port indicates
the type of the payload as BFD control packet.The discriminator
values of BFD are obtained through negotiation through the out-of-
band MPLS ping.
3.2 Using GAL/G-Ach encapsulation without IP headers
3.2.1 Ingress replication
The packet contains the following labels: LSP label (transport)
when not using PHP, BUM label and the SH label (where applicable).
The G-Ach type is set to 0x0007 [VCCV-BFD]. The discriminator
values of BFD are obtained through negotiation through the out-of-
band MPLS ping.
3.2.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
0x0007 [VCCV-BFD]. The yourDisc value is set to 0 and the myDisc
value is uniquely generated by the root.
3.2.3 Unicast
The packet contains the following labels: LSP label (transport)
when not using PHP, E-VPN Unicast label and the optional entropy
label. The G-Ach type is set to 0x0007 [VCCV-BFD]. The
discriminator values of BFD are obtained through negotiation
through the out-of-band MPLS ping.
4. Scalability Considerations
The mechanisms proposed in this draft could either be run
periodically to monitor the network proactively or in response to
specific network events to aid troubleshooting in a demand-driven
Govindan et al Expires April 22, 2014 [Page 6]
INTERNET DRAFT Proactive fault detection in E-VPN October 19, 2013
manner. Since the mechanisms proposed could affect the load of the
network elements as networks scale to support a large number of
EVIs, caution needs to be exercised in choosing the parameters and
the interfaces on which these mechanisms are enabled.
5. Security Considerations
This document does not introduce any new security issues, the
security considerations defined in [BFD] and [P2MPBFD] apply in
this document.
6 IANA Considerations
No new requests are made to IANA by this document.
7. Acknowledgments
We thank Tina Lam, Jose Liste and Mudigonda Mallik for their
valuable input, discussions and comments.
8 References
8.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[VCCV-BFD] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional
Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit Connectivity Verification (VCCV)", RFC 5885, June
2010.
[P2MPBFD] Katz, D. and D. Ward, "BFD for multipoint networks",
draft-ietf-multipoint-01.txt, work in progress,
June 2013.
[EVPNOAM] Salam et al, "E-VPN OAM Requirements and Framework",
draft-salam-l2vpn-evpn-oam-req-frmwrk-00.txt,
work in progress, October 2012.
Govindan et al Expires April 22, 2014 [Page 7]
INTERNET DRAFT Proactive fault detection in E-VPN October 19, 2013
[EVPNPING] Jain et al, "LSP-Ping Mechanisms for E-VPN and PBB-EVPN" ,
draft-jain-l2vpn-evpn-lsp-ping-01,
work in progress, February 2013.
[MPLSCVBFD] Swallow et al, "Connectivity Verification for Multicast
Label Switched Paths",
draft-ietf-mpls-mcast-cv-00
work in progress, April 2007.
8.2 Informative References
[EVPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN",
draft-ietf-l2vpn-evpn-02.txt, work in progress,
October 2012.
[PBB-EVPN] Sajassi et al, "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn-05,
July 2013.
[TRILL-EVPN]
Sajassi et al., "TRILL-EVPN",
draft-ietf-l2vpn-trill-evpn-00.txt,
work in progress, June 2012.
[MPLSEL] Kompella et al,
"The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012.
Authors' Addresses
Vengada Prasad Govindan
EMail: venggovi@cisco.com
Samer Salam
EMail: ssalam@cisco.com
Ali Sajassi
EMail:sajassi@cisco.com
Govindan et al Expires April 22, 2014 [Page 8]