When an LSAck for an older LSA is received...

[ChuYinsu]

Hi, when I was testing BIRD in the lab, I encountered a question.

First, this is the topology, which is a very simple one, two computers
connect each other via a twisted pair:

          Laptop(eth0,
192.168.0.1)---------Point-to-Point---------(eth0,
192.168.0.2)Personal Computer(PC)
          |          |          |
                               |        |
          |          |          |
                               |        |
     -----           |           -------------
                          -----          -----
     |               |                       |
                          |                   |
    tap0          eth1                  tap1
               tap0                tap1
10.1.1.2/16  10.32.31.239/16   10.2.1.2/16
11.1.1.2/16         11.2.1.2/16

And following is part of the Wireshark capture file(plus my
understandings behind "//"):

NO.     Time            Source          Destination     Proto.  Info.
7	14.064842000	192.168.0.2	192.168.0.1	OSPF	DB Descr.
8	14.066061000	192.168.0.1	192.168.0.2	OSPF	DB Descr.
9	14.067224000	192.168.0.2	192.168.0.1	OSPF	DB Descr.
10	14.067619000	192.168.0.1	192.168.0.2	OSPF	DB Descr.
//Above is the Master/Slave negotiation and the DD packets
transferring procedure.

12	17.071181000	192.168.0.2	224.0.0.5	OSPF	Hello Packet
13	17.071241000	192.168.0.1	192.168.0.2	OSPF	LS Request
14	17.071563000	192.168.0.2	192.168.0.1	OSPF	LS Update   //Age: 9secs,
SeqNum: 0x80000001, Checksum: 0x2351
//After exchanging DD packets, Laptop requires LSA from the PC. And
now in Laptop, the conversation between PC and Laptop has been in
state FULL.

15	18.073167000	192.168.0.1	224.0.0.5	OSPF	LS Update   //Age: 1sec,
SeqNum: 0x80000002, Checksum: 0x366b
//Before PC is going to send LSR packet to Laptop, Laptop has flooded
its newly originated LSA. When PC receives this LSU packet, it removes
its LSR packet on the list.
//And now in PC, the conversation between PC and Laptop has been in state FULL.

18	19.074720000	192.168.0.2	224.0.0.5	OSPF	LS Update   //Age: 1sec,
SeqNum: 0x80000002, Checksum: 0xae33
//So the PC also originates its new LSA and floods it.

19	19.075041000	192.168.0.1	192.168.0.2	OSPF	LS Acknowledge
//This is for the No.14 LSU packet, delayed.

20	19.077611000	192.168.0.2	192.168.0.1	OSPF	LS Acknowledge
//This is for the No.15 LSU packet, delayed.

21	20.079119000	192.168.0.1	224.0.0.5	OSPF	Hello Packet
24	24.083617000	192.168.0.2	192.168.0.1	OSPF	LS Update
//Here is the question, why this LSU is sent?

25	25.090754000	192.168.0.1	192.168.0.2	OSPF	LS Acknowledge
//This is for the No.24 LSU packet.

26	27.093352000	192.168.0.2	224.0.0.5	OSPF	Hello Packet
27	30.096506000	192.168.0.1	224.0.0.5	OSPF	Hello Packet

After checking debugging information in the syslog, I thought the
reason might be this:

In the PC's syslog, after the PC receiving the No.19 LSAck, here are some lines:
(time information, etc.) test-ubuntu bird: testing_ospf: I have: Age:
0, Seqno: 0x80000002, Sum: 44595
(time information, etc.) test-ubuntu bird: testing_ospf: He has: Age:
9, Seqno: 0x80000001, Sum: 9041

It seems that it's comparing the received LSAck with the LSA in the
LSDB. PC finds that the LSU that the LSAck acknowledges cannot be
found in the LSDB - however there's a newer one. So the PC simply
sends another newer LSU(which is the No.24 packet) to Laptop. Is this
right?

However, where is the corresponding operation described in RFC 2328? I
searched the Section 13.7 Receiving link state acknowledgments without
any results.

Thanks!