BMWG working group Rajiv Asati Internet Draft Cisco Category: Informational Carlos Pignataro Expires: May 2010 Cisco ????? November 9, 2009 Reset Characterization draft-asati-bmwg-reset-00 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on March 19, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of Xu, et al. Expires May 9, 2010 [Page 1] Internet-Draft Reset November 2009 publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract A forwarding device may get reset (automatically or manualy) and subsequently may experience an outage. It is deemed useful to know how long a device would take to recover after such an event. <> The forwarding devices in the network may go out of service due to (hardware or software) reset event. It is deemed useful to know how long a device would take to recover after such an event. <> Moreover, there are varieties of reset triggers each deserving special attention. Hence, clarity and consistency in reset procedures (above & beyond what's specified in RFC2544) are crucial to derive the meaningful results. This document specifies a methodology for characterizing reset during benchmarking of forwarding devices, and provides clarity and consistency in reset procedures beyond what's specified in RFC2544. Asati, et al. Expires May 9, 2010 [Page 2] Internet-Draft Reset November 2009 Table of Contents 1. Introduction...................................................4 1.1. Scope.....................................................4 2. Key Words to Reflect Requirements..............................5 3. Reset Test.....................................................5 3.1. Hardware Reset............................................5 3.1.1. RP reset (graceful restart)..........................5 3.1.2. LC reset.............................................5 3.2. Software Reset............................................6 3.2.1. Process reset........................................6 3.2.2. OS reset.............................................6 3.2.3. Routing protocol reset...............................6 4. Security Considerations........................................6 5. IANA Considerations............................................7 6. Acknowledgments................................................7 7. References.....................................................8 7.1. Normative References......................................8 7.2. Informative References....................................8 Authors' Addresses................................................9 Asati, et al. Expires May 9, 2010 [Page 3] Internet-Draft Reset November 2009 1. Introduction A forwarding device may get reset (automatically or manualy) and subsequently may experience an outage. It is deemed useful to know how long a device would take to recover after such an event. However, the answer to this question is no longer simple and straight-forward as the modern forwarding devices employ many hardware advancements (distributed forwarding etc.) and software advancements (graceful restart etc.) that influence the recovery time after the reset. Additionally, there are other factors that influence the recovery time after the reset: 1. Type of reset - Hardware (line-card crash etc.) vs. Software (protocol reset, process crash etc.) 2. Manual vs. Automatic reset 3. Local vs. Remote reset 4. Scale - Number of line cards present vs. in-use 5. Scale - Number of physical and logical interfaces 6. Scale - Number of routing protocol instances In summary, there are varieties of reset triggers that may produce different results depending on the procedures. Hence, clarity and consistency in reset procedures (above & beyond what's specified in RFC2544) are crucial to derive the meaningful results. This document specifies a methodology for characterizing reset during benchmarking of forwarding devices, and provides clarity and consistency in reset procedures beyond what's specified in RFC2544. These procedures may be used by other benchmarking documents such as RFC2544, RFC5180, RFCmpls etc. 1.1. Scope This document focuses on only the reset criterion of benchmarking, and presumes that it would be beneficial to RFC2544, RFC5180, RFCmpls, and other BMWG benchmarking efforts. Asati, et al. Expires May 9, 2010 [Page 4] Internet-Draft Reset November 2009 2. Key Words to Reflect Requirements 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 BCP 14, RFC 2119 [RFC2119]. RFC 2119 defines the use of these key words to help make the intent of standards track documents as clear as possible. While this document uses these keywords, this document is not a standards track document. 3. Reset Test This section contains the description of the tests that are related to the characterization of DUT's MPLS traffic forwarding. There are two types of reset: 1. Hardware resets 2. Software resets Section 3.1 describes various hardware resets, whereas section 3.2 describes various software resets. 3.1. Hardware Reset To characterize the speed at which a DUT recovers from the hardware reset 3.1.1. RP reset (graceful restart) Objective . 3.1.2. LC reset Objective . Asati, et al. Expires May 9, 2010 [Page 5] Internet-Draft Reset November 2009 3.2. Software Reset To characterize the speed at which a DUT recovers from the software reset 3.2.1. Process reset Objective . 3.2.2. OS reset Objective . 3.2.3. Routing protocol reset Objective . 4. Security Considerations Benchmarking activities, as described in this memo, are limited to technology characterization using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above. The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network. Furthermore, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT/SUT. Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks. There are no specific security considerations within the scope of this document. Asati, et al. Expires May 9, 2010 [Page 6] Internet-Draft Reset November 2009 5. IANA Considerations There is no IANA consideration for this document. 6. Acknowledgments The authors would like to thank Ron Bonica, who motivated us to write this document. This document was prepared using 2-Word-v2.0.template.dot. Asati, et al. Expires May 9, 2010 [Page 7] Internet-Draft Reset November 2009 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2544] Bradner, S. and McQuaid, J., "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999. [RFC1242] Bradner, S., Editor, "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991. [RFC3031] Rosen et al., "Multiprotocol Label Switching Architecture", RFC 3031, August 1999. [RFC3032] Rosen et al., "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3107] Rosen, E. and Rekhter, Y., "Carrying Label Information in BGP-4", RFC 3107, May 2001. [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 5036, January 2001. 7.2. Informative References [RFC5180] Popoviciu, C., et al, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, May 2008. Asati, et al. Expires May 9, 2010 [Page 8] Internet-Draft Reset November 2009 Authors' Addresses Rajiv Asati Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA Email: rajiva@cisco.com Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road RTP, NC 27709 USA Email: cpignata@cisco.com Asati, et al. Expires May 9, 2010 [Page 9]