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]