RFC 4167

Graceful OSPF Restart Implementation Report

๐Ÿ“… published October 2005, from ietf

๐ŸŽ€ RFC 4167: Graceful OSPF Restart Implementation Report

Okay bestie, here's the title block first ๐Ÿฆ‹

  • RFC number: 4167
  • Title: Graceful OSPF Restart Implementation Report
  • Series: Network Working Group
  • Author: A. Lindem, Cisco Systems, Inc
  • Category: Informational
  • Date: October 2005
  • Obsoletes / Updates: this header doesn't list anything it obsoletes or updates ๐Ÿ’…

Status of This Memo โœจ

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2005).

Abstract ๐Ÿ”ฅ

Okay so Graceful OSPF Restart, which is specified in RFC 3623, gives an OSPF router a way to keep forwarding traffic even while its OSPF software is restarting. This document is the implementation report for that extension to base OSPF. It's giving real-world receipts ๐Ÿ“‹

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

1. Overview ๐Ÿงš

Okay, so today a lot of Internet routers split control from forwarding. Some processors handle control and management jobs like OSPF routing, and other processors do the actual data forwarding. That split makes it possible to keep forwarding data while the control software gets restarted or reloaded. For OSPF [OSPF], the protocol mechanisms that make this work are described in Graceful OSPF Restart [GRACE].

This document covers the RFC 1264 [CRITERIA] requirement for an implementation experience report on Graceful OSPF Restart. โœจ Section 2 has the results of an implementation survey, plus the differences between the vendors who answered it. Section 3 is a MIB reference. Section 4 gives an authentication reference. Section 5 just points back to the implementations listed in Section 2. Section 6 has a minimal set of test scenarios. Last but not least, Section 7 has a disclaimer about operational experience ๐Ÿซถ

2. Implementation Experience ๐Ÿฆ‹

Eleven vendors implemented graceful OSPF and finished the implementation survey. They are 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 of them implemented restart from the view of both the restarting router and the helper router. All but one vendor implemented both planned and unplanned restart. Every implementation is original. Seven successfully tested interoperability with Juniper, and Juniper successfully tested interoperability with Force10 Networks. One vendor tested against John Moy's GNU Public License implementation [OSPFD]. Two vendors hadn't 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 could be configured. For graceful OSPF restart, strict LSA checking tells you whether a changed LSA will end graceful restart on a helping router. Four vendors made it configurable (three defaulted it to enabled and one to disabled). Another vendor 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 turn it off. Wild, right? ๐Ÿ™ˆ

The second difference was whether a received grace LSA applies only to the adjacency it arrived on, or to all adjacencies with the restarting router. This one is pretty subtle, since it only matters for helping and restarting routers with more than one full adjacency at the time of restart. Eight vendors implemented the option where the received grace LSA only applies to the adjacency it was received on. Three vendors applied the grace LSA to all adjacencies with the grace LSA originator (that is, the restarting router). ๐Ÿ“

The final difference was whether extra extensions were added for other features, like protocol redistribution or interaction with MPLS VPNs [VPN]. Five vendors implemented extensions and six did not. It's worth noting that these extensions are beyond the scope of Graceful OSPF Restart [GRACE] ๐ŸŒˆ

3. MIB Reference ๐Ÿ’œ

MIB objects for Graceful OSPF Restart have been added to the OSPF Version 2 Management Information Base [OSPFMIB]. The additions are:

  • 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 ones base OSPF uses [OSPF]. Nothing new here, bestie ๐Ÿซถ

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 router and a helping router. For all scenarios, monitoring data plane traffic may be used to make sure the restart is non-disruptive:

  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's hard to gauge operational experience right now. Still, multiple service providers have tested and evaluated it ๐Ÿ’–

8. Security Considerations ๐Ÿšจ

This is serious, so read carefully ๐Ÿ’€

This document doesn't go into implementation and interoperability details for the security mechanisms in great depth, because Graceful OSPF Restart doesn't introduce any new security mechanisms. The security considerations for the OSPF protocol are in RFC 2328 [OSPF]. The security considerations for Graceful OSPF Restart are 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

[OSPFMIB]   Joyal, D., et al, "OSPF Version 2 Management Information
            Base", Work in Progress, December 2003.

11. Acknowledgments ๐Ÿซถ

The author wants to thank the individuals and vendors who 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

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 on 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 on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of any attempt to obtain a general license or permission for implementers or users to use such proprietary rights can be obtained from the IETF online 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 required to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org.

Acknowledgement ๐Ÿ’œ

Funding for the RFC Editor function is currently provided by the Internet Society. โœจ

๐Ÿ“ฆ where this page comes from