idnits 2.17.1 draft-ietf-ospf-restart-01.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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 3) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. 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 (February 2001) is 8470 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) == Missing Reference: 'OSPF' is mentioned on line 85, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-ospf-lls-00 == Outdated reference: A later version (-01) exists of draft-ietf-ospf-oob-resync-00 -- Possible downref: Normative reference to a draft: ref. 'OOB' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alex Zinin 3 Internet Draft Abhay Roy 4 Expiration Date: September 2001 Liem Nguyen 5 File name: draft-ietf-ospf-restart-01.txt Cisco Systems 6 February 2001 8 OSPF Restart Signaling 9 draft-ietf-ospf-restart-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its Areas, and its Working Groups. Note that other 18 groups may also distribute working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a "working 24 draft" or "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 33 OSPF is a link-state intra-domain routing protocol used in IP 34 networks. Routers find new and detect unreachable neighbors via Hello 35 subprotocol. Hello OSPF packets are also used to ensure two-way 36 connectivity within time. When a router restarts its OSPF software, 37 it may not know its neighbors. If such a router sends a hello packet 38 on an interface, its neighbors are going to reset the adjacency, 39 which may not be desirable in certain conditions. This memo provides 40 a mechanism that allows OSPF routers to inform their neighbors about 41 the restart process. Note that this mechanism requires support from 42 neighboring routers. 44 1 Motivation 45 While performing a graceful restart of OSPF software [OSPF], routers 46 need to prevent their neigbors from reseting their adjacencies. 47 However, after a reload, routers may not be aware of the neighbors 48 they had adjacencies with in their previous incarnations. If such a 49 router sends a Hello packet on an interface and this packet does not 50 list some neighbors, those neighbors will reset the adjacency with 51 restarting router. 53 This document describes a technique that allows restarting routers to 54 inform their neighbors that they may not know about some neighbors 55 yet and the absence of some router-IDs in the Hello packets should be 56 ignored. 58 2 Proposed solution 60 A new bit, called RS (restart signal) is introduced into Extended 61 Options TLV in the LLS block (see [LLS]). The value of this bit is 62 TBD (temporarily used value is 0x00000002, see Figure 1 below). 64 +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ 65 | * | * | * | * | * | * | * |...| * | * | * | * | * | * | RS| LR| 66 +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ 68 Figure 1. Bits in Extended Options TLV 70 OSPF routers should set the RS-bit in the EO-TLV attached to a Hello 71 packet when this is not clear that all neighbors are listed in this 72 packet, but the restarting router wants them to preserve their 73 adjacencies. The RS-bit may not be set in Hello packets longer than 74 RouterDeadInterval seconds. 76 For a definition of the LR bit, see [OOB]. 78 2.1 Receiving Hello Packets with RS-bit set 80 When an OSPF router receives a Hello packet, containing the LLS block 81 with the EO-TLV which has the RS-bit set, the router should skip the 82 two-way connectivity check with the announcing neighbor (i.e., the 83 router should not generate a 1-WayReceived event for the neighbor if 84 it does not find its own router ID in the list of neighbors as 85 described in 10.5 of [OSPF]), provided that the neighbor FSM for this 86 neighbor is in the Full state. 88 The router should also send a unicast Hello back to the sender in 89 reply to a Hello packet with RS bit set. This is to speed up 90 learning of previously known neighbors. When sending such a reply 91 packet, care must be taken to ensure that the RS bit is clear in it. 93 Two additional fields are introduced in the neighbor data structure: 94 RestartState flag and ResyncTimeout timer. RestartState flag 95 indicates that a Hello packet with RS-bit set has been received and 96 the local router expects its neighbor to go through the LSDB 97 resynchronization procedure using [OOB]. ResyncTimeout is a single- 98 shot timer limiting the delay between the first seen Hello packet 99 with RS-bit set and initialization of the LSDB resynchronization 100 procedure. The length of ResyncTimeout timer is RouterDeadInterval 101 seconds. 103 When a Hello packet with RS-bit set is received and RestartState flag 104 is not set for the neighbor, the router sets RestartState flag and 105 starts ResyncTimeout timer. If ResyncTimeout expires, RestartState 106 flag is cleared and a 1-WayReceived event is generated for the 107 neighbor. If, while ResyncTimeout timer is running, the neighbor 108 starts LSDB resynchronization procedure using [OOB], ResyncTimeout 109 timer is cancelled. The router also clears RestartState flag on 110 completion of the LSDB resynchronization process. 112 2.2 Insuring topology stability 114 Under certain circumstances it might be desirable to stop announcing 115 the restarting router as fully adjacent if this may lead to possible 116 routing loops. In order to provide this functionality, a configurable 117 oprion is provided on the neighboring routers that instructs the OSPF 118 process to follow the logics described below. 120 When an OSPF router schedules a routing table calculation due to a 121 change in the contents of its LSDB, it should also reset all 122 adjacencies with restarting routers (those with RestartState set to 123 TRUE) by clearing the RestartState neighbor flags, canceling 124 ResyncTimeout timers (if running), and generating the 1-WayReceived 125 events for the neighbor FSMs. 127 3 Compatibility Issues 129 The described technique requires cooperation from neighboring 130 routers. However, if neighbors do not support this technique, they 131 will just reset the adjacency. 133 4 Security Considerations 135 The described technique does not introduce any new security issues 136 into OSPF protocol. 138 5 Acknowledgements 140 The authors would like to thank John Moy, Russ White, Don Slice, and 141 Alvaro Retana for their valuable comments. 143 6 References 145 [OSPF]J. Moy. OSPF version 2. Technical Report RFC 2328, Internet 146 Engineering Task Force, 1998. ftp://ftp.isi.edu/in- 147 notes/rfc2328.txt. 149 [LLS] Zinin, Friedman, Roy, Nguyen, Yeung, "OSPF Link-local Signal- 150 ing", draft-ietf-ospf-lls-00.txt, Work in progress. 152 [OOB] Zinin, Roy, Nguyen, "OSPF Out-of-band LSDB resynchronization", 153 draft-ietf-ospf-oob-resync-00.txt, Work in progress. 155 7 Authors' addresses 157 Alex Zinin Abhay Roy 158 Cisco Systems Cisco Systems 159 150 W. Tasman Dr. 170 W. Tasman Dr. 160 San Jose,CA 95134 San Jose,CA 95134 161 USA USA 162 E-mail: azinin@cisco.com E-mail: akr@cisco.com 164 Liem Nguyen 165 7025 Kit Creek Rd. 166 Research Triangle Park, NC 27709 167 USA 168 e-mail: lhnguyen@cisco.com