[OSPF] [Errata Verified] RFC2328 (3974)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 12 May 2014 15:58 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 E6C021A0729; Mon, 12 May 2014 08:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Level:
X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 rrpmJefR3by2; Mon, 12 May 2014 08:58:53 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id A6CFD1A0352; Mon, 12 May 2014 08:58:53 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 6679518000D; Mon, 12 May 2014 08:57:57 -0700 (PDT)
To: mdubrovs@cisco.com, jmoy@casc.com
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20140512155757.6679518000D@rfc-editor.org>
Date: Mon, 12 May 2014 08:57:57 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/_hzzGj_lipye6tMjFw0nc_AJYG8
Cc: ospf@ietf.org, akatlas@juniper.net, iesg@ietf.org, rfc-editor@rfc-editor.org
Subject: [OSPF] [Errata Verified] RFC2328 (3974)
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: Mon, 12 May 2014 15:58:56 -0000

The following errata report has been verified for RFC2328,
"OSPF Version 2". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3974

--------------------------------------
Status: Verified
Type: Technical

Reported by: Mike Dubrovsky <mdubrovs@cisco.com>
Date Reported: 2014-04-24
Verified by: Alia Atlas (IESG)

Section: 13

Original Text
-------------
    (6) Else, if there is an instance of the LSA on the sending
        neighbor's Link state request list, an error has occurred in the
        Database Exchange process.  In this case, restart the Database
        Exchange process by generating the neighbor event BadLSReq for
        the sending neighbor and stop processing the Link State Update
        packet.

    (7) Else, if the received LSA is the same instance as the database
        copy (i.e., neither one is more recent) the following two steps
        should be performed:

        (a) If the LSA is listed in the Link state retransmission list
            for the receiving adjacency, the router itself is expecting
            an acknowledgment for this LSA.  The router should treat the
            received LSA as an acknowledgment by removing the LSA from
            the Link state retransmission list.  This is termed an
            "implied acknowledgment".  Its occurrence should be noted
            for later use by the acknowledgment process (Section 13.5).

        (b) Possibly acknowledge the receipt of the LSA by sending a
            Link State Acknowledgment packet back out the receiving
            interface.  This is explained below in Section 13.5.


Corrected Text
--------------
    (6) Else, if the received LSA is the same instance as the database
        copy (i.e., neither one is more recent) the following two steps
        should be performed:

        (a) If the LSA is listed in the Link state retransmission list
            for the receiving adjacency, the router itself is expecting
            an acknowledgment for this LSA.  The router should treat the
            received LSA as an acknowledgment by removing the LSA from
            the Link state retransmission list.  This is termed an
            "implied acknowledgment".  Its occurrence should be noted
            for later use by the acknowledgment process (Section 13.5).

        (b) Possibly acknowledge the receipt of the LSA by sending a
            Link State Acknowledgment packet back out the receiving
            interface.  This is explained below in Section 13.5.

    (7) Else, if there is an instance of the LSA on the sending
        neighbor's Link state request list, an error has occurred in the
        Database Exchange process.  In this case, restart the Database
        Exchange process by generating the neighbor event BadLSReq for
        the sending neighbor and stop processing the Link State Update
        packet.


Notes
-----
The problem arises when the routing domain has two instances of LSA 
with the same sequence number and the same checksum,
but with an age difference bigger than MaxAgeDiff.

The above could take place in multiple scenarios. Here are two examples:

1) There is a demand circuit somewhere in the routing domain
2) The router lost its ASBR status and therefore flushed the self-originated Type 5 LSAs
   but later on gained the ASBR status back and re-originated Type 5.    
   If the network was partitioned, each partition can have two instances of LSA
   with an age difference bigger than MaxAgeDiff.
   
The two instances of LSA can temporarily prevent the adjacency formation. 
   
Consider the example below:


Topology
========


RT1 ----- RT2

Initial state:
==============
The physical link between RT1 and R2 just came up 
The routers are about to form ospf adjacency.

Initial link-state databases:
=============================
R1 ospf database has          LSA 10.0.0.1 age 910 seq # 0x80000001 
R2 ospf database has the same LSA 10.0.0.1 age   9 seq # 0x80000001

RT1 Event Sequence:
===============

RT1 is starting to form adjacency with RT2. 

1) During the Database Exchange, RT2's LSA instance is more recent because of more than 900 (MaxAgeDiff) seconds age difference (section 13.1 of RFC 2328).
2) So RT1 requests the LSA
3) RT2 sends the LSA after incrementing the age by 1 (InfTransDelay).
4) When the LSA instance arrives to RT1, it is identical (the difference is exactly 900 seconds now).

So RT1 aborts Loading according to step (6) of section 13.


Solution:
=========

Swap steps (6) and (7) of section 13.

Acee Lindem adds:
"This situation comes into play when a router views an LSA as being
more recent when the LSA is requested (via Link-State Request) but as the
same instance when the LSA is actually received."

--------------------------------------
RFC2328 (no draft string recorded)
--------------------------------------
Title               : OSPF Version 2
Publication Date    : April 1998
Author(s)           : J. Moy
Category            : INTERNET STANDARD
Source              : Open Shortest Path First IGP
Area                : Routing
Stream              : IETF
Verifying Party     : IESG