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

From: Acee Lindem <[email-masked]>
Date: Tue, 6 May 2014 18:16:32 +0000

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

---

From: "Mike Dubrovskiy (mdubrovs)" <[email-masked]>
Date: Tue, 6 May 2014 19:47:08 +0000

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.

> From: Acee Lindem [mailto:[email-masked]]
> Sent: Tuesday, May 06, 2014 11:17 AM
> To: RFC Errata System; [email-masked]; [email-masked];
> [email-masked]; Abhay Roy (akr)
> Cc: Mike Dubrovskiy (mdubrovs); [email-masked]
> 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
> 
> >The following errata report has been submitted for RFC2328, "OSPF
> >Version 2".
> >
> >with the same sequence number and the same checksum, but with an age
> >difference bigger than MaxAgeDiff.
> >
> >   If the network was partitioned, each partition can have two
> >instances of LSA
> >The physical link between RT1 and R2 just came up The routers are about
> >to form ospf adjacency.
> >
> >4) When the LSA instance arrives to RT1, it is identical (the
> >difference is exactly 900 seconds now).
> >
> >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.
> >

---

From: Acee Lindem <[email-masked]>
Date: Wed, 7 May 2014 15:04:32 +0000

Hi Mike, 

Acee

---

From: Acee Lindem <[email-masked]>
Date: Mon, 12 May 2014 15:53:47 +0000

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