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]