Network Working Group E. Salahuddin Internet Draft J. Karthik Expires: August 2007 Cisco Systems February 07 Motivation for Benchmarking BFD Protocol Implementations Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. 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 Abstract This document describes the motivation for benchmarking the Bidirectional Forwarding Detection (BFD) protocol. The BFD protocol is a relatively new protocol intended to detect failures in the bidirectional path between two network elements, with potentially very low latency [BFD, BFD-GEN]. The BFD protocol is being implemented by several vendors and is being deployed extensively by the service providers. Hence, it is imperative that common understanding is established for performance and conformance benchmarks as well as interoperability. This draft seeks to generate Salahuddin, Karthik Expires August, 2007 [Page 1] Internet-Draft Motivation for Benchmarking February 2007 BFD Protocol Implementations interest on this topic in the working group. If there is sufficient interest on this topic, drafts that address the Methodology and Terminology for the BFD protocol could be proposed; before BMWG could make this an official working group item. Table of Contents 1. Introduction...................................................3 2. Existing definitions...........................................3 3. Key BFD Benchmarks.............................................4 3.1. Detection Time............................................4 3.2. Mode of operation.........................................4 3.3. Echo function capability..................................4 3.4. Control Plane Independence................................4 3.5. Minimum Rx Interval supported.............................4 3.6. Minimum Tx Interval supported.............................4 3.7. Minimum Echo Rx Time......................................4 3.8. Max number of BFD sessions supported......................4 3.9. Multi-Hop BFD sessions....................................4 3.10. Authentication Support...................................5 4. Key BFD Use Scenarios..........................................5 5. Security Considerations........................................5 6. Acknowledgements...............................................5 7. References.....................................................5 7.1. Normative References......................................5 7.2. Informative References....................................6 8. Author's Address...............................................6 Salahuddin, Karthik Expires August, 2007 [Page 2] Internet-Draft Motivation for Benchmarking February 2007 BFD Protocol Implementations 1. Introduction An increasingly important requirement of networking equipment is the ability to detect a forwarding failure between two systems in order to establish alternative paths more quickly. The BFD protocol addresses this need by providing low-overhead and short-duration detection of failures in the path between two network elements. Both rapid-detection and low-overhead are open to individual interpretation, in terms of what they entail and how to verify them. So, it is important to establish a benchmarking framework for this protocol. An additional goal of the BFD protocol is to provide a single mechanism that can be used for liveliness detection over any media, at any protocol layer and with a wide range of detection time and overhead. This capability makes it further necessary to have a set of guidelines that are well understood and clearly defined to benchmark the key attributes of the BFD protocol. The BFD protocol is also being proposed for multi-hop virtual links like MPLS LSPs, AToM VCs and others [BFD-MPLS, BFD-MHOP]. This is another area which needs to be characterized and benchmarked for comparison with the single-hop behavior of an implementation. For reasons mentioned above, this document is being put forward to initiate discussion on the topic and invite comments. In the process generating enough interest that may result in future documents that address the benchmarking needs, scenarios, procedures and terminology of the BFD protocol. A set of key benchmarks and use cases are also discussed in this document. 2. Existing definitions For the sake of clarity and continuity this RFC adopts the template for definitions set out in Section 2 of RFC 1242. Definitions are indexed and grouped together in sections for ease of reference. 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. The reader is encouraged to be familiar with the commonly used BFD terms, some of which are defined in the appendix. Salahuddin, Karthik Expires August, 2007 [Page 3] Internet-Draft Motivation for Benchmarking February 2007 BFD Protocol Implementations 3. Key BFD Benchmarks 3.1. Detection Time Shortest detection time supported for a certain scale deployment. 3.2. Mode of operation The mode of operation currently enabled on the device (Demand mode vs. Asynchronous mode). 3.3. Echo function capability Whether or not a device under test (DUT) can initiate and respond to the Echo function request. 3.4. Control Plane Independence Ability of an implementation to continue to operate when there is a disruption in the control plane. 3.5. Minimum Rx Interval supported This is the interval at which a DUT is capable of receiving control messages from the BFD session peer. 3.6. Minimum Tx Interval supported This benchmark describes the smallest interval between 2 transmitted BFD control messages that a device is capable of supporting. 3.7. Minimum Echo Rx Time This is the minimum interval between received BFD Echo packets that a system is capable of supporting. 3.8. Max number of BFD sessions supported The number of BFD sessions that can be simultaneously supported by the DUT. 3.9. Multi-Hop BFD sessions This benchmark verifies the capability of an implementation to support multi-hop BFD adjacency. Salahuddin, Karthik Expires August, 2007 [Page 4] Internet-Draft Motivation for Benchmarking February 2007 BFD Protocol Implementations 3.10. Authentication Support This benchmark verifies if the authentication is supported or not, and if it is supported, what types of authentication are supported. 4. Key BFD Use Scenarios 0 – AtoM VCs 1 – L3VPNs 2 – TE Tunnels 3 – Routing Protocols 4 – GRE/L2TPv3 5. Security Considerations Documents of this type do not directly affect the security of the Internet or of corporate networks as long as benchmarking is not performed on devices or systems connected to operating networks. 6. Acknowledgements We would like to acknowledge contributions from Azhar Sayeed and Aamer Akhter. We also want to thank Jay Bromander and Rajiv Papneja for the initial review. 7. References 7.1. Normative References [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", draft-ietf-bfd-base-05.txt, June, 2006. [BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single Hop)", draft-ietf-bfd-v4v6-1hop-05.txt, June, 2006. Salahuddin, Karthik Expires August, 2007 [Page 5] Internet-Draft Motivation for Benchmarking February 2007 BFD Protocol Implementations [BFD-GEN] Katz, D., and Ward, D., "Generic Application of BFD”, draft-ietf-bfd-v4v6-1hop-05.txt, June, 2006. [BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs", draft-ietf-bfd-mpls-03.txt, June, 2006. [BFD-MHOP] D. katz, D. Ward, "BFD for Multihop Paths", draft- ietf-bfd-multihop-04.txt [RFC-BENCH] Bradner, S. and McQuaid, J., "Benchmarking Methodology for Network Interconnect Devices", RFC 2544. 7.2. Informative References [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. 8. Author's Address Esa Salahuddin Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 USA Phone: +1 978 936 1569 Email: esa@cisco.com Jay Karthik Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 USA Phone: +1 978 936 0533 Email: jkarthik@cisco.com Salahuddin, Karthik Expires August, 2007 [Page 6] Internet-Draft Motivation for Benchmarking February 2007 BFD Protocol Implementations Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Salahuddin, Karthik Expires August, 2007 [Page 7] Internet-Draft Motivation for Benchmarking February 2007 BFD Protocol Implementations Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Salahuddin, Karthik Expires August, 2007 [Page 8]