Hi Acee, Thank you for looking into it. Please find my explanation below:
Before the errata: Step 5 - received LSA is more recent Step 6 - received LSA is on Link state request list Step 7 - received LSA is the same instance Step 8 - received LSA is older With the errata: Step 5 - received LSA is more recent Step 6- received LSA is the same instance Step 7 - received LSA is on Link state request list Step 8 - received LSA is older Mike P.S. The issue is quite easily reproducible if implementation allows setting the value of the InfTransDelay. > -----Original Message----- > From: Acee Lindem [mailto:[email protected]] > Sent: Tuesday, May 06, 2014 11:17 AM > To: RFC Errata System; [email protected]; [email protected]; > [email protected]; Abhay Roy (akr) > Cc: Mike Dubrovskiy (mdubrovs); [email protected] > Subject: Re: [Technical Errata Reported] RFC2328 (3974) > > 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
