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

["Mike Dubrovskiy (mdubrovs)" <[e-mail]>]

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:[e-mail]]
> Sent: Tuesday, May 06, 2014 11:17 AM
> To: RFC Errata System; [e-mail]; [e-mail];
> [e-mail]; Abhay Roy (akr)
> Cc: Mike Dubrovskiy (mdubrovs); [e-mail]
> 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 <[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