draft-holla-ospf-update-graceful-restart-01.txt March 2006 Network Working Group Internet Draft Ashok C. Holla Anup Kumar T Sujay Gupta Document: draft-holla-ospf-update-graceful- Huawei restart-01.txt Technologies, Bangalore Expires: September 2006 March 2006 Update to OSPF Graceful Restart procedure draft-holla-ospf-update-graceful-restart-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document suggests improvements to OSPF v2 Graceful Restart. The basic protocol working remains as specified in [OSPFGR]. The draft describes a two pronged approach for improving the current graceful restart mechanism. It improves the restarting router’s Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 1] draft-holla-ospf-update-graceful-restart-01.txt March 2006 ability to detect and react to topology changes. It also reduces the conservative behavior of the helper router in reacting to topology changes. Conventions used in this document In the text "GR" indicates Graceful Restart. The meaning of “Restarting Router” and “Helper Router” are as per [OSPFGR]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 2.1 Topology-Change LSAs.......................................3 2.2 Scope of the Topology-Change LSA...........................3 3. Enhancements to Graceful Restart mechanism.....................5 3.1 Operations of the Helper Router............................5 3.2 Operations of the Restarting Router........................7 3.3 Explicit feedback mechanism using Exit-Grace TLV...........8 4. Security Considerations........................................9 5. IANA Considerations............................................9 6. Backward Compatibility.........................................9 7. Special cases and considerations..............................10 8. Appendix......................................................10 Normative References.............................................11 Informative References...........................................12 Acknowledgments..................................................12 Authors’ Addresses...............................................12 Intellectual Property Statement..................................12 1. Introduction This document suggests improvements to OSPF v2 Graceful Restart. The basic protocol working remains as specified in [OSPFGR]. Existing specification for graceful restart in OSPFv2 has scope for optimization in terms of overall convergence time and avoidance of routing inconsistencies. This draft suggests methods to achieve the same. This draft provides mechanisms for the restarting router to detect and react to topology changes. It reduces the conservative behavior Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 2] draft-holla-ospf-update-graceful-restart-01.txt March 2006 of the helper router in reacting to topology changes. It also introduces an additional TLV for the Grace LSA, which provides an explicit mechanism through which a router can communicate its non participation as a helper router. This document is organized as follows: Section 2 introduces the concept of ‘Topology-Change LSA’. Section 3.1 describes a less conservative approach to be taken by the helper router in reacting to topology changes. Section 3.2 describes the additional checks a router under restart should perform to ensure faster detection of a topology change to facilitate an early exit of Graceful Restart. Section 3.3 introduces an additional TLV for the Grace LSA, which provides an explicit mechanism that can be used by the helper, to communicate with the restarting router. The proposed suggestions are backward compatible with [OSPFGR]. 2. Terminology 2.1 Topology-Change LSAs In [OSPFGR], helper routers detect topology changes by examining ‘changed LSAs’ as prescribed in Section 3.3 [OSPFDC]. However, this notion of ‘changed LSA’ is very broad and can be reduced in scope without affecting routing consistency. In this regard, the scope of a ‘Topology-Change LSA’ is defined. ‘Topology-Change LSAs’ characterize routing information which entails possible removal or modification of existing route entries in a router, i.e. they are LSAs which when processed, may remove or modify existing route entries. These LSAs should trigger helper routers to exit helper mode immediately. Other LSAs may trigger a router to exit helper mode. This is discussed in Section 3.1. 2.2 Scope of the Topology-Change LSA For an LSA to qualify as a ‘Topology-Change LSA’, it must satisfy one of the following two requirements: Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 3] draft-holla-ospf-update-graceful-restart-01.txt March 2006 (a) A Max-Aged LSA received or originated for which there exists a previous database copy MUST be considered as ‘Topology-Change LSA’ (b) A modified LSA received or originated for which there exists a previous database copy MUST be considered as ‘Topology-Change LSA’ All other LSAs received or originated MUST NOT be considered as ‘Topology-Change LSA’. Thus, this class excludes periodic refresh LSAs and also new LSAs without a previous database copy. In a further attempt to reduce the scope of ‘Topology-Change LSAs’, an implementation MAY choose to interpret non max-aged modified LSAs {case (b) above} as follows: If any existing information described in the previous database copy is missing or modified in the new LSA, then the new LSA MUST be considered as a ‘Topology-Change LSA’. In this regard, the criteria for an LSA to be considered as ‘Topology-Change LSA’ are: 1. For Router LSA: a. Change in the options field or any of the V, E or B bits in the LSA. b. Absence of any link piece (link ID, link Data tuple) previously present in the database copy. 2. For Network LSA: a. Change in the options field of the LSA. b. Change in Network mask. c. Absence of any previously attached router. 3. For Summary(Type-3 or 4) LSA: a. Change in the options field of the LSA. b. Change in the Network mask. c. Change in the metric to LS-INFINITY [OSPF]. 4. For External and NSSA LSAs: a. Change in the options field in the LSA. b. Change in the forwarding address. c. Change of the network mask. d. Change in the metric to LS-INFINITY [OSPF]. A non max-aged changed LSA which does not exhibit any of the modifications listed above, MAY NOT be considered as a ‘Topology- Change LSA’. This implies that if the change in the LSA is the presence of any new information not found in the previous copy (Ex: a new link piece in a Router LSA, a new attached router in a network LSA etc), the LSA MAY NOT be considered as a ‘Topology-Change LSA’. Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 4] draft-holla-ospf-update-graceful-restart-01.txt March 2006 3. Enhancements to Graceful Restart mechanism. 3.1 Operations of the Helper Router This section describes some modifications to the helper router behavior. The basic protocol behavior remains as specified in Section 3 of [OSPFGR]. Whenever a helper router encounters a non-refresh LSA (section 3.2 [OSPFGR]) which has to be flooded to a restarting router, it exits helper mode. This results in the restarting router quitting GR. This constraint is overkill, and can be optimized. 3.1.1 Entering Helper mode One of the criteria for a router to enter helper mode (section 3.1 [OSPFGR]) requires that all LSAs on the retransmit list on the helper router for the restarting router, should be periodic refresh LSAs. This criterion is very conservative and can be relaxed. In this draft, this has been achieved through an explicit definition of a ‘Topology-Change LSA’ (Section 2.1). This definition reduces the scope of topology changes that necessitate a router to terminate helper mode. In light of this, the checks that a router (say Router Y) should perform (Section 3.1 [OSPFGR]) while entering helper mode for a restarting router (say Router X), are modified as follows: On receiving Grace LSA from X, Y should examine the retransmit list for X. If Y finds any ‘Topology-Change LSA’ on the retransmit list and which are not implied acknowledgements to X, Y MUST NOT enter helper mode. Rest of the behavior should be as per section 3.1 [OSPFGR]. 3.1.2 Refusal to enter Helper mode In certain scenarios, a router may refuse to enter helper mode after receiving Grace LSAs from a restarting router. This could be due to a local policy configured on the router which prevents it from entering helper mode for the particular restarting router, or the type of graceful restart (planned/unplanned) or the duration of graceful restart. A router could refuse being a helper also due to the presence of ‘Topology-Change LSAs’ on the retransmit list for the restarting router. Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 5] draft-holla-ospf-update-graceful-restart-01.txt March 2006 In such cases, the router SHOULD immediately send Grace LSAs with the Exit-Grace TLV to the restarting router indicating its reluctance to enter helper mode. The processing and format of this TLV is explained in Section 3.3. This helps the restarting router in making an informed decision on whether to enter or abandon a Graceful Restart. In the absence of this mechanism, the restarting router will enter a Graceful Restart and later during adjacency formation, on examining the neighbor’s router/network LSA, it would exit graceful restart. With this mechanism, the restarting router can immediately abandon graceful restart and flush the grace LSAs originated, thus minimizing any possible routing inconsistencies and improving the overall convergence time. 3.1.3 Exiting Helper mode The existing criteria for exiting helper mode are very conservative. They can be relaxed to ensure that the restarting router is made to exit GR only when it is necessary to prevent routing inconsistencies. This has been achieved through an explicit definition of ‘Topology- Change LSA’ in Section 2.1. 1. Action on receiving or originating a ‘Topology-Change LSA’: If a helper router receives or originates a ‘Topology-Change LSA’ and the LSA has to be flooded to a restarting router, the helper router MUST immediately terminate helper mode for the restarting router. This ensures that the restarting router’s routing table does not have any invalid routes. Other LSAs are to be flooded without the helper router exiting helper mode. This might sometimes lead to routing inconsistencies. The modification to the route calculation as proposed below will correct any such problems. 2. Action on Route Calculation: When a helper runs SPF [OSPF], if a route is added or modified making a restarting router as the next hop, then the helper MUST immediately exit helper mode for that restarting router. 3.1.4 Operation of the Router on Exiting Helper Mode The helper router on exiting helper mode before the grace LSAs are flushed by the restarting router SHOULD, send Grace LSAs with the Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 6] draft-holla-ospf-update-graceful-restart-01.txt March 2006 Exit-Grace TLV to the restarting router (See description in Section 3.3), in addition to the operations specified in Section 3.1[OSPFGR]. 3.2 Operations of the Restarting Router This section describes some modifications to the restarting router behavior. Some responsibility of detecting topology changes has now been placed on the restarting router. The basic protocol behavior remains as specified in Section 3 [OSPFGR]. 3.2.1 Exit Graceful Restart A restarting router SHOULD perform the following actions along with those mentioned in the “Exit Graceful Restart” in Section 2.2 [OSPFGR]. 1. If on the restarting router, the inactivity timer fires for a neighbor, or there is a downward transition from 2-way to 1-way with a neighbor, the router SHOULD exit graceful restart. 2. The restarting router MAY, by examining its pre-restart Router and Network LSAs, build up a list of pre-restart neighbors. It can then start inactivity timers for these neighbors, except those on NBMA interfaces with DR-priority 0. This proves beneficial in certain scenarios (Refer Section 8: case A). 3. The restarting router, on receiving grace LSA containing the Exit- Grace TLV from a helper, MUST acknowledge the LSA and immediately quit GR. However, the LSA MUST NOT be stored in the database. The format of the TLV is described in Section 3.3. 3.2.2 Configurable Parameters Section 2.1 of [OSPFGR] allows a restarting router to use reliable flooding for its Grace LSAs. Since the reliable flooding mechanism takes indeterminate time, it is better if the restarting router waits for a bounded period of time before entering GR. If at the end of this time period, the reliable flooding is incomplete, the router will still enter Graceful Restart. In addition to the optional global parameters defined in Section B [OSPFGR], there MAY be a configurable parameter controlling the duration until which the restarting router must wait after initiating GR and before entering GR. 'RestartNotifyDuration' Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 7] draft-holla-ospf-update-graceful-restart-01.txt March 2006 This parameter symbolizes the duration in seconds for which the restarting router waits before entering Graceful Restart after sending Grace-LSAs. However, if all acknowledgements are received within this period, the router can immediately enter Graceful Restart. A suggested method of deriving a default value for this parameter is to keep it as a multiple of the largest retransmit timer for any neighbor. This ensures at least a ‘minimum’ number of retransmissions are sent to a neighbor. The grace period in the Grace LSAs MUST be inclusive of this time period, and as specified in [OSPFGR], SHOULD be less than 1800 seconds. 3.3 Explicit feedback mechanism using Exit-Grace TLV. The restarting router learns about a router not supporting helper mode by examining router and network LSAs (section 2.2 [OSPFGR]). This mechanism is sub-optimal, and in some scenarios, ineffectual (Section 8: Case B). This draft proposes a method for helper routers to communicate with the restarting router in an explicit manner, thus improving convergence time as well as reducing routing holes. 3.3.1 Sending Grace LSA with the Exit-Grace TLV. The Grace LSA with the Exit-Grace TLV SHOULD be sent as unicast Packets to the restarting router on Broadcast, NBMA and P2MP networks. However, on P2P interfaces, the packet should be sent to AllSPFRouters. [OSPF] When this TLV is included, the mandatory Grace TLV (described in [OSPFGR]) MUST NOT be included in the LSA. The sending of this Exit-Grace TLV MAY be made reliable. 3.3.2 Receiving Grace LSA with Exit-Grace TLV. A router, on receiving grace LSA containing the Exit-grace TLV from a neighbor, MUST acknowledge the LSA. The LSA MUST NOT be stored in the database or flooded. If the receiving router is under graceful- restart, it must immediately exit graceful restart. If the receiving router is not under Graceful Restart, the TLV will have no impact on the operations of the router. 3.3.3 Format of Exit-Grace LSA TLV Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 8] draft-holla-ospf-update-graceful-restart-01.txt March 2006 The Exit-Grace LSA TLV is enclosed in the Opaque link-local scoped Grace LSA. The format of the Grace LSA is specified in [OSPFGR]. The format of the Exit-Grace TLV is described below. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type field of the Exit-Grace TLV is assigned an experimental value of 4. The length field, defining the length of the value field in octets, MUST be 1. For non P2P networks, the value MUST be the IP address of the interface through which the helper sends the Grace LSA. For P2P networks, the value MUST be the Router-ID of the helper router. If the above TLV is present in a Grace LSA, it is mandatory for the Grace-Period TLV to be absent. The absence of the Grace-Period TLV ensures the receiving router dropping the LSA, as the Grace-Period TLV is specified as mandatory in [OSPFGR].In particular this ensures that implementations not supporting the Exit-Grace TLV will not process the LSA. The format of the Grace LSA other than the addition of the above TLV remains same as that mentioned in [OSPFGR]. 4. Security Considerations This draft raises no new security considerations other than that covered in [OSPFGR] and [OSPF]. 5. IANA Considerations This document describes a new TLV for Grace LSAs. The TLV type is to be assigned by IANA. The suggested value is 4. (Refer IANA). 6. Backward Compatibility The compliance of the feature mentioned here, allows for faster and optimal detection of topology changes and thus faster convergence. If one or more neighbors do not support Exit-Grace LSA TLV and/or other features mentioned above and support only RFC 3623, the protocol behavior specified in [OSPFGR] remains unimpaired. Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 9] draft-holla-ospf-update-graceful-restart-01.txt March 2006 However, one anomaly for backward compatibility introduced by this draft is documented in Section 7. 7. Special cases and considerations Area 0 RT1-----------------X-----------------RT2---------RT3 In the above topology RT1, X, RT2 and RT3 are all in area 0 X and RT2 are implementations which are based on this draft. However, RT1 is based on [OSPFGR] only. Scenario: X having initiated GR has completed adjacency formation with helper RT1, but, is still in the process of forming adjacency with RT2. At this point, RT3 originates a NEW type-5 LSA. Due to the nature of the modifications proposed in this draft, RT2 will not exit helper mode on receipt of this LSA from RT3 (refer sections 2.1 and 3.1.3). However, since X will flood this LSA to RT1, RT1 will exit helper mode. Since, RT1 and X are full with each other, X cannot detect RT1 quitting helper mode. Therefore, X continues with GR WITHOUT adding a route to the destination described by the new LSA, as X does not update its forwarding table during GR. This results in a routing hole. This condition will persist until X exits graceful restart. 8. Appendix Case A Problem Definition: It may not be possible for the restarting router to detect topology changes and exit graceful restart if a 'stub' neighbor goes down before receiving any hello packet from it. Thus the routing table of the restarting router and other routers will be invalid until grace period expiry. Ex: {topology}--------X-----Y (All in the same area) Where X undergoes a Graceful Restart, originates Grace LSAs to Y ('stub' neighbor). If Y goes down immediately after acknowledging the Grace LSA, there is no way X can detect this topology change event and exit GR, before grace period expiry. [Refer Section 2.2 [OSPFGR]] 'When to exit Graceful Restart', the criteria for exiting Graceful restart i.e. reforming adjacency with Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 10] draft-holla-ospf-update-graceful-restart-01.txt March 2006 all pre-restart neighbors will not be met, so X can exit only after grace-period expiry. Case B Since the protocol [OSPFGR] does not provide a method for a helper router to notify the restarting router, its exit of helper mode after the adjacency formation is complete, there are possibilities of routing holes existing for a bounded period of time, grace LSA being flushed or grace period expiry. Ex: Area 0 RT1-----------------X-----------------RT2---------RT3 | Area 1 | | RT4 In the above topology RT1, X, RT2 and RT3 are all in area 0; X and RT4 are in Area 1 which is a stub area. Scenario: X having initiated GR has completed adjacency formation with helpers RT1 and RT2 and still in the process of forming adjacency with RT4. At this point, RT3 originates a new type-5 LSA. Due to the nature of the protocol, RT2 and RT1 will exit helper mode on receipt of this LSA from RT3 and X respectively. Since, X will not send this LSA to RT4, RT4 will not exit helper mode. RT1 and RT2 have no mechanism to inform X about their quitting of helper mode (since they are already full with X). Therefore, X continues with GR WITHOUT adding a route to the destination described by the new LSA, as X will not update the forwarding table during GR. This results in a routing hole being created at X. This condition will persist until X exits GR. Normative References [OSPFGR] Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003. [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [OSPFDC] Moy, J., “Extending OSPF to support Demand Circuits”, RFC 1793, April 1995. Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 11] draft-holla-ospf-update-graceful-restart-01.txt March 2006 Informative References [IANA] Kompella.K, “IANA Considerations for OSPF”, draft-ietf-ospf- iana-01, work in progress. Acknowledgments The authors wish to thank Pradeep Shastry, K.L Srini, Saravanak, Abhay, Satish Hampali, Abhishek and Sandeep for their insightful comments and suggestions. The authors also wish to thank Acee Lindem, Don Goodspeed, Vishwas Manral and Padma Pillay-Esnault for their comments. Authors’ Addresses Ashok Chandrashekhar Holla Huawei Technologies Bangalore,India 560008 ashok_ch@huawei.com Anup Kumar T Huawei Technologies Bangalore,India 560008 anupkumart@huawei.com Sujay Gupta Huawei Technologies Bangalore,India 560008 sujayg@huawei.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 12] draft-holla-ospf-update-graceful-restart-01.txt March 2006 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Internet Draft Holla, Kumar & Gupta Expires - September 2006 [Page 13]