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

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

Return-Path: <acee@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC611B2B4A for <ospf@ietfa.amsl.com>; Thu, 18 Jun 2015 11:57:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dWIMmlCEX8A for <ospf@ietfa.amsl.com>; Thu, 18 Jun 2015 11:57:04 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B5E1B2C7F for <ospf@ietf.org>; Thu, 18 Jun 2015 11:57:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: A0BeBQCjE4NV/4YNJK1cgxBUXwaDGLpjgVsKhXgegSA6EgEBAQEBAQGBCoQjAQEEAQEBIBE6HQEIGgImAgQlCxUSBBOILw2gGY9flkYBAQEBBgEBAQEBGQSBIYokhCMRAR6DIoFDBZEEgmwBi0qBNYgDhEKCLIgAJmODFm+BDDqBAgEBAQ
X-IronPort-AV: E=Sophos;i="5.13,640,1427760000"; d="scan'208";a="2788817"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jun 2015 18:57:03 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5IIv3xc021743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <ospf@ietf.org>; Thu, 18 Jun 2015 18:57:03 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.208]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 18 Jun 2015 13:57:03 -0500
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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.116.152.197]
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
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 18:57:06 -0000

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