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 <[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
