idnits 2.17.1 draft-ietf-ospf-hitless-restart-02.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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 2002) is 8104 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) == Unused Reference: 'Ref3' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'Ref5' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'Ref8' is defined on line 468, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2370 (ref. 'Ref2') (Obsoleted by RFC 5250) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref3' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref4' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref5' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'Ref6') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref7' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Moy 3 Internet Draft Sycamore Networks, Inc. 4 Expiration Date: August 2002 February 2002 5 File name: draft-ietf-ospf-hitless-restart-02.txt 7 Hitless OSPF Restart 8 draft-ietf-ospf-hitless-restart-02.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 the OSPF routing protocol, 34 whereby an OSPF router can stay on the forwarding path even as its 35 OSPF software is restarted. This is called "hitless restart" or 36 "non-stop forwarding". A restarting router may not be capable of 37 adjusting its forwarding in a timely manner when the network 38 topology changes. In order to avoid the possible resulting routing 39 loops the procedure in this memo automatically reverts to a normal 40 OSPF restart when such a topology change is detected, or when one or 41 more of the restarting router's neighbors do not support the 42 enhancements in this memo. Proper network operation during a hitless 43 restart makes assumptions upon the operating environment of the 44 restarting router; these assumptions are also documented. 46 Table of Contents 48 1 Overview ............................................... 2 49 1.1 Acknowledgments ........................................ 3 50 2 Operation of restarting router ......................... 3 51 2.1 Entering hitless restart ............................... 4 52 2.2 When to exit hitless restart ........................... 5 53 2.3 Actions on exiting hitless restart ..................... 6 54 3 Operation of helper neighbor ........................... 6 55 3.1 Entering helper mode ................................... 7 56 3.2 Exiting helper mode .................................... 8 57 4 Backward compatibility ................................. 9 58 5 Unplanned outages ...................................... 9 59 6 Interaction with Traffic Engineering .................. 10 60 7 Future Work ........................................... 10 61 References ............................................ 10 62 A Grace-LSA format ...................................... 11 63 Security Considerations ............................... 13 64 Authors' Addresses .................................... 13 66 1. Overview 68 Today many Internet routers implement a separation of control and 69 forwarding functions. Certain processors are dedicated to control 70 and management tasks such as OSPF routing, while other processors 71 perform the data forwarding tasks. This separation creates the 72 possibility of maintaining a router's data forwarding capability 73 while the router's control software is restarted/reloaded. We call 74 such a possibility "hitless restart" or "non-stop forwarding". 76 The problem that the OSPF protocol presents to hitless restart is 77 that, under normal operation, OSPF intentionally routes around a 78 restarting router while it rebuilds its link-state database. OSPF 79 avoids the restarting router to minimize the possibility of routing 80 loops and/or black holes caused by lack of database synchronization. 81 Avoidance is accomplished by having the router's neighbors reissue 82 their LSAs, omitting links to the restarting router. 84 However, if (a) the network topology remains stable and (b) the 85 restarting router is able to keep its forwarding table(s) across the 86 restart, it would be safe to keep the restarting router on the 87 forwarding path. This memo documents an enhancement to OSPF that 88 makes such hitless restart possible, and one that automatically 89 reverts back to a standard OSPF restart for safety when network 90 topology changes are detected. 92 In a nutshell, the OSPF enhancements for hitless restart are as 93 follows. The router attempting a hitless restart originates link- 94 local Opaque-LSAs, herein called Grace-LSAs, announcing the 95 intention to perform a hitless restart, and asking for a "grace 96 period". During the grace period its neighbors continue to announce 97 the restarting router in their LSAs as if it were fully adjacent 98 (i.e., OSPF neighbor state Full), but only if the network topology 99 remains static (i.e, the contents of the LSAs in the link-state 100 database having LS types 1-5,7 remain unchanged; periodic refreshes 101 are allowed). 103 There are two roles being played by OSPF routers during hitless 104 restart. First there is the router that is being restarted. The 105 operation of this router during hitless restart, including how the 106 router enters and leaves hitless restart, is the subject of Section 107 2. Then there are the router's neighbors, which must cooperate in 108 order for the restart to be hitless. During hitless restart we say 109 that the neighbors are executing in "helper mode". Section 3 covers 110 the responsibilities of a router executing in helper mode, including 111 entering and leaving helper mode. 113 1.1. Acknowledgments 115 The author wishes to thank John Drake, Vishwas Manral, Padma 116 Pillay-Esnault and Kent Wong for their helpful comments. 118 2. Operation of restarting router 120 After the router restarts/reloads, it must change its OSPF 121 processing somewhat until it re-establishes full adjacencies with 122 all its previously fully-adjacent neighbors. This time period, 123 between the restart/reload and the reestablishment of adjacencies, 124 is called "hitless restart". During hitless restart: 126 (1) The restarting router does not originate LSAs with LS types 127 1-5,7. Instead, the restarting router wants the other routers 128 in the OSPF domain to calculate routes using the LSAs that it 129 had originated prior to its restart. During this time, the 130 restarting router does not modify or flush received self- 131 originated LSAs, (see Section 13.4 of [Ref1]) but instead 132 accepts them as valid. In particular, the grace-LSAs that the 133 restarting router had originated before the restart are left 134 in place. Received self-originated LSAs will be dealt with 135 when the router exits hitless restart (see Section 2.3). 137 (2) The restarting router runs its OSPF routing calculations, as 138 specified in Section 16 of [Ref1]. This is necessary to 139 return any OSPF virtual links to operation. However, the 140 restarting router does *not* install OSPF routes into the 141 system's forwarding table(s), instead relying on the 142 forwarding entries that it had installed prior to the 143 restart. 145 (3) If the restarting router determines that it was Designated 146 Router on a given segment immediately prior to the restart, 147 it elects itself as Designated Router again. The restarting 148 router knows that it was Designated Router if, while the 149 associated interface is in Waiting state, an Hello packet is 150 received from a neighbor listing the router as Designated 151 Router. 153 Otherwise, the restarting router operates the same as any other OSPF 154 router. It discovers neighbors using OSPF's Hello protocol, elects 155 Designated and Backup Designated Routers, performs the Database 156 Exchange procedure to initially synchronize link-state databases 157 with its neighbors, and maintains this synchronization through 158 flooding. 160 The processes of entering hitless restart, and of exiting hitless 161 restart (either successfully or not) are covered in the following 162 sections. 164 2.1. Entering hitless restart 166 The router (call it Router X) is informed of the desire for its 167 hitless restart when an appropriate command is issued by the 168 network operator. The network operator may also specify the 169 length of the grace period, or the necessary grace period may be 170 calculated by the router's OSPF software. 172 In preparation for the hitless restart, Router X must perform 173 the following actions before its software is restarted/reloaded. 174 Note that common OSPF shutdown procedures are *not* performed, 175 since we want the other OSPF routers to act as if Router X 176 remains in continuous service. For example, Router X does not 177 flush its locally originated LSAs, since we want them to remain 178 in other routers' link-state databases throughout the restart 179 period. 181 (1) Router X must ensure that its forwarding table(s) is/are 182 up-to-date and will remain in place across the restart. 184 (2) The router must note in non-volatile storage the 185 cryptographic sequence numbers being used for each 186 interface. Otherwise it will take up to 187 RouterDeadInterval seconds after the restart before it 188 can start to reestablish its adjacencies, which would 189 force the grace period to be lengthened severely. 191 Router X then originates the grace-LSAs. These are link-local 192 Opaque-LSAs (see Appendix A). Their LS Age field is set to 0, 193 and the requested grace period (in seconds) is inserted into the 194 body of the grace-LSA. The precise contents of the grace-LSA are 195 described in Appendix A. 197 A grace-LSA is originated for each of the router's OSPF 198 interfaces. If Router X wants to ensure that its neighbors 199 receive the grace-LSAs, it should retransmit the grace-LSAs 200 until they are acknowledged (i.e, perform standard OSPF reliable 201 flooding of the grace-LSAs). If one or more fully adjacent 202 neighbors do not receive grace-LSAs, they will more than likely 203 cause premature termination of the hitless restart procedure 204 (see Section 4). 206 After the grace-LSAs have been sent, the router should store the 207 fact that it is performing hitless restart along with the length 208 of the requested grace period in non-volatile storage. (Note to 209 implementors: It may be easiest to simply store the absolute 210 time of the end of the grace period). The OSPF software should 211 then be restarted/reloaded, and when the reloaded software 212 starts executing the hitless restart modifications in Section 2 213 above are followed. (Note that prior to the restart, the router 214 does not know whether its neighbors are going to cooperate as 215 "helpers"; the mere reception of grace-LSAs does not imply 216 acceptance of helper responsibilities. This memo assumes that 217 the router would want to restart anyway, even if the restart is 218 not going to be hitless). 220 2.2. When to exit hitless restart 222 A Router X exits hitless restart when any of the following 223 occurs: 225 (1) Router X has reestablished all its adjacencies. Router X 226 can determine this by examining the router-LSAs that it 227 had last originated before the restart (called the "pre- 228 restart router-LSA"), and, on those segments where the 229 router is Designated Router, the pre-restart network- 230 LSAs. These LSAs will have been received from the helping 231 neighbors, and need not have been stored in non-volatile 232 storage across the restart. All previous adjacencies will 233 be listed as type-1 and type 2 links in the router-LSA, 234 and as neighbors in the body of the network-LSA. 236 (2) Router X receives an LSA that is inconsistent with its 237 pre-restart router-LSA. For example, X receives a router- 238 LSA originated by router Y that does not contain a link 239 to X, even though X's pre-start router-LSA did contain a 240 link to Y. This indicates that either a) Y does not 241 support hitless restart, b) Y never received the grace- 242 LSA or c) Y has terminated its helper mode for some 243 reason (Section 3.2). 245 (3) The grace period expires. 247 2.3. Actions on exiting hitless restart 249 On exiting "hitless restart", the reloaded router reverts back 250 to completely normal OSPF operation, reoriginating LSAs based on 251 the router's current state and updating its forwarding table(s) 252 based on the current contents of the link-state database. In 253 particular, the following actions should be performed when 254 exiting, either successfully or unsuccessfully, hitless restart. 256 (1) The router should reoriginate its router-LSAs for all 257 attached areas, to make sure they have the correct 258 contents. 260 (2) The router should reoriginate network-LSAs on all 261 segments where it is Designated Router. 263 (3) The router reruns its OSPF routing calculations (Section 264 16 of [Ref1]), this time installing the results into the 265 system forwarding table, and originating summary-LSAs, 266 Type-7 LSAs and AS-external-LSAs as necessary. 268 (4) Any remnant entries in the system forwarding table that 269 were installed before the restart, but that are no longer 270 valid, should be removed. 272 (5) Any received self-originated LSAs that are no longer 273 valid should be flushed. 275 (6) Any grace-LSAs that the router had originated should be 276 flushed. 278 3. Operation of helper neighbor 280 The helper relationship is per network segment. As a "helper 281 neighbor" on a segment S for a restarting router X, router Y has 282 several duties. It monitors the network for topology changes, and as 283 long as there are none, continues to its advertise its LSAs as if X 284 had remained in continuous OSPF operation. This means that Y's LSAs 285 continue to list an adjacency to X over network segment S, 286 regardless of the adjacency's current synchronization state. This 287 logic affects the contents of both router-LSAs and network-LSAs, and 288 also depends on the type of network segment S (see Sections 12.4.1.1 289 through 12.4.1.5 and Section 12.4.2 of [Ref1]). When helping over a 290 virtual link, the helper must also continue to set bit V in its 291 router-LSA for the virtual link's transit area (Section 12.4.1 of 292 [Ref1]). 294 Also, if X was the Designated Router on network segment S when the 295 helping relationship began, Y maintains X as Designated router until 296 the helping relationship is terminated. 298 3.1. Entering helper mode 300 When a router Y receives a grace-LSA from router X, it enters 301 helper mode for X, on the associated network segment, as long as 302 all the following checks pass: 304 (1) Y currently has a full adjacency with X (neighbor state 305 Full) over the associated network segment. On broadcast, 306 NBMA and Point-to-MultiPoint segments, the neighbor 307 relationship with X is identified by the IP interface 308 address in the body of the grace-LSA (see Appendix A). On 309 all other segment types X is identified by the grace- 310 LSA's Advertising Router field. 312 (2) There have been no changes in content to the link-state 313 database (LS types 1-5,7) since router X restarted. This 314 is determined as follows. Router Y examines the link- 315 state retransmission list for X over the associated 316 network segment. If there are any LSAs with LS types 317 1-5,7 on the list, then they all must be periodic 318 refreshes. If there are instead LSAs on the list whose 319 contents have changed (see Section 3.3 of [Ref9]), Y must 320 refuse to enter helper mode. 322 (3) The grace period has not yet expired. This means that the 323 LS age of the grace-LSA is less than the grace period 324 specified in the body of the grace-LSA (Appendix A). 326 (4) Local policy allows Y to act as the helper for X. 327 Examples of configured policies might be a) never act as 328 helper, b) never allow the grace period to exceed a Time 329 T, c) only help on software reloads/upgrades, or d) never 330 act as a helper for certain specific routers (specified 331 by OSPF Router ID). 333 There is one exception to the above requirements. If Y was 334 already helping X on the associated network segment, the new 335 grace-LSA should be accepted and the grace period should be 336 updated accordingly. 338 Note that Router Y may be helping X on some network segments, 339 and not on others. However, that circumstance will probably lead 340 to the premature termination of X's hitless restart, as Y will 341 not continue to advertise adjacencies on the segments where it 342 is not helping (see Section 2.2). 344 A single router is allowed to simultaneously serve as a helper 345 for multiple restarting neighbors. 347 3.2. Exiting helper mode 349 Router Y ceases to perform the helper function for its neighbor 350 Router X on a given segment when one of the following events 351 occurs. 353 (1) The grace-LSA originated by X on the segment is flushed. 354 This is the successful termination of hitless restart. 356 (2) The grace-LSA's grace period expires. 358 (3) A change in link-state database contents indicates a 359 network topology change, which forces termination of a 360 hitless restart. Specifically, if router Y installs a 361 new LSA in its database with LS types 1-5,7 and having 362 the following two properties, it should cease helping X. 363 The two properties of the LSA are a) the contents of the 364 LSA have changed; this includes LSAs with no previous 365 link-state database instance and the flushing of LSAs 366 from the database, but excludes periodic LSA refreshes 367 (see Section 3.3 of [Ref9]), and b) the LSA would have 368 been flooded to X, had Y and X been fully adjacent. As an 369 example of the second property, if Y installs a changed 370 AS-external-LSA, it should not terminate a helping 371 relationship with a neighbor belonging to a stub area, as 372 that neighbor would not see the AS-external-LSA in any 373 case. 375 When router Y exits helper mode for X on a given network 376 segment, it reoriginates its LSAs based on the current state of 377 its adjacency to Router X over the segment. In detail, Y takes 378 the following actions: (a) Y recalculates the Designated Router 379 for the segment, (b) Y reoriginates its router-LSA for the 380 segment's OSPF area, (c) if Y is Designated Router for the 381 segment, it reoriginates the network-LSA for the segment and (d) 382 if the segment was a virtual link, Y reoriginates its router-LSA 383 for the virtual link's transit area. 385 4. Backward compatibility 387 Backward-compatibility with unmodified OSPF routers is an automatic 388 consequence of the functionality documented above. If one or more 389 neighbors of a router requesting hitless restart are unmodified, or 390 if they do not received the grace-LSA, the hitless restart converts 391 to a normal OSPF restart. 393 The unmodified routers will start routing around the restarted 394 router X as it performs initial database synchronization, by 395 reissuing their LSAs with links to X omitted. These LSAs will be 396 interpreted by helper neighbors as a topology change, and by X as an 397 LSA inconsistency, in either case reverting to normal OSPF 398 operation. 400 5. Unplanned outages 402 The hitless restart mechanisms in this memo can be used for 403 unplanned outages. (Examples of unplanned outages include the crash 404 of a router's control software, an unexpected switchover to a 405 redundant control processor, etc). However, implementors and network 406 operators should note that attempting hitless restart from an 407 unplanned outage may not be a good idea, owing to the router's 408 inability to properly prepare for the restart (see Section 2.1). In 409 particular, it seems unlikely that a router could guarantee the 410 sanity of its forwarding table(s) across an unplanned restart. In 411 any event, implementors providing the option to recover hitlessly 412 from unplanned outages must allow a network operator to turn the 413 option off. 415 In contrast to the procedure for planned restart/reloads that was 416 described in Section 2.1, a router attempting hitless restart after 417 an unplanned outage must originate grace-LSAs *after* its control 418 software resumes operation. The following points must be observed 419 during this grace-LSA origination. 421 o The grace-LSAs must be originated and sent *before* the 422 restarted router sends any OSPF Hello Packets. 424 o The grace-LSAs are encapsulated in Link State Update Packets and 425 sent out all interfaces, even though the restarted router has no 426 adjacencies and no knowledge of previous adjacencies. 428 o To improve the probability that grace-LSAs be delivered, an 429 implementation may send them a number of times (see for example 430 the Robustness Variable in [Ref9]). 432 o The restart reason in the grace-LSAs must be set to unknown(0). 433 This enables the neighbors to decide whether they want to help 434 the router through an unplanned restart. 436 6. Interaction with Traffic Engineering 438 The operation of the Traffic Engineering Extensions to OSPF [Ref4] 439 during OSPF Hitless Restart is specified in [Ref7]. 441 7. Future Work 443 The interactions between OSPF Hitless Restart and the Multicast 444 Extensions to OSPF [Ref6] have not been specified in this memo. 446 References 448 [Ref1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 450 [Ref2] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 451 1998. 453 [Ref3] Murphy, S., M. Badger and B. Wellington, "OSPF with Digital 454 Signatures", RFC 2154, June 1997. 456 [Ref4] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 457 Extensions to OSPF", work in progress. 459 [Ref5] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA Option", 460 work in progress. 462 [Ref6] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 463 1994. 465 [Ref7] Kompella, K., et. al., "Routing Extensions in Support of 466 Generalized MPLS", work in progress. 468 [Ref8] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 469 1793, April 1995. 471 [Ref9] Fenner, W., "Internet Group Membership Protocol, Version 2", 472 RFC 2236, November 1997. 474 A. Grace-LSA format 476 The grace-LSA is a link-local scoped Opaque-LSA [Ref2] having Opaque 477 Type of 3 and Opaque ID equal to 0. Grace-LSAs are originated by a 478 router that wishes to execute a hitless restart of its OSPF 479 software. A grace-LSA requests that the router's neighbors aid it in 480 its hitless restart by continuing to advertise the router as fully 481 adjacent during a specified grace period. 483 Each grace-LSA has LS age field set to 0 when the LSA is first 484 originated; the current value of LS age then indicates how long ago 485 the restarting router made its request. The body of the LSA is TLV- 486 encoded. The TLV-encoded information includes the length of the 487 grace period, the reason for the hitless restart and, when the 488 grace-LSA is associated with a broadcast, NBMA or Point-to- 489 MultiPoint network segment, the IP interface address of the 490 restarting router. 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | LS age | Options | 9 | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | 3 | 0 | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Advertising Router | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | LS sequence number | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | LS checksum | length | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | | 506 +- TLVs -+ 507 | ... | 509 The format of the TLVs within the body of a grace-LSA is the same as 510 the TLV format used by the Traffic Engineering Extensions to OSPF 511 [Ref4]. The TLV header consists of a 16-bit Type field and a 16-bit 512 length field, and is followed by zero or more bytes of value. The 513 length field indicates the length of the value portion in bytes. The 514 value portion is padded to four-octet alignment, but the padding is 515 not included in the length field. For example, a one byte value 516 would have the length field set to 1, and three bytes of padding 517 would be added to the end of the value portion of the TLV. 519 The following is the list of TLVs that can appear in the body of a 520 grace-LSA. 522 o Grace Period (Type=1, length=4). The number of seconds that the 523 router's neighbors should continue to advertise the router as 524 fully adjacent, regardless of the the state of database 525 synchronization between the router and its neighbors. Since this 526 time period began when grace-LSA's LS age was equal to 0, the 527 grace period terminates when either a) the LS age of the grace- 528 LSA exceeds the value of Grace Period or b) the grace-LSA is 529 flushed. See Section 3.2 for other conditions which terminate 530 the grace period. This TLV must always appear in a grace-LSA. 532 o Hitless restart reason (Type=2, length=1). Encodes the reason 533 for the router restart, as one of the following: 0 (unknown), 1 534 (software restart), 2 (software reload/upgrade) or 3 (switch to 535 redundant control processor). This TLV must always appear in a 536 grace-LSA. 538 o IP interface address (Type=3, length=4). The router's IP 539 interface address on the subnet associated with the grace-LSA. 540 Required on broadcast, NBMA and Point-to-MultiPoint segments, 541 where the helper uses the IP interface address to identify the 542 restarting router (see Section 3.1). 544 DoNotAge is never set in a grace-LSA, even if the grace-LSA is 545 flooded over a demand circuit. This is because the grace-LSA's LS 546 age field is used to calculate the extent of the grace period. 548 Grace-LSAs have link-local scope because they only need to be seen 549 by the router's direct neighbors. 551 Security Considerations 553 One of the ways to attack a link-state protocol such as OSPF is to 554 inject false LSAs into, or corrupt existing LSAs in, the link-state 555 database. Injecting a false grace-LSA would allow an attacker to 556 spoof a router that, in reality, has been withdrawn from service. 557 The standard way to prevent such corruption of the link-state 558 database is to secure OSPF protocol exchanges using the 559 Cryptographic authentication specified in [Ref1]. An even stronger 560 way of securing link-state database contents has been proposed in 561 [Ref3]. 563 Authors' Addresses 565 J. Moy 566 Sycamore Networks, Inc. 567 150 Apollo Drive 568 Chelmsford, MA 01824 569 Phone: (978) 367-2505 570 Fax: (978) 256-4203 571 email: jmoy@sycamorenet.com