Re: [OSPF] [Technical Errata Reported] RFC2328 (3974)
Acee Lindem <acee.lindem@ericsson.com> Mon, 12 May 2014 15:53 UTC
Return-Path: <acee.lindem@ericsson.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 E17321A0728 for <ospf@ietfa.amsl.com>; Mon, 12 May 2014 08:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 5yzJ1npr2Y3d for <ospf@ietfa.amsl.com>; Mon, 12 May 2014 08:53:54 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id AA4D61A0352 for <ospf@ietf.org>; Mon, 12 May 2014 08:53:54 -0700 (PDT)
X-AuditID: c6180641-f799b6d000000b0f-40-53709cd7055b
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BC.F2.02831.7DC90735; Mon, 12 May 2014 12:05:11 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Mon, 12 May 2014 11:53:47 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, "akatlas@gmail.com" <akatlas@gmail.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "akr@cisco.com" <akr@cisco.com>
Thread-Topic: [Technical Errata Reported] RFC2328 (3974)
Thread-Index: AQHPbfpcsEUMQ+NpHkOCbQLGrg4woQ==
Date: Mon, 12 May 2014 15:53:47 +0000
Message-ID: <CF963B09.2DC87%acee.lindem@ericsson.com>
References: <20140424172827.6ABD01801A2@rfc-editor.org>
In-Reply-To: <20140424172827.6ABD01801A2@rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A07D23906FC5FF4ABE22CFBDBA2D68D6@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyuXRPgu71OQXBBrO2mVv86LnBbPHp4SVm i8MHZ7FZPPy1hs2i5d49doum/V/ZHNg8pvzeyOqxc9Zddo8lS34yeazYvJLRo6HtGGsAaxSX TUpqTmZZapG+XQJXxquDsxkLzhhVbFx2mK2B8Z5aFyMnh4SAicSyL6+ZIGwxiQv31rN1MXJx CAkcZZSYNGUnM4SznFFi0+F57CBVbAI6Es8f/QNLiAisYZR4++IBM0iCWcBPYt7GC2wgtrCA ucSuvwvAxooIWEisuL+SEcLWk1jeuoW1i5GDg0VAVeJ/RyRImFfAVOJX6zywciGg1jOvZoLt 4gRq3TShA8xmBLru+6k1TBCrxCVuPZkPdbWAxJI955khbFGJl4//sYLYokCr3h2HqVGS+Ph7 PjtEr47Egt2f2CBsa4mTh75B2doSyxa+Zoa4R1Di5MwnLBMYJWYhWTcLSfssJO2zkLTPQtK+ gJF1FSNHaXFqWW66keEmRmDUHpNgc9zBuOCT5SFGAQ5GJR7eBbMLgoVYE8uKK3MPMUpzsCiJ 86Z/ig0WEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwDj54/2t5Wca7wVL8T2tLpRlNyuLkA59 0RJUp5gjvk/JVozxxUzrthuy/unaCSxHjhbfeCS9nU3rvOyl0x0vu5ZME3Zv+e2yoiLp58sS rleG59/PmXqfnzPMoZxL/INozM7ieQGGb/69eFhmttO3UlGBt2edEEdHRlVgsFiSJwOX7cPb nAJWSizFGYmGWsxFxYkA5PR6yLsCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/co--UO2tElQzJdxd2udp5iyjCts
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [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: Mon, 12 May 2014 15:53:57 -0000
Hi Alia, We have discussed this technical errata offline and I agree with it. I think the following text should be added: 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. Thanks, Acee -----Original Message----- From: RFC Errata System <rfc-editor@rfc-editor.org> Date: Thursday, April 24, 2014 10:28 AM To: "jmoy@casc.com" <jmoy@casc.com>, Alia Atlas <akatlas@gmail.com>, Adrian Farrel <adrian@olddog.co.uk>, Abhay Roy <akr@cisco.com>, Ericsson <acee.lindem@ericsson.com> Cc: Mike Dubrovskiy <mdubrovs@cisco.com>, OSPF - OSPF WG List <ospf@ietf.org>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org> Subject: [Technical Errata Reported] RFC2328 (3974) >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