[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
- [OSPF] [Technical Errata Reported] RFC2328 (3974) RFC Errata System
- Re: [OSPF] [Technical Errata Reported] RFC2328 (3… Acee Lindem
- Re: [OSPF] [Technical Errata Reported] RFC2328 (3… Mike Dubrovskiy (mdubrovs)
- Re: [OSPF] [Technical Errata Reported] RFC2328 (3… Acee Lindem
- Re: [OSPF] [Technical Errata Reported] RFC2328 (3… Acee Lindem
- [OSPF] [Errata Verified] RFC2328 (3974) RFC Errata System