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.

   <<delete>> 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. <</delete>>

   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]