idnits 2.17.00 (12 Aug 2021) /tmp/idnits42176/draft-ietf-ospf-ospfv3-graceful-restart-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 327. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (April 28, 2008) is 5129 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) ** Obsolete normative reference: RFC 2740 (ref. 'OSPFv3') (Obsoleted by RFC 5340) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Pillay-Esnault 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track A. Lindem 5 Expires: October 30, 2008 Redback Networks 6 April 28, 2008 8 OSPFv3 Graceful Restart 9 draft-ietf-ospf-ospfv3-graceful-restart-08.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 30, 2008. 36 Abstract 38 This document describes the OSPFv3 graceful restart. The OSPFv3 39 graceful restart is identical to OSPFv2 except for the differences 40 described in this document. These differences include the format of 41 the grace Link State Advertisements (LSA) and other considerations. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Grace Link State Advertisement . . . . . . . . . . . . . . . . 3 47 2.1. Grace LSA - LS Type . . . . . . . . . . . . . . . . . . . . 3 48 2.2. Grace LSA Format . . . . . . . . . . . . . . . . . . . . . 4 49 3. Additional Considerations for OSPFv3 Graceful Restart . . . . . 5 50 3.1. Preservation of LSA ID to Prefix Correspondence . . . . . . 5 51 3.2. Preservation of Interface IDs for Link-LSAs, 52 Network-LSAs, and Router-LSAs . . . . . . . . . . . . . . . 5 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 55 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 58 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 60 Intellectual Property and Copyright Statements . . . . . . . . . . 8 62 1. Introduction 64 Graceful OSPF restart [GRACE] describes a mechanism to restart the 65 control plane of an OSPFv2 [OSPFv2] router which still has its 66 forwarding plane intact with a minimum of disruption to the network. 68 In general, the methods described in [GRACE] work for OSPFv3 [OSPFv3] 69 as well. However, OSPFv3 will use a grace-LSA with a different 70 format to signal that a router is initiating (or is about to 71 initiate) a graceful restart. This document describes other OSPFv3 72 differences as well. 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Grace Link State Advertisement 80 An OSPFv3 router initiating a graceful restart of its OSPFv3 software 81 originates grace-LSAs. A grace-LSA requests that the router's 82 neighbors aid in its graceful restart by continuing to advertise the 83 router as fully adjacent during the specified grace period. The 84 grace-LSA contains the restarting router grace-period and the reason 85 code indicating the reason for the graceful restart. 87 In OSPFv3 (refer 2.11 of [OSPFv3]), neighboring routers on any link 88 are always identified by their router IDs. This contrasts with the 89 OSPFv2 behavior where neighbors on point-to-point networks and 90 virtual links are identified by their Router IDs while neighbors on 91 broadcast, NBMA, and point-to-multipoint links are identified by 92 their IPv4 interface addresses. Consequently, there is no 93 requirement for the router-address TLV [GRACE] for OSPFv3 graceful 94 restart. 96 The TLV formats of the grace-LSA described in [GRACE] remain 97 unchanged. 99 2.1. Grace LSA - LS Type 101 A grace-LSA is defined as link-local scope LSA with the LS type equal 102 to 0x000b. 104 LSA function code LS Type Description 105 ------------------------------------------ 106 11 0x000b Grace LSA 108 Grace-LSA Type and Function code 110 The U-bit is set to 0 since this is a link-local scoped LSA and the 111 flooding scope is not impacted by whether or not the LSA is known. 112 The S2-bit and S1-bit are also set to 0 to indicate link-local 113 flooding scope. 115 2.2. Grace LSA Format 117 The format of a grace LSA is: 119 0 1 2 3 120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | LS age |0|0|0| 11 | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Link State ID | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Advertising Router | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | LS sequence number | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | LS checksum | Length | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | | 133 +- TLVs -+ 134 | ... | 136 Grace-LSA Format 138 The Link State ID of a grace-LSA in OSPFv3 is the interface ID of the 139 interface originating the LSA. 141 The format of each TLV is: 143 0 1 2 3 144 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Type | Length | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Value... | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 TLV Format 153 Grace-LSA TLVs are formatted according to section 2.3.2 of [OSPF-TE]. 155 The following is the list of TLVs that can appear in the body of a 156 grace-LSA. 158 Grace Period (Type=1, length=4). The number of seconds that the 159 router's neighbors should continue to advertise the router as 160 fully adjacent, regardless of the state of database 161 synchronization between the router and its neighbors. This TLV 162 MUST always appear in a grace-LSA. 164 Graceful restart reason (Type=2, length=1). Encodes the reason 165 for the router restart, as one of the following: 0 (unknown), 1 166 (software restart), 2 (software reload/upgrade) or 3 (switch to 167 redundant control processor). This TLV MUST always appear in a 168 grace-LSA. 170 3. Additional Considerations for OSPFv3 Graceful Restart 172 This section describes OSPFv3 unique considerations in addition to 173 those described in [GRACE]. 175 3.1. Preservation of LSA ID to Prefix Correspondence 177 In OSPFv2, there is a direct correspondence between summary and 178 external LSA IDs and the prefixes being advertised. However, in 179 OSPFv3, the LSA ID for inter-area prefix LSAs and external LSAs is 180 simply an unsigned 32-bit integer. Hence, to avoid network churn 181 during graceful restart, the restarting router MUST preserve the LSA 182 ID to prefix correspondence across graceful restarts. 184 3.2. Preservation of Interface IDs for Link-LSAs, Network-LSAs, and 185 Router-LSAs 187 In OSPFv3, the LSA ID for link-local-LSAs and network-LSAs and link 188 descriptions in router-LSAs map to their corresponding Interface ID. 189 Changes in the Interface ID during graceful restart will result in a 190 mismatch between the restarting router's pre-restart LSAs and its 191 neighbor adjacency state. These disparities will cause the graceful 192 restart to terminate prematurely. 194 Synchronizing interface ID changes between neighbors is possible. 195 However, placing the burden on the restarting router to preserve 196 interface IDs across restarts provides for a more robust, more 197 deterministic, and simpler mechanism. Therefore, the OSPFv3 198 interface ID, as described in section 3.1.2 of [OSPFv3], MUST be 199 preserved by the restarting router across restarts. 201 Many implementations currently use the interface's MIB-II IfIndex 202 [MIB-INTF] for Interface ID. The persistence of Interface ID across 203 reboots is described in section 3.1.5 of [MIB-PERS]. 205 4. Security Considerations 207 [OSPFv3-AUTH] relies on manual key distribution which precludes the 208 use of replay protection utilizing sequence numbers. The replay of 209 an OSPF Link-Update containing a grace-LSA would allow an attacker to 210 deceive neighboring routers into believing that a router that has 211 been taken out of service (either intentionally or via a malicious 212 action by the same attacker) is still active and is in the process of 213 graceful restart. However, this attack is much more difficult than 214 the obvious replay of standard OSPFv3 hello packets to accomplish the 215 same thing by keeping the adjacency up. Since hello packets are sent 216 more predictably and knowledge of the key is not required, the risk 217 added by OSPFv3 graceful restart is insignificant. Hence, this 218 document does not raise any new security concerns other than those 219 covered in [OSPFv3], [OSPFv3-AUTH], and [GRACE]. 221 5. IANA Considerations 223 A new LSA function code will be required for the OSPFv3 grace-LSA. 224 Assignment of 0x000b has been suggested herein in the "OSPFv3 LSA 225 Function Codes" sub-registry of the "Open Shortest Path First v3 226 (OSPFv3) Parameters" registry. OSPFv3 grace-LSA TLVs and sub-TLVs 227 use the "OSPFv2 Grace LSA Top Level TLV" IANA sub-registry of the 228 "Open Shortest Path First v2 (OSPFv2) Parameters" registry. 230 6. Acknowledgments 232 Many thanks to Kireeti Kompella, Les Ginsberg, and David Ward with 233 whom much of this was discussed. The authors also wish to thank 234 Kunihiro Ishiguro and Vivek Dubey for their comments. 236 This document was produced using Marshall Rose's xml2rfc tool. 238 7. References 240 7.1. Normative References 242 [GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF 243 Restart", RFC 3623, November 2003. 245 [OSPF-TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 246 Extensions to OSPF", RFC 3630, September 2003. 248 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 250 [OSPFv3] Moy, J., Ferguson, D., and R. Coltun, "OSPF for IPv6", 251 RFC 2740, March 1997. 253 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 254 Requirement Levels", RFC 2119, March 1997. 256 7.2. Informative References 258 [MIB-INTF] 259 McCloghrie, K. and M. Rose, "Management Information Base 260 for network management of TCP/IP-based internets: 261 MIB-II", RFC 1213, March 1991. 263 [MIB-PERS] 264 McCloghrie, K. and F. Kastenholz, "The Interfaces Group 265 MIB", RFC 2863, June 2000. 267 [OSPFv3-AUTH] 268 Gupta, M. and N. Melam, "Authentication/Confidentiality 269 for OSPFv3", RFC 4552, June 2006. 271 Authors' Addresses 273 Padma Pillay-Esnault 274 Cisco Systems 275 3750 Cisco Way 276 San Jose, CA 95134 277 USA 279 Email: ppe@cisco.com 281 Acee Lindem 282 Redback Networks 283 102 Carric Bend Court 284 Cary, NC 27519 285 USA 287 Email: acee@redback.com 289 Full Copyright Statement 291 Copyright (C) The IETF Trust (2008). 293 This document is subject to the rights, licenses and restrictions 294 contained in BCP 78, and except as set forth therein, the authors 295 retain all their rights. 297 This document and the information contained herein are provided on an 298 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 299 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 300 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 301 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 302 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 303 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 305 Intellectual Property 307 The IETF takes no position regarding the validity or scope of any 308 Intellectual Property Rights or other rights that might be claimed to 309 pertain to the implementation or use of the technology described in 310 this document or the extent to which any license under such rights 311 might or might not be available; nor does it represent that it has 312 made any independent effort to identify any such rights. Information 313 on the procedures with respect to rights in RFC documents can be 314 found in BCP 78 and BCP 79. 316 Copies of IPR disclosures made to the IETF Secretariat and any 317 assurances of licenses to be made available, or the result of an 318 attempt made to obtain a general license or permission for the use of 319 such proprietary rights by implementers or users of this 320 specification can be obtained from the IETF on-line IPR repository at 321 http://www.ietf.org/ipr. 323 The IETF invites any interested party to bring to its attention any 324 copyrights, patents or patent applications, or other proprietary 325 rights that may cover technology that may be required to implement 326 this standard. Please address the information to the IETF at 327 ietf-ipr@ietf.org.