idnits 2.17.00 (12 Aug 2021) /tmp/idnits1093/draft-lindem-ospf-hitless-extended-restart-00.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: ---------------------------------------------------------------------------- == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (June 2002) is 7273 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: 'Ref2' on line 99 -- Looks like a reference, but probably isn't: 'Ref1' on line 54 == Unused Reference: '1' is defined on line 112, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 114, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Acee Lindem 3 Internet Draft Anand Oswal 4 Expiration Date: November 2002 Redback Networks 5 June 2002 7 Extended Hitless OSPF Restart 8 draft-lindem-ospf-hitless-extended-restart-00.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 This memo documents an enhancement to OSPF "hitless restart" whereby 34 an OSPF router can request that its forwarding state be maintained 35 longer that the router dead interval on one or more router 36 interfaces. This is useful when the OSPF software is being 37 updated and the router dead interval on one or more interfaces is 38 configured to a small value. 40 Table of Contents 42 1 Overview ............................................... 2 43 2 Changes to restarting router operation ................. 2 44 3 Changes to helper neighbor operation ................... 2 45 4 Backward compatibility ................................. 3 46 5 Security Considerations ................................ 3 47 6 References ............................................. 3 48 7 Acknowledgments ........................................ 3 49 8 Authors' Addresses ..................................... 3 51 1. Overview 53 "Hitless OSPF Restart" [Ref2] describes an enhancement to the 54 OSPF protocol [Ref1] which allows an OSPF router to continue 55 forwarding after the OSPF routing software has been restarted. 56 This memo documents an extension which allows the restart time 57 to exceed the router dead interval on one or more interfaces. This 58 useful when the routing software is being updated and the router 59 dead interval on one or more interfaces is configured to a very 60 small value. 62 2. Changes to restarting router operation 64 When the restarting router is to be brought down for a period which 65 may exceed the router dead interval on one or more router 66 interfaces, a unique value will be used for the Hitless restart 67 reason (Type=2, length=1) TLV. Currently, a value of 4 (extended 68 maintenance) is used for this purpose. Once the grace-LSA has been 69 originated on an interface, the restarting router must assure that 70 it does not send any hello packets until it actually restarts. This 71 is required to prevent helper neighbors from resetting their router 72 dead interval timer corresponding to the restarting router to the 73 configured value. 75 Routers that support both planned and unplanned restart should save 76 the restart reason in non-volatile storage. When the OSPF restarts 77 restarts, the saved restart reason is examined to determine whether 78 or not grace-LSAs need to be originated. The restart reason will be 79 0 (unknown) for unplanned restarts. This indicates the restarting 80 router must originate grace-LSAs prior to sending any hellos 81 (as specified in section 5 of "Hitless OSPF restart" [Ref2]). 83 3. Changes to helper neighbor operation 85 When a router Y receives a grace-LSA from router X and all 86 criteria for entering helper are satisfied (as specified in section 87 3.1 of "Hitless OSPF restart" [Ref2]), it will enter helper mode. If 88 Hitless restart reason TLV in the grace-LSA indicates "extended 89 maintenance" and the router dead interval will expire sooner 90 than the grace period expiration, the router dead interval 91 timer for the restarting router will be reset to expire at the 92 same time as the grace period expiration. 94 Additionally, local policy may be implemented to disallow 95 router dead interval extension when entering helper mode. 97 4. Backward compatibility 99 This extension to "Hitless OSPF Restart" [Ref2] does not introduce 100 any new backward compatibility issues. If an OSPF router supports 101 hitless OSPF restart but does not support this extension and the 102 router dead timer for a restarting OSPF router expires, it will 103 simply exit helper mode and the resume normal OSPF operation. 105 5. Security Considerations 107 The described technique does not introduce any new security issues 108 into OSPF protocol. 110 6. References 112 [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 114 [2] Moy, J., "OSPF Hitless Restart", work in progress. 116 7. Acknowledgments 118 The authors wish to thank Naiming Shen and Tony Przygienda for their 119 helpful comments. 121 8. Authors' Addresses 123 Acee Lindem Anand Oswal 124 Redback Networks Redback Networks 125 102 Carric Bend Court 350 Holger Way 126 Cary, NC 27519 San Jose, CA 95134 127 e-mail: acee@redback.com e-mail: aoswal@redback.com