[OSPF] Request for clarification of OSPF loading phase

Ondrej Zajicek <santiago@crfreenet.org> Thu, 18 June 2015 17:14 UTC

Return-Path: <santiago@crfreenet.org>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 072561B2A3C for <ospf@ietfa.amsl.com>; Thu, 18 Jun 2015 10:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GyCxbPkujC_t for <ospf@ietfa.amsl.com>; Thu, 18 Jun 2015 10:14:32 -0700 (PDT)
Received: from mail.crfreenet.org (mail6.crfreenet.org [IPv6:2002:515c:9101:20::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5200D1B2A34 for <ospf@ietf.org>; Thu, 18 Jun 2015 10:14:32 -0700 (PDT)
Received: from feanor (unknown []) by mail.crfreenet.org (Postfix) with ESMTP id 7FC7FFCCD; Thu, 18 Jun 2015 19:14:28 +0200 (CEST)
Date: Thu, 18 Jun 2015 19:14:28 +0200
From: Ondrej Zajicek <santiago@crfreenet.org>
To: ospf@ietf.org, "Acee Lindem (acee)" <acee@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q"
Content-Disposition: inline
X-Operating-System: Debian GNU/Linux
User-Agent: Mutt/1.5.23 (2014-03-12)
Message-Id: <20150618171428.7FC7FFCCD@mail.crfreenet.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/3MJLcVWm2u7MxdD2tv_i3pHbeSM>
Cc: Donald Sharp <sharpd@cumulusnetworks.com>, Andrew <nitr0@seti.kr.ua>, Paul Jakma <paul@jakma.org>
Subject: [OSPF] Request for clarification of OSPF loading phase
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2015 17:14:35 -0000


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: 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."