Hi Ondrej, >On Jun 18, 2015, at 1:14 PM, Ondrej Zajicek <[email protected]> >wrote: >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.
And there should not be - The Link Request mechanisms is based on LSAs being removed from the Link State Request List and NOT packet acknowledgement…. Hope this helps, Acee >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: [email protected]) >OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) >"To err is human -- to blame it on a computer is even more so." >_______________________________________________ >OSPF mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
