Hi Mike, Since the current step 7 deals with the SAME instance of the LSA, I don't see how swapping steps 6 and 7 solves the problem. Perhaps, I'm missing some other edit?
Thanks, Acee -----Original Message----- From: RFC Errata System <[email protected]> Date: Thursday, April 24, 2014 10:28 AM To: "[email protected]" <[email protected]>, Alia Atlas <[email protected]>, Adrian Farrel <[email protected]>, Abhay Roy <[email protected]>, Ericsson <[email protected]> Cc: Mike Dubrovskiy <[email protected]>, OSPF - OSPF WG List <[email protected]>, "[email protected]" <[email protected]> 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 <[email protected]> > >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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
