Re: OSPFv3 BadLSReq

[Acee Lindem <[e-mail]>]

Hello Taisuke Sasaki,

Maybe I am missing your scenario. See below.

Taisuke Sasaki wrote:
> Hello Acee.
> Thank you for your reply.
>
> I had an error in writing in my previous mail.
>
>
>>Taisuke Sasaki wrote:
>>
>>>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.
>>>
>>
>
> When R1 receives a LS-Request packet from R2,
> it is possible that neighbor event "BadLSReq" happens in R1
> because R1 told R2 in Database Description packets that
>         ^^^^^^^^^^
> I had an Intra-Area-Prefix-LSA associated with a Router-LSA .
> But now, R1 has already flushed it.
>
>
>
>>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.
>
>
> 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.

Then how can there be a LS Request packet if neither router is in
exchange/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.

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.

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

Nope - A router will only send a LS-Request packet in
exchange/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
>


--
Acee