[OSPF] Incremental LSDB Sync

["Alvaro Retana (aretana)" <[e-mail]>]

Hi!

During Dimitri's presentation of his "Phased OSPF Link-State Database
Synchronization' draft (draft-dimitri-ospf-phased-db-sync) in Beijing I
mentioned that the same result (2 stage LSDB sync) can be achieved using
OOB Resync (rfc4811).

I just posted a new draft that talks about that.  I called it
'Incremental LSDB Sync" (ILS) and it uses existing mechanisms.  Here's
the abstract:

          OSPF Incremental Link State Database Synchronization
                        draft-retana-ospf-ils-00

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.



Looks like the draft is not up on the web site yet, so I'm attaching a
copy below.

Comments/thoughts/flames?

Thanks!

Alvaro.

----------------------------------------------------------------



Network Working Group                                          A. Retana
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Informational                         November 30, 2010
Expires: June 3, 2011


          OSPF Incremental Link State Database Synchronization
                        draft-retana-ospf-ils-00

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 June 3, 2011.

Copyright Notice

   Copyright (c) 2010 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
   described in the Simplified BSD License.



Retana                    Expires June 3, 2011                  [Page 1]


Internet-Draft         OSPF Incremental LSDB Sync          November 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
   3.  Incremental LSDB Synchronization Process  . . . . . . . . . . . 3
     3.1.  Graceful Restart  . . . . . . . . . . . . . . . . . . . . . 4
   4.  Backward Compatibility  . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6





































Retana                    Expires June 3, 2011                  [Page 2]


Internet-Draft         OSPF Incremental LSDB Sync          November 2010


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 RFC 2119 [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
           SHOULD be classified as requiring prioritized
           synchronization, while other LSAs MAY be classified as not
           requiring it.

   Prioritized LSDB Synchronization
           This step corresponds to the adjacency establishment process
           as described in RFC 2328 [RFC2328].

           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.



Retana                    Expires June 3, 2011                  [Page 3]


Internet-Draft         OSPF Incremental LSDB Sync          November 2010


   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
           changes to the process are needed.








Retana                    Expires June 3, 2011                  [Page 4]


Internet-Draft         OSPF Incremental LSDB Sync          November 2010


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 RFC 2328 [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.


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 author 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.




Retana                    Expires June 3, 2011                  [Page 5]


Internet-Draft         OSPF Incremental LSDB Sync          November 2010


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.


Author's Address

   Alvaro Retana
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC  27709
   USA

   Phone: [phone]
   Email: [e-mail]





















Retana                    Expires June 3, 2011                  [Page 6]