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: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
