INTERNET-DRAFT Mingui Zhang Intended Status: Informational Zuliang Wang Mach Chen Huawei Expires: January 5, 2015 July 4, 2014 Use Cases Requiring New Features of BFD draft-zhang-bfd-new-use-cases-00.txt Abstract This document describes some use cases arising from the deployment of BFD. These use cases are expected by ISPs but not supported by current BFD yet. Requirements are developed on basis of these use cases so that they can be taken into consideration in the future update of the 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) 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 Mingui Zhang, et al Expires January 5, 2015 [Page 1] INTERNET-DRAFT Use Cases Requiring New BFD Features July 4, 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Use Case #1: Reliable Detection for Multipath . . . . . . . 3 3.2. Use Case #2: Application Consistence . . . . . . . . . . . 4 3.3. Use Case #3: Capability Inquiry and Feedback . . . . . . . 5 3.4. Use Case #4: State Relay . . . . . . . . . . . . . . . . . 6 3.5. Use Case #5: Detection of Asymmetric LSPs . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Mingui Zhang, et al Expires January 5, 2015 [Page 2] INTERNET-DRAFT Use Cases Requiring New BFD Features July 4, 2014 1. Introduction BFD is able to detect a network fault with a very low latency. It is designed to be independent of any media, data protocols, and routing protocols [RFC5880]. Today, it has been widely deployed in ISPs' networks and used by various applications. Requirements for those BFD core use cases used to be generally fulfilled. However, there are also some use cases that do not fit current BFD. This document reveals five use cases arising from the real deployment of BFD but not supported yet. From these use cases, some basic requirements are extracted to be considered in the future when BFD is to be updated. This document aims to provide some information for the discussion on whether these use cases can be handled with a smooth update of the BFD protocol. 2. Acronyms and Terminology 2.1. Acronyms BFD: Bidirectional Forwarding Detection 2.2. 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]. Familiarity with [RFC5880] is assumed in this document. 3. Use Cases 3.1. Use Case #1: Reliable Detection for Multipath +----+ +----+ +----+ +----+ | +------+ R2 +------+ R3 +------+ | | | +----+ +----+ | | | R1 | | R5 | | | +----+ | | | +------+ R4 +------------------+ | +----+ +----+ +----+ Figure 3.1. An example topology of BFD for OSPF ECMP Carrier networks widely adopt multipath techniques between two endpoints for the purpose of higher bandwidth and resilience, such as ECMP in OSPF/ISIS, Ethernet Link Aggregation (LAG), and MPLS Link Bundling [RFC4201]. If BFD is deployed on network devices, the Mingui Zhang, et al Expires January 5, 2015 [Page 3] INTERNET-DRAFT Use Cases Requiring New BFD Features July 4, 2014 interface cards will be the components sending and receiving BFD control packets. If just one BFD session is set up for the pair of endpoints of the multipath, it's likely that the sending and receiving interface cards of data packets assigned by the flow-based load balance are not corresponding to those of BFD packets. Figure 3.1 shows an example of BFD for OSPF ECMP. Suppose BFD is detecting the data path R1-R2-R3-R5 while R1 chooses the data path R1-R4-R5 as the forwarding path. The detection can't be accurate. In [RFC7130], for each enabled address family and each member link, a micro-BFD session is set up. Then the BFD packets can be demultiplexed based on the "Your Discriminator" field. However, this technique is only applicable for LAG links. For a plain multipath, logical member links usually can't be one-to-one mapped to those pairs of interface cards. Take the following figure for example, the head node R1 has three interface cards attached to the multipath, while the tail node R5 has two interface cards attached to the multipath. +----+ +----+ +----+ +----+ | +------+ R2 +------+ R3 +------+ | | | +----+ +----+ | | | R1 | +----+ | R5 | | +------+ | | | | | | R4 +------------------+ | | +------+ | +----+ +----+ +----+ Figure 3.2. Another example topology of BFD for OSPF ECMP Some operators have BFD running on the Master Board Card of the two endpoints. This introduces extra overhead to the Master Board and brings new security risk to client applications. The Master Board Card may change to slave mode, which will be mistakenly detected as a failure of the multipath. In this use case, unless all interface cards fail at one end, carriers expect the multipath works, therefore BFD should not report a failure. Hence, BFD is required to be able to identify active interface cards on two endpoints. The endpoints should set up one session for the multipath based on any pair of active interface cards. 3.2. Use Case #2: Application Consistence Mingui Zhang, et al Expires January 5, 2015 [Page 4] INTERNET-DRAFT Use Cases Requiring New BFD Features July 4, 2014 +----+ IGP/PIM/RSVP IGP/PIM/RSVP +----+ | R1 +------------------------------+ R2 | +----+ +----+ Figure 3.3. Client applications of the BFD are inconsistent Endpoint subscribes the BFD detection locally. If the two endpoints subscribing one BFD session with different applications while different applications claim different detection requirements, the BFD may malfunction. Take Figure 3.3 as an example, the pair of interface cards on R1 and R2 are multiply configured with IGP/PIM/RSVP. Assume IGP requires a transmit interval of 10 milliseconds and a detection multiplier of 3 while PIM requires a transmit interval of 100 milliseconds and a multiplier of 5. Finally, the BFD session may achieve a detection time of 500 milliseconds. The two endpoints are required to negotiate the detection requirements of the applications subscribing the same BFD session. If these requirements are inconsistent, the BFD session SHOULD not be established before the inconsistence is resolved. 3.3. Use Case #3: Capability Inquiry and Feedback If the local system restarts, it may resume the BFD session. Suppose the link has been failed or the peer has no resources to create the BFD session or the peer had been taken down administratively during the absence of the local system. Since no BFD control packets will be received from the peer system, the BFD will report a Down state. Rather, the real state of the forwarding path can either be Down or Up. +----+ capability inquiry-> +----+ | R1 +------------------------------+ R2 | +----+ <-able/unable/no response +----+ Figure 3.4. BFD capability inquiry and feedback The local system is required to inquire the peer's BFD capability when the BFD session is resumed after the system reboots. The peer is required to feedback whether the BFD is able to be created as required. If the peer can establish the BFD session as required, the remote system MUST send a BFD Control packet in the detection time with the State field set to anything other than Up. This is shown in Figure 3.4. o If the peer cannot establish the BFD session because it does not support the detection as required or it does not have the resource anymore to establish the BFD session or the BFD has been taken down Mingui Zhang, et al Expires January 5, 2015 [Page 5] INTERNET-DRAFT Use Cases Requiring New BFD Features July 4, 2014 administratively, the peer MUST feedback it is unable to establish the session. If the feedback is received, the BFD MUST not report a Down state of the forwarding path. It's up to the application to determine the state of the forwarding path. o If no feedback is received from the peer in the detection time, the BFD will continue to report to the application that the forwarding path is in Down state. It's required that the above update is supported by both peering systems. In other words, this update is not backward compatible. 3.4. Use Case #4: State Relay +----+ L2VPN +----+ L3VPN +----+ | R1 +-----------+ R2 +-------------+ R3 | +----+<-BFD S1-->+----+<--BFD S2--->+----+ | | |<--------BFD S1+S2----------->| Figure 3.5. BFD session concatenation End to end forwarding paths mixed with L2VPN and L3VPN tunnels are widely adopted in IPRAN. As shown in Figure 3.5, the tunnel between R1 and R2 and the tunnel between R2 and R3 are connected end-to-end in series. These three endpoints can establish two separate BFD sessions to detect the whole forwarding path. However, it's impossible for R1 and R3 to establish a single BFD session between each other. When the L2VPN tunnel fails, R1 and R2 are disconnected but R3 is unaware of the failure. R2 has to resort to the control plane of L3VPN to disseminate the failure. For example, R2 can withdraw the VPN route through BGP [RFC4364]. This will trigger the reconvergence of L3VPN. Usually, the reconvergence is slow and traffic being sent from R3 to R1 will suffer from a long time period of interruption. Section 6.8.17 of [RFC5880] provides the Concatenated Paths mechanism. R2 can propagate the state of the BFD session S1 to S2 through the diagnostic code. However, the indication of the failure requires the participation of the interworking system R2, which may become a heavy overhead when lots of paths need be concatenated. While this happens often in IPRAN. In this use case, carriers expect the state change of BFD session S1 is relayed to R3 without the participation of the interworking system R2. R3 can immediately sense that R1 is not reachable and stop sending traffic to an obvious black-hole. It's also required that the Mingui Zhang, et al Expires January 5, 2015 [Page 6] INTERNET-DRAFT Use Cases Requiring New BFD Features July 4, 2014 relations of the concatenation paths are relayed to R3 by R2 as well. In other words, R2 need transmit the correspondence (mapping) between the concatenated BFD sessions to R3 through the BFD control packet. 3.5. Use Case #5: Detection of Asymmetric LSPs A bidirectional LSP is probably adopting different forwarding paths for different directions. Suppose the ingress LSR set up the BFD session with Echo function enabled. When the echo packets are looped back, the other system chooses the forwarding path by default according to the IP forwarding path. If this forwarding path is different to the reverse forwarding path of the LSP, the BFD detection will be inaccurate. The ingress LSR should be able to advertise in the BFD control packets whether the LSP reverse forwarding path should be used as the forwarding path for echo packets. If the ingress LSR is requiring the LSP reverse path as the forwarding path for echo packets, the egress LSR MUST loop back the echo packets according to the reverse path rather than the default IP forwarding path. 4. Security Considerations This document raises no new security issues. 5. IANA Considerations This document requires no IANA actions. RFC Editor: please remove this section before publication. Acknowledgements Authors would like to thank the comments and suggestions from Marc Binderberger and Xudong Zhang. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. Mingui Zhang, et al Expires January 5, 2015 [Page 7] INTERNET-DRAFT Use Cases Requiring New BFD Features July 4, 2014 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. [RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010. [RFC7130] M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M. Binderberger, Ed., J. Haas, Ed., "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", RFC 7130, February 2014. 6.2. Informative References [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010. Mingui Zhang, et al Expires January 5, 2015 [Page 8] INTERNET-DRAFT Use Cases Requiring New BFD Features July 4, 2014 Author's Addresses Mingui Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District, Beijing 100095 P.R. China Email: zhangmingui@huawei.com Zuliang Wang Huawei Technologies No. 156 Beiqing Rd. Haidian District, Beijing 100095 P.R. China Email: zuni.wang@huawei.com Mach(Guoyi) Chen Huawei Technologies No. 156 Beiqing Rd. Haidian District, Beijing 100095 P.R. China EMail: mach@huawei.com Mingui Zhang, et al Expires January 5, 2015 [Page 9]