Subject: OSPF Link state request list management question

From: "Dovolsky, Dan" <[email-masked]>
Date: Tue, 10 Dec 2002 18:59:37 -0500

BSD.

I will be appreciated to anyone who can help me with following question:

Suppose we have some triangle network topology (routers A,B and C) where each router has two adjacencies.

Router A has rebooted. After restart, it attempts to reestablish
adjacency with routers B and C. After exchange DB descriptors, Router B decided,
that it has to request some missing LSA from router A and send request to it.

Immediately after that, router B received this missing LSA from router C
(adjacency between A and C comes first). When the requested LSA received from router A,
adjacency between B and A is restarted.

This behavior proved to be real on Cisco router, and it actually defined by spec:

OSPF RFC2328, section 13.  The Flooding Procedure states:

      "(6)      Else, if there is an instance of the LSA on the sending
        neighbor's Link state request list, an error has occurred in the
        Database Exchange process.  In this case, restart the Database
        Exchange process by generating the neighbor event BadLSReq for
        the sending neighbor and stop processing the Link State Update
        packet."

However, in section 13.3.  Next step in the flooding procedure:

        "Also   included in this part of the flooding procedure is the
         maintenance of the neighbors' Link state request lists.
       ....
            (b) Else, if the adjacency is not yet full (neighbor state
                is Exchange or Loading), examine the Link state request
                list associated with this adjacency.  If there is an
                instance of the new LSA on the list, it indicates that
                the neighboring router has an instance of the LSA
                already.  Compare the new LSA to the neighbor's copy:

                o   If the new LSA is less recent, then examine the next
                    neighbor.

                o   If the two copies are the same instance, then delete
                    the LSA from the Link state request list, and
                    examine the next neighbor.[20]

                o   Else, the new LSA is more recent.  Delete the LSA
                    from the Link state request list.

            (c) If the new LSA was received from this neighbor, examine
                the next neighbor."

My question is why OSPF needs that section 13 (6) part and require unnecessary adjacency restarting ?

Following to this section 6 text (sections 7 and 8) define this case processing very well:
    
   "(7) Else, if the received LSA is the same instance as the database
        copy (i.e., neither one is more recent) the following two steps
        should be performed:

        (a) If the LSA is listed in the Link state retransmission list
            for the receiving adjacency, the router itself is expecting
            an acknowledgment for this LSA.  The router should treat the
            received LSA as an acknowledgment by removing the LSA from
            the Link state retransmission list.  This is termed an
            "implied acknowledgment".  Its occurrence should be noted
            for later use by the acknowledgment process (Section 13.5).

        (b) Possibly acknowledge the receipt of the LSA by sending a
            Link State Acknowledgment packet back out the receiving
            interface.  This is explained below in Section 13.5.

    (8) Else, the database copy is more recent.  If the database copy
        has LS age equal to MaxAge and LS sequence number equal to
        MaxSequenceNumber, simply discard the received LSA without
        acknowledging it. (In this case, the LSA's LS sequence number is
        wrapping, and the MaxSequenceNumber LSA must be completely
        flushed before any new LSA instance can be introduced).
        Otherwise, as long as the database copy has not been sent in a
        Link State Update within the last MinLSArrival seconds, send the
        database copy back to the sending neighbor, encapsulated within
        a Link State Update Packet. The Link State Update Packet should
        be sent directly to the neighbor..."

Regards,
Dan Dovolsky.

Office: 703-847-2438
[email-masked]