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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4FC611B2B4A for <>; Thu, 18 Jun 2015 11:57:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8dWIMmlCEX8A for <>; Thu, 18 Jun 2015 11:57:04 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70B5E1B2C7F for <>; Thu, 18 Jun 2015 11:57:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3404; q=dns/txt; s=iport; t=1434653824; x=1435863424; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=T9by9z+B3xL8dRAk8zvo1c7WKkmfvoq2CDXSha7xNpg=; b=ThymjfRqlGESBTpSp/V9i6eDvY3ANcCcFzKW9YPLuWQSfL8leU1iW++N 6YJhj+pMq7HAvWFt7hijgmTP5qhdl/i5PsfOf2v4qbw6gMywpcUK5N/+P xlmjXGbiescUagdZ1txHzCtHv6TK3Sirls09W00CrHvSZ1NzuQfexfMIR c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,640,1427760000"; d="scan'208";a="2788817"
Received: from ([]) by with ESMTP; 18 Jun 2015 18:57:03 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t5IIv3xc021743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Thu, 18 Jun 2015 18:57:03 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 18 Jun 2015 13:57:03 -0500
From: "Acee Lindem (acee)" <>
To: OSPF WG List <>
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: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OSPF] Request for clarification of OSPF loading phase
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Jun 2015 18:57:06 -0000

Hi Ondrej, 

>On Jun 18, 2015, at 1:14 PM, Ondrej Zajicek <>
>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

Hope this helps,

>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:
>OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3,
>"To err is human -- to blame it on a computer is even more so."
>OSPF mailing list