[OSPF] Request for clarification of OSPF loading phase

[Ondrej Zajicek <[e-mail]>]

Hello

We noticed that in RFC 2328 there are some border cases of OSPF loading
phase that are vague enough to cause compatibility problems between
different implementations. It is the Link State Request / Update exchange
described mostly in section 10.9 .

The main issue is that LSREQ packets often contain more LSRs that can be
answered in one LSUPD packet and the fact that there is no explicit way
how to see match LSUPD packets are proper responses to LSREQ packets.


There are generally two approaches to this:

(1) Router A sends LSREQ packet. When it is received by router B, router B
immendiately answers with multiple LSUPD packets covering all LSRs.

When router A receives LSUPD packet, it removes appropriate LSRs from Link
State Request List, but only if all LSRs sent in the last LSREQ packet
were removed then the next LSREQ packet is sent.


(2) Router A sends LSREQ packet. When it is received by router B, router B
immediately answers with just one LSUPD with just enough LSAs to fit to
one LSUPD packet.

When router A receives LSUPD packet, it truncates the Link State Request
List and immediately sends the next LSREQ packet.


RFC 2328 10.9 is a bit vague w.r.t. this issue, some sentences suggest
interpretation (1), while others suggest (2). Example in RFC 2328 10.10
suggests (2) as it contains just one LS Update after LS Request, but
that may be just ommited detail.

Approach (2) also has a problem that it cannot distinguish LSUPD that is
a reaction to LSREQ from some random asynchronous LSUPD that incidentally
covers the beginning of the Link State Request List.


We saw both approaches used in existing OSPF implementations.
Unsurprisingly, mixing them causes some strange problems.
What is the proper interpretation of this aspect of RFC 2328?


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: [e-mail])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."