idnits 2.17.1 draft-ietf-ospf-graceful-impl-report-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2004) is 7285 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 63 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-mib-update-08 ** Obsolete normative reference: RFC 1264 (ref. 'CRITERIA') (Obsoleted by RFC 4794) == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-rfc2547bis-01 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Acee Lindem (Redback Networks) 3 Internet Draft 4 Expiration Date: October 2004 Proposed Status: Informational 5 File name: draft-ietf-ospf-graceful-impl-report-05.txt May 2004 7 Graceful OSPF Restart Implementation Report 8 draft-ietf-ospf-graceful-impl-report-05.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet- Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 Graceful OSPF Restart as specified in RFC 3623 provides a mechanism 34 whereby an OSPF router can stay on the forwarding path even as its 35 OSPF software is restarted. This document provides an 36 implementation report for this extension to the base OSPF protocol. 38 Table of Contents 40 1 Overview ............................................... 2 41 2 Implementation Experience .............................. 3 42 2.1 Implementation Differences ............................. 3 43 3 MIB Reference .......................................... 4 44 4 Authentication Mechanisms .............................. 4 45 5 List of Implementations ................................ 4 46 6 Test Scenarios ......................................... 4 47 7 Operational Experience ................................. 4 48 8 Security Considerations ................................ 5 49 9 Intellectual Property .................................. 5 50 10 Normative References ................................... 5 51 11 Informative References ................................. 6 52 12 Acknowledgments ........................................ 6 53 13 Author's Address ....................................... 6 55 1. Overview 57 Today many Internet routers implement a separation of control and 58 forwarding functions. Certain processors are dedicated to control 59 and management tasks such as OSPF routing, while other processors 60 perform the data forwarding tasks. This separation creates the 61 possibility of maintaining a router's data forwarding capability 62 while the router's control software is restarted/reloaded. For the 63 OSPF protocol [1], this protocol mechanisms necessary to accomplish 64 this are described in Graceful OSPF Restart [GRACE]. 66 This document satisfies the RFC 1264 [CRITERIA] requirement for a 67 report on implementation experience for Graceful OSPF Restart. 68 Section 2 of this document contains the results of an 69 implementation survey. It also documents implementation differences 70 between the vendors responding to the survey. Section 3 contains a 71 MIB reference. Sections 4 provide an authentication reference. 72 Section 5 simply refers to the implementations listed in section 2. 73 Section 6 includes a minimal set of test scenarios. Finally, 74 section 7 includes a disclaimer with respect to operational 75 experience. 77 2. Implementation Experience 79 Eleven vendors have implemented graceful OSPF and have completed 80 the implementation survey. These include Redback, Juniper, Motorola 81 Computer Group (formerly Netplane Systems), Mahi Networks, 82 Nexthop technologies, Force10 Networks, Procket, Alcatel, Laurel 83 Networks, DCL (Data Connection Limited), and Ericsson. All have 84 implemented restart from the perspective of both a restarting 85 and helper router. All but one vendor implemented both planned 86 and unplanned restart. All implementations are original. Seven 87 successfully tested interoperability with Juniper. Juniper 88 successfully tested interoperability with Force10 Networks. One 89 vendor tested with John Moy's GNU Public License implementation 90 [OSPFD]. Two vendors hadn't tested interoperability at the time of 91 the survey. 93 2.1 Implementation Differences 95 The first difference was whether or not strict LSA checking was 96 implemented and, if so, whether it was configurable. In the context 97 of graceful OSPF restart, strict LSA checking indicates whether or 98 not a changed LSA will result in termination of graceful restart 99 by a helping router. Four vendors made it configurable (three 100 defaulted it to enabled and one disabled), another made it 101 a compile option (shipping with strict LSA checking disabled), 102 another didn't implement it at all, and five implemented strict 103 LSA checking with no configuration option to disable it. 105 The second was whether a received grace LSA would be taken to apply 106 only to the adjacency on which it was received or all adjacencies 107 with the restarting router. This is a rather subtle difference 108 since it only applies to helping and restarting routers with more 109 than one full adjacency at the time or restart. Eight vendors 110 implemented the option of received grace LSA only applying to the 111 adjacency on which it was received. Three vendors applied the grace 112 LSA to all adjacencies with the grace LSA originator (i.e., the 113 restarting router). 115 The final difference was in whether or not additional extensions 116 were implemented to accommodate other features such as protocol 117 redistribution or interaction with MPLS VPNs [VPN]. Five vendors 118 implemented extensions and six did not. It should be noted that 119 such extensions are beyond the scope of Graceful OSPF 120 Restart [GRACE]. 122 3. MIB Reference 124 MIB objects for the Graceful OSPF Restart have been added to the 125 OSPF Version 2 Management Information Base [OSPFMIB]. Additions 126 include: 128 - Objects ospfRestartSupport, ospfRestartInterval, ospfRestartAge, 129 ospfRestartExitReason, and ospfRestartStrictLsaChecking to 130 ospfGeneralGroup. 132 - Objects ospfNbrRestartHelperStatus, ospfNbrRestartHelperAge, 133 and ospfNbrRestartHelperExitReason to ospfNbrEntry. 135 - Objects ospfVirtNbrRestartHelperStatus, 136 ospfVirtNbrRestartHelperAge, and 137 ospfVirtNbrRestartHelperExitReason to ospfVirtNbrEntry. 139 4. Authentication Mechanisms 141 The authentication mechanisms are the same as those implemented 142 by the base OSPF protocol [OSPF]. 144 5. List of Implementations 146 Refer to section 2. 148 6. Test Scenarios 150 A router implementing graceful restart should test, at a minimum, 151 the following scenarios as both a restarting and helping 152 router. For all scenarios, monitoring data plane traffic may be 153 used to assure the restart is non-disruptive: 155 1. Operation over a broadcast network. 156 2. Operation over a P2P network. 157 3. Operation over a virtual link. 158 4. Operation using OSPF MD5 authentication. 159 5. Early graceful restart termination when an LSA consistency 160 is detected. 161 6. Early graceful restart termination when a flooded LSA 162 changes (if implemented). 164 7. Operational Experience 166 Since the feature is configurable it is difficult to evaluate 167 operational experience at this juncture. However, service providers 168 have tested and evaluated the feature. 170 8. Security Considerations 172 This document does not address any security issues other a reference 173 to the RFC 2328 [OSPF]. Security considerations for the OSPF protocol 174 are included in RFC2328 [OSPF]. Security considerations for Graceful 175 OSPF Restart are included in [GRACE]. 177 9. Intellectual Property 179 The IETF takes no position regarding the validity or scope of any 180 intellectual property or other rights that might be claimed to 181 pertain to the implementation or use of the technology described in 182 this document or the extent to which any license under such rights 183 might or might not be available; neither does it represent that it 184 has made any effort to identify any such rights. Information on the 185 IETF's procedures with respect to rights in standards-track and 186 standards-related documentation can be found in BCP-11. Copies of 187 claims of rights made available for publication and any assurances of 188 licenses to be made available, or the result of an attempt made to 189 obtain a general license or permission for the use of such 190 proprietary rights by implementors or users of this specification can 191 be obtained from the IETF Secretariat. 193 The IETF invites any interested party to bring to its attention any 194 copyrights, patents or patent applications, or other proprietary 195 rights which may cover technology that may be required to practice 196 this standard. Please address the information to the IETF Executive 197 Director. 199 10. Normative References 201 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 203 [GRACE] Moy, J., Pillay-Esnault, P., Lindem, A., 204 "Graceful OSPF Restart", RFC 3623, July 2003. 206 [OSPFMIB] Joyal, D., et al, "OSPF Version 2 Management Information 207 Base", draft-ietf-ospf-mib-update-08.txt, December 2003, 208 work in progress. 210 [CRITERIA] Hinden, R., "Routing Protocol Criteria", RFC 1264, 211 October 1991. 213 11. Informative References 215 [VPN] Rosen, E., Rekhter, Y. "BGP/MPLS IP VPNs", 216 draft-ietf-l3vpn-rfc2547bis-01.txt, 217 September 2003, work in progress. 218 [OSPFD] Moy, J., "OSPF Complete Implementation", 219 Addison-Wesley, 1991, ISBN 0-201-30966-1 221 12. Acknowledgments 223 The author wishes to acknowledge the individuals/vendors who have 224 completed the implementation survey. 226 - Anand Oswal (Redback Networks) 227 - Padma Pillay-Esnault (Juniper Networks) 228 - Vishwas Manral (Motorola Computer Group, formerly Netplane 229 System). 230 - Sriganesh Kini (Mahi Networks) 231 - Jason Chen (Force10 Networks) 232 - Daniel Gryniewicz (NextHop Technologies) 233 - Hasmit Grover (Procket Networks) 234 - Pramoda Nallur (Alcatel) 235 - Ardas Cilingiroglu (Laurel Networks) 236 - Philip Crocker (Data Connection Limited) 237 - Le-Vinh Hoang (Ericsson) 239 13. Author's Address 241 Acee Lindem 242 Redback Networks 243 102 Carric Bend Court 244 Cary, NC 27519 245 Email: acee@redback.com