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

[Acee Lindem <[e-mail]>]

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 <[e-mail]>
Date: Thursday, April 24, 2014 10:28 AM
To: "[e-mail]" <[e-mail]>, Alia Atlas <[e-mail]>,
Adrian Farrel <[e-mail]>, Abhay Roy <[e-mail]>, Ericsson
<[e-mail]>
Cc: Mike Dubrovskiy <[e-mail]>, OSPF - OSPF WG List
<[e-mail]>, "[e-mail]" <[e-mail]>
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 <[e-mail]>
>
>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