idnits 2.17.1 draft-ietf-ospf-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: ---------------------------------------------------------------------------- ** 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 2 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 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 (November 2000) is 8535 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: July 2001 Liem Nguyen 5 File name: draft-ietf-ospf-restart-00.txt Cisco Systems 6 November 2000 8 OSPF Restart Signaling 9 draft-ietf-ospf-restart-00.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| OR| 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 OR bit, see [OOB]. 78 2.2 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 It is also recommended that a unicast Hello is sent back to the 89 sender in reply to a Hello packet with RS bit set. This is to speed 90 up 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 3 Compatibility Issues 95 The described technique requires cooperation from neighboring 96 routers. However, if neighbors do not support this technique, they 97 will just reset the adjacency. 99 4 Security Considerations 101 The described technique does not introduce any new security issues 102 into OSPF protocol. 104 5 Acknowledgements 106 The authors would like to thank Russ White, Don Slice, and Alvaro 107 Retana for their valuable comments. 109 6 References 111 [OSPF]J. Moy. OSPF version 2. Technical Report RFC 2328, Internet 112 Engineering Task Force, 1998. ftp://ftp.isi.edu/in- 113 notes/rfc2328.txt. 115 [LLS] Zinin, Friedman, Roy, Nguyen, Yeung, "OSPF Link-local Signal- 116 ing", draft-ietf-ospf-lls-00.txt, Work in progress. 118 [OOB] Zinin, Roy, Nguyen, "OSPF Out-of-band LSDB resynchronization", 119 draft-ietf-ospf-oob-resync-00.txt, Work in progress. 121 7 Authors' addresses 123 Alex Zinin Abhay Roy 124 Cisco Systems Cisco Systems 125 150 W. Tasman Dr. 170 W. Tasman Dr. 126 San Jose,CA 95134 San Jose,CA 95134 127 USA USA 128 E-mail: azinin@cisco.com E-mail: akr@cisco.com 130 Liem Nguyen 131 7025 Kit Creek Rd. 132 Research Triangle Park, NC 27709 133 USA 134 e-mail: lhnguyen@cisco.com