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

[Acee Lindem <[e-mail]>]

Hi Mike, 
The intent of your change was evident from the errata ;^)  My question is how it solves the problem when the two instance are not the same instance since they differ by more than MaxAgeDiff as described in the errata (see excerpted text below): 

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


Acee 

On May 6, 2014, at 3:47 PM, Mike Dubrovskiy (mdubrovs) <[e-mail]> wrote:

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