Subject: OSPFv3 BadLSReq

From: Taisuke Sasaki <[email-masked]>
Date: Tue, 27 May 2003 11:24:49 +0900

I have a question about a OSPFv3 Database exchange process.

Suppose below:
1) R1 has only 1 Broadcast interface in Area 0.
   R2 has 2 interfaces in Area 0.
   (one is a broadcast and the other is a loopback)

2) Both the R1's interface and the R2's are assigned
   the same IPv6 prefix (Prefix A).

3) At first, the link between R1 and R2 is down.

4) Consider about R1.

   +---+  Prefix A   +---+
   |R1 +------X------+R2 |
   +---+             +---+

When the link is up, R1 originates a Intra-Area-Prefix-LSA
associated with a Router-LSA.
This Intra-Area-Prefix-LSA has a Prefix A.

In a database exchange process:
when R1 receives the last Database Description packet from R2,
neighbor event "ExchangeDone" happens and neighbor state
transits to "Loading" or "Full" in R1.

If the neighbor state transit to "Full",
R1 flushes an Intra-Area-Prefix-LSA associate with a Router-LSA
through premature aging process because it is thought that the
interface turns to be adjacent.

After the above event:
When R1 receives a LS-Request packet from R2,
it is possible that neighbor event "BadLSReq" happens in R1
because R2 told R1 in Database Description packets that
I had an Intra-Area-Prefix-LSA associated with a Router-LSA .
But now, R1 has already flushed it.

---
taisuke sasaki

---

From: Acee Lindem <[email-masked]>
Date: Tue, 27 May 2003 13:42:23 -0400

> 3) At first, the link between R1 and R2 is down.

Hello Taisuke Sasaki,

R2 should place the MaxAge LSA on neighbor R1's retransmission list
when it flushes it. The LSA should not be removed from R2's
link state database as long as there are routers in exchange or
loading state. Refer to RFC 2328 section 14.1.

Thanks,
Acee

--
Acee

---

From: Taisuke Sasaki <[email-masked]>
Date: Wed, 28 May 2003 11:41:26 +0900

Hello Acee.
Thank you for your reply.

I had an error in writing in my previous mail.

because R1 told R2 in Database Description packets that
        ^^^^^^^^^^

> loading state. Refer to RFC 2328 section 14.1.

In R1, the LSA(Intra-Area-Prefix-LSA associated with a Router-LSA)
was already flushed because R2's neighbor state is "FULL".
There in no router in exchange or loading state.

The point is below:
1) R1 told R2 that R1 had an Intra-Area-Prefix-LSA associated
   with a Router-LSA in Database Description packets.
   So, R2 will request the Intra-Area-Prefix-LSA.

nevertheless,

2) When R1 receives a LS-Request packet from R2,
   it is possible that R2's neighbor state is already full,
   and there is no router in exchange or loading state,
   and an Intra-Area-Prefix-LSA associated with a Router-LSA
   is already flushed in R1's link state database.
   So, BadLSReq event will happen.

---
taisuke sasaki

---

From: Acee Lindem <[email-masked]>
Date: Tue, 27 May 2003 23:21:51 -0400

Hello Taisuke Sasaki,

Maybe I am missing your scenario. See below.

> because R1 told R2 in Database Description packets that

Then how can there be a LS Request packet if neither router is in
exchange/loading state?

>    So, R2 will request the Intra-Area-Prefix-LSA.

The reference LSA in the intra-area prefix LSA should not be
examined in the database exchange process. Each LSA should
be considered synchronized individually.

>    and there is no router in exchange or loading state,

Nope - A router will only send a LS-Request packet in
exchange/loading state.

--
Acee

---

From: Taisuke Sasaki <[email-masked]>
Date: Wed, 28 May 2003 14:32:49 +0900

> Then how can there be a LS Request packet if neither router is in

Please see my last comments.

> be considered synchronized individually.

What I call "an Intra-Area-Prefix-LSA associated with a Router-LSA"
is not what you call "a reference LSA", but a Intra-Area-Prefix-LSA
to advertise its own prefixes and those of its attached stub links.
(namely, an Intra-Area-Prefix-LSA which Referenced LS type is 0x2001)

> Nope - A router will only send a LS-Request packet in

Indeed a router will only send a LS-Request packet in
exchange/loading state, but a router does not necessarily
receive a LS-Request packet in exchange/loading state.
^^^^^^^

My opinion is that
a router can receive a LS-Request packet from the full state neighbor.

example:

     +---+                +---+
     |R1 |----------------|R2 |
     +---+                +---+

When R2 send a LS-Request packet:

1) from R2's point of view,
   R1's neighbor state is indeed exchange or loading.

2) from R1's point of view,
   R2's neighbor state can be exchange or loading or full.

regards.

---
taisuke sasaki

---

From: Sina Mirtorabi <[email-masked]>
Date: Tue, 27 May 2003 23:46:49 -0700

Taisuke

-> The point is below:
-> 1) R1 told R2 that R1 had an Intra-Area-Prefix-LSA associated
->    with a Router-LSA in Database Description packets.
->    So, R2 will request the Intra-Area-Prefix-LSA.
->
-> nevertheless,
->
-> 2) When R1 receives a LS-Request packet from R2,
->    it is possible that R2's neighbor state is already full,

I guess you meant to say "R1's neighbor state is already Full"

->    and there is no router in exchange or loading state,
->    and an Intra-Area-Prefix-LSA associated with a Router-LSA
->    is already flushed in R1's link state database.
->    So, BadLSReq event will happen.

The point that you missed is that when R1 maxage its LSA it is expecting
to get an Ack and when R2 receive the Maxage LSA it will remove it from
its link state request list ( a part from sending an Ack )

--

From 2328

(b) Else, if the adjacency is not yet full (neighbor state
                is Exchange or Loading), examine the Link state request
                list associated with this adjacency.  If there is an
                instance of the new LSA on the list, it indicates that
                the neighboring router has an instance of the LSA
                already.  Compare the new LSA to the neighbor's copy:

                o   If the new LSA is less recent, then examine the next
                    neighbor.

                o   If the two copies are the same instance, then delete
                    the LSA from the Link state request list, and
                    examine the next neighbor.[20]

                o   Else, the new LSA is more recent.  Delete the LSA
                    from the Link state request list.
--

Sina

->
-> ---
-> taisuke sasaki
->

---

From: Taisuke Sasaki <[email-masked]>
Date: Wed, 28 May 2003 17:05:31 +0900

Acee and Sina,

Thank you for your detailed explanation.
I read a rfc2328 14.1 again and carefully.

> loading state. Refer to RFC 2328 section 14.1.

Now, I understand that OSPF prevent R1 from BadLSReq event
from the next 2 important points.  right?

R1) The premature aging process guarantees that
    MaxAge LSA is never flushed from its link state database
    as long as it is contained on any neighbor LS-Retransmission
    list.
    (this is what Acee pointed out)

R2) Receiving R1's MaxAge LSA makes R2 delete the same instance of
    the LSA from the LS-Request list associated with R1, if needed.
    (this is what Sina pointed out)

     +---+                +---+

---
taisuke sasaki

---

From: Acee Lindem <[email-masked]>
Date: Wed, 28 May 2003 09:53:43 -0400

> from the next 2 important points.  right?

Taisuke,

Almost correct.

>     (this is what Acee pointed out)

RFC 2328 states that a MaxAge LSA shouldn't be deleted from the
link state database as long as there are neighbors in Exchange
or Loading state.

>     (this is what Sina pointed out)

Yes.

--
Acee