idnits 2.17.1 draft-dong-ospf-purge-lsa-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (October 24, 2011) is 4568 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft X. Zhang 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 26, 2012 October 24, 2011 7 Purge LSA for OSPF flushing 8 draft-dong-ospf-purge-lsa-00 10 Abstract 12 In some scenarios current OSPF flushing mechanism may incur problem 13 of delaying the deletion of invalid Link State Advertisement (LSA) 14 and result in desynchronization of link state database. This 15 document proposes a backward compatible solution to solve this 16 problem. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 26, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Problem with OSPF Flushing Mechanism . . . . . . . . . . . . . 3 60 3. Proposed Flushing Mechanism . . . . . . . . . . . . . . . . . . 4 61 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 4 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 65 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 The LSA flushing mechanism of OSPF is described in [RFC2328]. In 71 some scenarios such as route oscillation, this flushing mechanism may 72 incur problem of delaying the deletion of invalid LSA on some 73 routers, and result in desynchronization of link state database. 75 This document proposes a backward compatible solution to solve this 76 problem. 78 2. Problem with OSPF Flushing Mechanism 80 As described in section 14.1 of [RFC2328], an LSA can be flushed from 81 the routing domain by setting its LS age to MaxAge, while leaving its 82 LS sequence number alone, and then reflooding the LSA. The MaxAge 83 LSA must be removed immediately from the router's link state database 84 as soon as both a) it is no longer contained on any neighbor Link 85 state retransmission lists and b) none of the router's neighbors are 86 in states Exchange or Loading. And section 12.1.6 of [RFC2328] 87 specifies that "As soon as this flood has been acknowledged by all 88 adjacent neighbors, a new instance can be originated with sequence 89 number of InitialSequenceNumber." Thus after the MaxAge LSA is 90 removed, a new instance with sequence number equal to 91 InitialSequenceNumber would be originated. 93 Under some scenarios such as route oscillation, such procedure may 94 delay the deletion of invalid LSA in the link state database of some 95 routers thus cause desynchronization of link state database. One 96 example is described as below: 98 a. Router X and router Y formed OSPF adjacency, X advertised an AS- 99 external-LSA with sequence number set to InitialSequenceNumber to Y. 100 Then route oscillation happens to this external route. 102 b. X flushes the AS-external-LSA by setting the LS age to MaxAge and 103 sends it to Y. After some time X does not receive the acknowledgment 104 from Y, then X retransmits the flushing LSA to Y. 106 c. Y receives the first flushing LSA and sends Acknowledgment back 107 to X. Then Y receives the second flushing LSA and sends back the 108 second acknowledgment. 110 d. X receives the first Acknowledgment and remove the flushing LSA 111 from its link state database. Then X originates this AS-external-LSA 112 with InitialSequenceNumber and sends it to Y. Soon the LSA is flushed 113 again due to route oscillation. After doing this, X receives the 114 second acknowledgment for the previous flushing from Y, then the 115 flushing LSA is removed from X's link state database. 117 e. Y receives this new LSA and install it into its link state 118 database. Then in a short time Y receives the flushing LSA. If the 119 time interval between this flushing LSA and previous LSA is shorter 120 than MinLSArrival, this flushing LSA would be discarded by Y. 122 As a result, router X does not have this LSA in its link state 123 database, but router Y will keep this LSA until the LS age reaches 124 MaxAge. Such desynchronization of link state database may cause 125 traffic blackholing or forwarding loops. 127 The root cause of this problem is that after LSA flushing the router 128 would set the LS sequence number of the new LSA instance back to 129 InitialSequenceNumber. And in some cases the LSA updates and the 130 acknowledgments may become out of sync. 132 3. Proposed Flushing Mechanism 134 This section defines a flushing mechanism to solve the problem 135 described in section 2. This flushing mechanism SHOULD be used when 136 LS sequence number is not to wrap. When it is time for the LS 137 sequence number is to wrap, procedures in Section 14.1 of [RFC2328] 138 MUST be used. 140 When an LSA needs to be flushed, the router SHOULD keep only the 141 header of the LSA, set its LS age to 0 and increment the LS sequence 142 number by 1. Such an LSA is called Purge LSA. The router SHOULD 143 flood this Purge LSA to neighbors for LSA flushing. The Purge LSA 144 SHOULD be retained in the database until the LS age reaches MaxAge. 146 When a new instance of the LSA is to be originated, if a 147 corresponding Purge LSA exists in the database, the router SHOULD 148 advance the LSA's LS sequence number one past the LS sequence number 149 of the corresponding Purge LSA. Then the corresponding Purge LSA 150 SHOULD be removed from the router's link state database. 152 4. Backward Compatibility 154 The proposed flushing mechanism is backward compatible with legacy 155 OSPF implementations. Legacy OSPF routers would treat the received 156 Purge LSA as a newer instance than its database copy, since the 157 sequence number is larger. And since the Purge LSA contains only LSA 158 header, it will not be used in the routing table calculation. When 159 the LS age of this purge LSA reaches MaxAge, it would be removed from 160 the router's link state database. 162 5. IANA Considerations 164 This document makes no request of IANA. 166 6. Security Considerations 168 This document does not change the security properties of OSPF. 170 7. Acknowledgements 172 The authors would like to thank Yongming Fu and Yong Miao for their 173 helps and suggestions to this document. 175 8. Normative References 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, March 1997. 180 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 182 Authors' Addresses 184 Jie Dong 185 Huawei Technologies 186 Huawei Building, No.156 Beiqing Rd. 187 Beijing 100095 188 China 190 Email: jie.dong@huawei.com 192 Xudong Zhang 193 Huawei Technologies 194 Huawei Building, No.156 Beiqing Rd. 195 Beijing 100095 196 China 198 Email: zhangxudong@huawei.com