Network Working Group V. Hegde Internet-Draft R. Chandrasekar Expires: September 6, 2012 Juniper Networks March 5, 2012 Multipoint BFD for MPLS draft-chandra-hegde-mpoint-bfd-for-mpls-00.txt Abstract Recent proposals have extended the use of Bidirectional Forwarding Detection to detect data plane failures in multipoint networks. One desirable application of Multipoint BFD [MP-BFD] is to detect data path failures in point-to-multipoint Label Switched Paths (P2MP LSPs). The scope of this document is to discuss the applicability of multipoint BFD for fault detection in the data plane of P2MP LSPs. The document extends the techniques and mechanisms mentioned in [RFC5884] and applies them to MPLS P2MP environment. 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 September 6, 2012. Copyright Notice Copyright (c) 2012 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 Hegde & Chandrasekar Expires September 6, 2012 [Page 1] Internet-Draft Multipoint BFD for MPLS March 2012 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2. BFD for P2MP LSPs: Motivation . . . . . . . . . . . . . . . . 4 3. Notes on bootstrapping Multipoint BFD for P2MP LSPs . . . . . 5 4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Periodic echo requests with "Do not reply" . . . . . . . . 6 4.2. Application driven Ping . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Hegde & Chandrasekar Expires September 6, 2012 [Page 2] Internet-Draft Multipoint BFD for MPLS March 2012 1. Introduction Application of BFD for fault detection in the data path of point-to- point MPLS LSPs is addressed in [RFC5884]. Since point-to-multipoint LSPs are not less vulnerable to data path failures than their point- to-point counterparts, this document extends the techniques used in [RFC5884] such that they can be applied to P2MP LSPs. This document stresses the reuse of existing LSP ping mechanism to bootstrap the BFD sessions for point-to-point LSPs and its application to point-to- multipoint LSPs and multipoint BFD in order to simplify implementation and network operations. 1.1. Terminology The terminology used in this document for MPLS OAM can be found in [RFC4379]. The terminology for multipoint BFD can be found in [MP-BFD]. 1.2. Conventions 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 [RFC5884]. Hegde & Chandrasekar Expires September 6, 2012 [Page 3] Internet-Draft Multipoint BFD for MPLS March 2012 2. BFD for P2MP LSPs: Motivation As with P2P LSPs, there is a requirement for faster detection of data plane failures in P2MP LSPs. Existing mechanisms like P2MP LSP ping and P2MP trace route are expensive in terms of the amount of control plane processing required and are catered towards fault isolation or on-demand fault detection at or by the ingress LSR. Multipoint BFD offers a way for the egress LSR to detect a loss of connectivity to a particular ingress along the multicast data path. Some of the advantages of BFD as listed in [RFC5884] which also apply to P2MP LSPs are: a) Support for fault detection for a greater number of LSPs. b) Fast detection. Considering how BFD is most suitable to be implemented in the hardware or firmware due to its fixed packet format, BFD can be used to achieve fault detection with sub-second granularity. There are several advantages of sub-second detection of data plane failures in any P2MP LSP at the the egress LSR, a couple of them being: 1) Multicast Live-Live For applications that make use of multicast live-live where traffic is pulled from two different streams and merged at the egress, fast detection of failures on any one of the streams at the egress of the P2MP LSP might be desirable to provide seamless service by switching over to the backup stream to avoid traffic interruptions. Multipoint BFD is a suitable choice to detect these kinds of data path failures and to notify the applications of these failures. 2) LSPs with discontinuous traffic flow One way of doing OAM over a P2MP LSP today is for an application to monitor the data traffic coming over the P2MP LSP and correlate that with the health of the data path. For applications that do not have continuous traffic flowing, it is desirable to monitor the connectivity of the data path by some other means. Multipoint BFD can be used for this purpose and the detection can be done at the LHR instead of the receiver. Hegde & Chandrasekar Expires September 6, 2012 [Page 4] Internet-Draft Multipoint BFD for MPLS March 2012 3. Notes on bootstrapping Multipoint BFD for P2MP LSPs The procedures of Multipoint BFD are described in [MP-BFD]. Although Multipoint BFD tries to be generic in nature regardless of the technology used to establish the multipoint tunnel, for P2MP LSPs there are certain scenarios where making the association of an incoming BFD packet with its corresponding P2MP LSP becomes a challenge at the egress. For example in case of Penultimate Hop Popping (PHP) for a single label stack P2MP LSP, incoming BFD packets at the egress do not contain enough information to associate them with a particular P2MP LSP. A similar problem of bootstrapping was encountered when attempting to run BFD over P2P LSPs. These problems have been resolved by following the procedures mentioned in [RFC5884].The procedures explained in [RFC5884] can be applied to P2MP LSP ping to bootstrap the multipoint BFD session. Although the mechanisms of [RFC5884] when appliedto P2MP LSP Ping and Multipoint BFD would work, it may not necessarily be optimal for a P2MP environment, primarily because: a) Unidirectional Nature. Multipoint BFD by nature can be unidirectional. Multipoint BFD in its primary form is designed for the egress LSR to detect a loss of connectivity to the ingress along the multipoint path along with providing the ingress with some optional mechanisms to track the connectivity to certain egress LSRs. When running multipoint BFD in this form, the ingress does not have any need to learn the BFD discriminator of the egress to establish the BFD session. Even if the ingress does wish to track the connectivity to certain egress LSRs, this would happen over the unicast path and if the procedures of [MP-BFD] are followed then the unicast BFD sessions can be established without any explicit out of band bootstrapping. b) Scalability The procedures of P2MP LSP ping are described in [RFC6425]. Although [RFC6425] talks about various mechanisms to rate limit the echo reply messages coming into the ingress, in a large deployment, it may not be optimal to solicit echo replies from all the egress LSRs. Soliciting replies from all the egress routers may lead to the ingress being flooded by a large number of messages in a short duration. Hegde & Chandrasekar Expires September 6, 2012 [Page 5] Internet-Draft Multipoint BFD for MPLS March 2012 4. Proposed Solutions 4.1. Periodic echo requests with "Do not reply" Applying the procedures of [RFC5884]to P2MP LSPs, periodic P2MP LSP Ping echo request messages MUST be sent by the ingress LSR to the egress LSR along the same data path as the P2MP LSP. These echo messages SHOULD contain the local discriminator of the Multipoint BFD session established by the ingress LSR for the P2MP LSP. The rate of generation of echo request messages must be considerably slower than the rate of generation of BFD packets at the ingress LSR. If the primary purpose of running P2MP LSP Ping is to facilitate the establishment of the BFD session and its association with the corresponding P2MP LSP at the egress LSR, then an implementation MAY set the value of the Reply Mode field in the message to 1 (Do Not Reply) thus indicating the egress LSRs to suppress the generation of echo reply messages. By doing so, an implementation avoids the possibility of congestion at the ingress LSR by not soliciting reply messages from all the egress LSRs. Note that even when P2MP LSP Ping is used for bootstrapping BFD sessions, periodic transmission of the echo request messages are required by the ingress LSR primarily because in a P2MP LSP environment, there are valid scenarios where the ingress LSR may not be aware of the existence of different egress LSRs. In such a case, the ingress LSR may not have sufficient information to decide when to send out the LSP ping with the BFD discriminator to bootstrap the BFD session at the newly attached egress LSRs. By periodically transmitting LSP Ping echo request messages, the ingress LSR ensures that any newly attached egress LSR will be able to bind the BFD session to the P2MP LSP when it receives the next periodic echo request message. It is highly possible that an egress LSR will start receiving the multipoint BFD packets before the LSP ping from the ingress. How an implementation chooses to handle these incoming BFD packets is outside the scope of this document and is left to the implementation. The egress LSR SHOULD follow the procedures mentioned in [RFC5884] to validate the PING packet and then use the discriminator in the P2MP echo request message to either bind an existing BFD session to the P2MP LSP or setup a new BFD session by accepting BFD packets with the discriminator value it has received in the echo request message from the ingress. 4.2. Application driven Ping The rate of generation of periodic echo requests by the ingress LSR is considerably slower than the rate of generation of BFD packets Hegde & Chandrasekar Expires September 6, 2012 [Page 6] Internet-Draft Multipoint BFD for MPLS March 2012 because the processing of PING packet is a control plane processing extensive operation. For P2MP LSPs, if an implementation of P2MP ping which is used for bootstrapping the BFD session has chosen to solicit replies from all the egress LSRs, then it is crucial that these ping packets are rate limited to avoid congestion at the ingress LSR. Slowing down the rate of generation of Ping packets also in turn slows down the bootstrapping of the BFD sessions at the egress LSRs who might have newly attached themselves to the P2MP LSP. This may not be desirable for certain applications which may want to leverage Multipoint BFD to fast detect failures on the data path of a P2MP LSP at the egress. Application driven expedited PING is one way to solve this problem. The decision as to when to send the expedited PING is left to the implementation and outside the scope of this document, one use of expedited ping is that if an application running on the ingress LSR can detect a new node attaching itself as the egress to its P2MP LSP, then an implementation MAY choose to send an expedited PING packet over the P2MP data path. An implementation MAY also choose to solicit an echo reply from one or a subset of egress LSRs using the Egress Address P2MP Responder Sub-TLV(as described in [RFC6425]) in the expedited echo request messages, however if an implementation chooses to solicit replies from a subset of egress LSRs using the P2MP LSP Ping, then it MUST ensure to avoid congestion at or near the ingress when the replies arrive. Periodic echo requests as described in section 4.1 can be used in conjunction with application driven epedited ping to provide an optimal solution to bootstrap BFD sessions.Periodic messages ensures that in a dynamic P2MP LSP environment, where the egress LSRs are constantly attaching or detaching themselves from the P2MP LSPs, the association of BFD packets to a P2MP LSP is possible at the egress LSR. For applications running in the ingress that do track the egress LSRs of a P2MP LSP, expedited PING could be used to quickly bootstrap the BFD session at the egress without having to wait for the next periodic PING, while doing so the application MAY also choose to solicit replies from a subset of the egress LSRs. Hegde & Chandrasekar Expires September 6, 2012 [Page 7] Internet-Draft Multipoint BFD for MPLS March 2012 5. Security Considerations No new security issues are introduced beyond those that are described in [RFC6425] and [MP-BFD]. Hegde & Chandrasekar Expires September 6, 2012 [Page 8] Internet-Draft Multipoint BFD for MPLS March 2012 6. IANA Considerations This draft does not have any request for IANA. Hegde & Chandrasekar Expires September 6, 2012 [Page 9] Internet-Draft Multipoint BFD for MPLS March 2012 7. Acknowledgments The authors would like to acknowledge the authors of [RFC6425] and the authors of [RFC5884] for their work, which is substantially re- used in this document. The authors would like to thank Santosh PK, Shivakumar Channalli and Harish Sitaraman for their reviews and feedback on this material. Hegde & Chandrasekar Expires September 6, 2012 [Page 10] Internet-Draft Multipoint BFD for MPLS March 2012 8. Normative References [MP-BFD] Katz, D. and D. Ward, "BFD for Multipoint Networks", draft-ietf-bfd-multipoint-00 (work in progress), October 2011. [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [RFC6425] Saxena, S., 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, November 2011. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. Hegde & Chandrasekar Expires September 6, 2012 [Page 11] Internet-Draft Multipoint BFD for MPLS March 2012 Authors' Addresses Vikas Hegde Juniper Networks Embassy Business Park Bangalore, KA 560093 India Email: vikashegde@juniper.net Chandrasekar R Juniper Networks Embassy Business Park Bangalore 560093 India Email: csekar@juniper.net Hegde & Chandrasekar Expires September 6, 2012 [Page 12]