Archive

Re: [OSPF] Request for clarification of OSPF loading phase

"Acee Lindem (acee)" <acee@cisco.com> Thu, 18 June 2015 18:57 UTC

From: "Acee Lindem (acee)" <acee@cisco.com>
To: OSPF WG List <ospf@ietf.org>
Thread-Topic: [OSPF] Request for clarification of OSPF loading phase
Thread-Index: AQHQqfiQk7ECBxfNrU6CoiyfNaP/TQ==
Date: Thu, 18 Jun 2015 18:57:03 +0000
Message-ID: <D1A88CCE.24AD4%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-ID: <E0DD7F4FE0261A43B6786F82698C6472@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/LMEpjQnSeXjXu_8XmV2hcHkCjfc>
Subject: Re: [OSPF] Request for clarification of OSPF loading phase
Precedence: list

Hi Ondrej, 

>On Jun 18, 2015, at 1:14 PM, Ondrej Zajicek <santiago@crfreenet.org>
>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: santiago@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."
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf

[OSPF] Request for clarification of OSPF loading … Ondrej Zajicek
Re: [OSPF] Request for clarification of OSPF load… Acee Lindem (acee)