Network Working Group A. Retana Internet-Draft Hewlett-Packard Co. Intended status: Informational A. Lindem Expires: January 14, 2013 Ericsson July 13, 2012 OSPF Incremental Link State Database Synchronization draft-retana-ospf-ils-01 Abstract The ability of OSPF to transport non-routing information to be used by other applications was defined by the Opaque LSA Option. In order to not impact the convergence of routing information, this document describes a simple process to incrementally synchronize the routing and non-routing information residing in an OSPF link-state database. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 14, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Retana & Lindem Expires January 14, 2013 [Page 1] Internet-Draft OSPF Incremental LSDB Sync July 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. Incremental LSDB Synchronization Process . . . . . . . . . . . 3 3.1. Graceful Restart . . . . . . . . . . . . . . . . . . . . . 4 3.2. Flooding and Database Synchronization . . . . . . . . . . . 5 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Changes between the -00 and -01 versions. . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Retana & Lindem Expires January 14, 2013 [Page 2] Internet-Draft OSPF Incremental LSDB Sync July 2012 1. Introduction Opaque LSAs [RFC5250] provide the ability for OSPFv2 [RFC2328] to transport non-routing information to be used by other applications. A similar capability exists in OSPFv3 [RFC5340] through the use of the U-bit and an appropriate LSA Function Code. Throughout this document Opaque LSAs and ones with unrecognized link-state types will be referred to simply as "opaque". The presence of opaque information in the OSPF Link-State Database (LSDB) may result in longer database exchange times, especially in cases where the amount of data is significantly larger than the routing-specific information. In order to not impact the convergence of routing information, this document describes a simple process to incrementally synchronize the information residing in an OSPF LSDB. The process uses existing mechanisms. 2. Requirements Language 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 [RFC2119]. 3. Incremental LSDB Synchronization Process The Incremental LSBD Synchronization (ILS) process consists of the following steps: LSA Prioritization The contents of the local LSDB are classified to determine which LSAs require prioritized synchronization. In general, LSAs containing routing-specific information MUST be classified as requiring prioritized synchronization, while other LSAs MAY be classified as not requiring it. All routers in the OSPF routing domain should use the same criteria for LSA prioritization. While this is not required for correct OSPF operation, it is required for deterministic operation of the applications using the opaque LSAs. Prioritized LSDB Synchronization This step corresponds to the adjacency establishment process as described in [RFC2328]. Retana & Lindem Expires January 14, 2013 [Page 3] Internet-Draft OSPF Incremental LSDB Sync July 2012 LSAs classified as not requiring prioritized synchronization MUST NOT be included in Database Description (DBD) Packets during the Database Exchange Process. The OSPF routing table structure SHOULD be calculated before moving on to the next step. Final LSDB Synchronization In this step, any remaining LSAs in the LSDB SHOULD be synchronized. The routers MUST use the Out-of-Band LSDB Resynchronization [RFC4811] (OOB Resync) mechanism, which provides a way to resynchronize the LSDB without affecting the advertised neighbor state. The process is described in terms of LSAs containing (or not) routing-specific information, but it may be generalized to include any other criteria considered significant in the local network and protocol instance. The last step in the process MAY be used recursively to achieve an incremental LSDB synchronization through different types of data, making it also applicable to environments where only non-routing information exists. 3.1. Graceful Restart The restart of the OSPF software in a router also presents an opportunity for LSDB synchronization. Because the restarting router is still in the forwarding path, it is important for the routing information in the LSDB to be synchronized as fast as possible. ILS can be used, with minor modifications, to reduce the synchronization time and the probability of network topology changes. Graceful OSPF Restart Graceful OSPF Restart for OSPFv2 [RFC3623] and OSPFv3 [RFC5187] don't specify any changes to the adjacency establishment process. ILS can be used by the Helper Neighbor during the Grace Period; if so, then the Helper Node MUST include any Grace- LSAs in the DBD Packets during the Prioritized LSDB Synchronization step. OSPF Restart Signaling OSPF Restart Signaling [RFC4812] defines a mechanism to inform neighbors about a local restart, in which the LSDB synchronization is achieved using OOB Resync. In other words, the Prioritized LSDB Synchronization step would use OOB Resync if the non-restarting router uses ILS. No other Retana & Lindem Expires January 14, 2013 [Page 4] Internet-Draft OSPF Incremental LSDB Sync July 2012 changes to the process are needed. 3.2. Flooding and Database Synchronization In order to maintain OSPF reliable flooding, separate neighbor flooding state must be maintained for the lower priority LSAs and used when determining whether a lower priority LSA has been flooded or put on a neighbor's retransmission list. The rules for flooding lower-priority LSAs and deleting lower priority MaxAge LSAs are modified for ILS synchronization. Neighbor state MUST be maintained as to whether low-priority LSAs have been synchronized with a given neighbor. In this document, this lower priority state will be referred to as ILS-state. This ILS-state will not advance until a neighbor reaches Full state and will return to Down ILS-state should the neighbor fall from Full state. If a given neighbor's ILS-state is Exchange or higher, then lower priority LSAs should be flooded to that neighbor. This similar to the general LSA flooding rules in Section 13.1 of [RFC2328]. Consistent with Section 14.1 in [RFC2328], a lower priority MaxAge LSA cannot be removed the Link State Database if any the router is in Exchange or Loading ILS-state. If multiple ILS synchronizations are used for synchronization different priorities of LSAs, separate ILS-state MUST be maintained for each priority and the previously described rules MUST be applied at each priority. 4. Backward Compatibility The operation of ILS depends on the support of OOB Resync during synchronization; no backwards compatibility issues exist there [RFC4811]. If OOB Resync is not supported by one of the routers, then the LSDB synchronization would fall back to the adjacency establishment process as described in [RFC2328]. If OOB Resync is supported, but ILS has not been implemented by all the routers involved, the operation is still backwards compatible. Note that the process (Section 3) depends on the database description by the local router. In other words, a router may decide to not fully describe the contents of its LSDB to its neighbor during the adjacency establishment process, and later use OOB Resync to incrementally describe the difference; the receiver doesn't need to be aware of ILS. The benefits of ILS may only be partially realized if not supported by all the routers involved in synchronization. Retana & Lindem Expires January 14, 2013 [Page 5] Internet-Draft OSPF Incremental LSDB Sync July 2012 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations The process described in this document does not introduce any new security issues into the OSPF protocol. 7. Acknowledgements The authors would like to thank Abhay Roy and Liem Nguyen for their comments, and Dimitri Papadimitriou for his comments and for providing the motivation for this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4811] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link State Database (LSDB) Resynchronization", RFC 4811, March 2007. 8.2. Informative References [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003. [RFC4812] Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart Signaling", RFC 4812, March 2007. [RFC5187] Pillay-Esnault, P. and A. Lindem, "OSPFv3 Graceful Restart", RFC 5187, June 2008. [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. Retana & Lindem Expires January 14, 2013 [Page 6] Internet-Draft OSPF Incremental LSDB Sync July 2012 Appendix A. Changes between the -00 and -01 versions. o Added a new section explaining how to maintain reliable flooding for the low priority LSAS. o Updated authors and contact information. Authors' Addresses Alvaro Retana Hewlett-Packard Co. 2610 Wycliff Road Raleigh, NC 27607 USA Email: alvaro.retana@hp.com Acee Lindem Ericsson 102 Carric Bend Court Cary, NC 27519 USA Email: acee.lindem@ericsson.com Retana & Lindem Expires January 14, 2013 [Page 7]