[OSPF] [Technical Errata Reported] RFC2328 (3974)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 24 April 2014 17:29 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 6856F1A026A for <ospf@ietfa.amsl.com>; Thu, 24 Apr 2014 10:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.174
X-Spam-Level:
X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 onyCGtmU58WN for <ospf@ietfa.amsl.com>; Thu, 24 Apr 2014 10:29:24 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 34A721A01DB for <ospf@ietf.org>; Thu, 24 Apr 2014 10:29:24 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 6ABD01801A2; Thu, 24 Apr 2014 10:28:27 -0700 (PDT)
To: jmoy@casc.com, akatlas@gmail.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com
X-PHP-Originating-Script: 6000:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20140424172827.6ABD01801A2@rfc-editor.org>
Date: Thu, 24 Apr 2014 10:28:27 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/BJ9ksaJQEycC80SL3AyL3eOkc44
Cc: ospf@ietf.org, rfc-editor@rfc-editor.org
Subject: [OSPF] [Technical Errata Reported] 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: Thu, 24 Apr 2014 17:29:26 -0000

The following errata report has been submitted 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

--------------------------------------
Type: Technical
Reported by: Mike Dubrovsky <mdubrovs@cisco.com>

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.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
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