summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4167.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4167.txt')
-rw-r--r--doc/rfc/rfc4167.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc4167.txt b/doc/rfc/rfc4167.txt
new file mode 100644
index 0000000..ec4d0c7
--- /dev/null
+++ b/doc/rfc/rfc4167.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group A. Lindem
+Request for Comments: 4167 Cisco Systems, Inc
+Category: Informational October 2005
+
+
+ Graceful OSPF Restart Implementation Report
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism
+ whereby an OSPF router can stay on the forwarding path even as its
+ OSPF software is restarted. This document provides an implementation
+ report for this extension to the base OSPF protocol.
+
+Table of Contents
+
+ 1. Overview ........................................................2
+ 2. Implementation Experience .......................................2
+ 2.1. Implementation Differences .................................2
+ 3. MIB Reference ...................................................3
+ 4. Authentication Mechanisms .......................................3
+ 5. List of Implementations .........................................3
+ 6. Test Scenarios ..................................................3
+ 7. Operational Experience ..........................................4
+ 8. Security Considerations .........................................4
+ 9. Normative References ............................................4
+ 10. Informative References .........................................4
+ 11. Acknowledgments ................................................5
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lindem Informational [Page 1]
+
+RFC 4167 Graceful OSPF Restart Implementation Report October 2005
+
+
+1. Overview
+
+ Today, many Internet routers implement a separation of control and
+ forwarding functions. Certain processors are dedicated to control
+ and management tasks such as OSPF routing, while other processors
+ perform the data forwarding tasks. This separation creates the
+ possibility of maintaining a router's data forwarding capability
+ while the router's control software is restarted/reloaded. For the
+ OSPF protocol [OSPF], the protocol mechanisms necessary to accomplish
+ this are described in Graceful OSPF Restart [GRACE].
+
+ This document satisfies the RFC 1264 [CRITERIA] requirement for a
+ report on implementation experience for Graceful OSPF Restart.
+ Section 2 of this document contains the results of an implementation
+ survey. It also documents implementation differences between the
+ vendors responding to the survey. Section 3 contains a MIB
+ reference. Section 4 provide an authentication reference. Section 5
+ simply refers to the implementations listed in section 2. Section 6
+ includes a minimal set of test scenarios. Finally, section 7
+ includes a disclaimer with respect to operational experience.
+
+2. Implementation Experience
+
+ Eleven vendors have implemented graceful OSPF and have completed the
+ implementation survey. These include Redback, Juniper, Motorola
+ Computer Group (formerly Netplane Systems), Mahi Networks, Nexthop
+ technologies, Force10 Networks, Procket, Alcatel, Laurel Networks,
+ DCL (Data Connection Limited), and Ericsson. All have implemented
+ restart from the perspective of both a restarting and helper router.
+ All but one vendor implemented both planned and unplanned restart.
+ All implementations are original. Seven successfully tested
+ interoperability with Juniper. Juniper successfully tested
+ interoperability with Force10 Networks. One vendor tested with John
+ Moy's GNU Public License implementation [OSPFD]. Two vendors had not
+ tested interoperability at the time of the survey.
+
+2.1. Implementation Differences
+
+ The first difference was whether strict LSA checking was implemented
+ and, if so, whether it was configurable. In the context of graceful
+ OSPF restart, strict LSA checking indicates whether a changed LSA
+ will result in the termination of graceful restart by a helping
+ router. Four vendors made it configurable (three defaulted it to
+ enabled and one to disabled), another made it a compile option
+ (shipping with strict LSA checking disabled), another didn't
+ implement it at all, and five implemented strict LSA checking with no
+ configuration option to disable it.
+
+
+
+
+Lindem Informational [Page 2]
+
+RFC 4167 Graceful OSPF Restart Implementation Report October 2005
+
+
+ The second was whether a received grace LSA would be taken to apply
+ only to the adjacency on which it was received or to all adjacencies
+ with the restarting router. This is a rather subtle difference since
+ it only applies to helping and restarting routers with more than one
+ full adjacency at the time of restart. Eight vendors implemented the
+ option of the received grace LSA only applying to the adjacency on
+ which it was received. Three vendors applied the grace LSA to all
+ adjacencies with the grace LSA originator (i.e., the restarting
+ router).
+
+ The final difference was in whether additional extensions were
+ implemented to accommodate other features such as protocol
+ redistribution or interaction with MPLS VPNs [VPN]. Five vendors
+ implemented extensions and six did not. It should be noted that such
+ extensions are beyond the scope of Graceful OSPF Restart [GRACE].
+
+3. MIB Reference
+
+ MIB objects for the Graceful OSPF Restart have been added to the OSPF
+ Version 2 Management Information Base [OSPFMIB]. Additions include:
+
+ - Objects ospfRestartSupport, ospfRestartInterval, ospfRestartAge,
+ ospfRestartExitReason, and ospfRestartStrictLsaChecking to
+ ospfGeneralGroup.
+
+ - Objects ospfNbrRestartHelperStatus, ospfNbrRestartHelperAge, and
+ ospfNbrRestartHelperExitReason to ospfNbrEntry.
+
+ - Objects ospfVirtNbrRestartHelperStatus,
+ ospfVirtNbrRestartHelperAge, and
+ ospfVirtNbrRestartHelperExitReason to ospfVirtNbrEntry.
+
+4. Authentication Mechanisms
+
+ The authentication mechanisms are the same as those implemented by
+ the base OSPF protocol [OSPF].
+
+5. List of Implementations
+
+ Refer to section 2.
+
+6. Test Scenarios
+
+ A router implementing graceful restart should test, at a minimum, the
+ following scenarios as both a restarting and helping router. For all
+ scenarios, monitoring data plane traffic may be used to ensure that
+ the restart is non-disruptive:
+
+
+
+
+Lindem Informational [Page 3]
+
+RFC 4167 Graceful OSPF Restart Implementation Report October 2005
+
+
+ 1. Operation over a broadcast network.
+
+ 2. Operation over a P2P network.
+
+ 3. Operation over a virtual link.
+
+ 4. Operation using OSPF MD5 authentication.
+
+ 5. Early graceful restart termination when an LSA inconsistency is
+ detected.
+
+ 6. Early graceful restart termination when a flooded LSA changes (if
+ implemented).
+
+7. Operational Experience
+
+ Since OSPF graceful restart is configurable, it is difficult to gage
+ operational experience at this juncture. However, multiple service
+ providers have tested and evaluated it.
+
+8. Security Considerations
+
+ This document does not discuss implementation and interoperability
+ aspects of the security mechanisms in great detail, as no new
+ security mechanisms are introduced with Graceful OSPF Restart.
+ Security considerations for the OSPF protocol are included in RFC
+ 2328 [OSPF]. Security considerations for Graceful OSPF Restart are
+ included in [GRACE].
+
+9. Normative References
+
+ [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+ [GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful
+ OSPF Restart", RFC 3623, November 2003.
+
+ [CRITERIA] Hinden, R., "Internet Engineering Task Force Internet
+ Routing Protocol Standardization Criteria", RFC 1264,
+ October 1991.
+
+10. Informative References
+
+ [VPN] Rosen, E. and Y Rekhter, "BGP/MPLS IP VPNs", Work in
+ Progress, September 2003.
+
+ [OSPFD] Moy, J., "OSPF Complete Implementation", Addison-Wesley,
+ 1991, ISBN 0-201-30966-1
+
+
+
+
+Lindem Informational [Page 4]
+
+RFC 4167 Graceful OSPF Restart Implementation Report October 2005
+
+
+ [OSPFMIB] Joyal, D., et al, "OSPF Version 2 Management Information
+ Base", Work in Progress, December 2003.
+
+11. Acknowledgments
+
+ The author wishes to acknowledge the individuals/vendors who have
+ completed the implementation survey.
+
+ - Anand Oswal (Redback Networks)
+ - Padma Pillay-Esnault (Juniper Networks)
+ - Vishwas Manral (Motorola Computer Group, formerly Netplane
+ System).
+ - Sriganesh Kini (Mahi Networks)
+ - Jason Chen (Force10 Networks)
+ - Daniel Gryniewicz (NextHop Technologies)
+ - Hasmit Grover (Procket Networks)
+ - Pramoda Nallur (Alcatel)
+ - Ardas Cilingiroglu (Laurel Networks)
+ - Philip Crocker (Data Connection Limited)
+ - Le-Vinh Hoang (Ericsson)
+
+Author's Address
+
+ Acee Lindem
+ Cisco Systems, Inc
+ 7025 Kit Creek Road
+ Research Triangle Park, NC 27709
+ USA
+
+ EMail: acee@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lindem Informational [Page 5]
+
+RFC 4167 Graceful OSPF Restart Implementation Report October 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ 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 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Lindem Informational [Page 6]
+