OSFP LSA_MAXSEQNO problems

[Alexander V. Chernikov]

On 14.08.2013 14:18, Ondrej Zajicek wrote:
> On Wed, Aug 14, 2013 at 03:35:07AM +0400, Alexander V. Chernikov wrote:
>> Hello list!
>>
>> Currently bird performs LSA premature aging in very strange way which
>> sometimes upsets quagga (up to SIGSEGV) and Cisco.
>> Every time aging is done via setting seq number to LSA_MAXSEQNO.
>>
>> RFC 2328, on the opposite, shows us only 2 cases where MaxSequenceNumber
>> is used in outgoing LSAs:
>> 1) Self LSA originating with given seq num (very rare event)
>> 2) [Premature] Aging of LSA from 1) because a) disappeared net and b)
>> seq number increase (12.1.6)
>>
>> For all other cases seq number should be either increased or left intact.
>>
>>
>> Bird, however, insist on setting LSA_MAXSEQNO while:
>> 1) Receiving self-originating LSA which is not in local LSDB (
>> ospf_lsupd_receive ) which is not a special case according to 14.1
>> 2) In all other places like handling if-down, external route disappear,
>> etc... ( ospf_lsupd_flush_nlsa )
> You are right that BIRD uses LSA_MAXSEQNO in more cases than prescribed
> by RFC 2328 (essentially in most cases when a local LSA is flushed), but
> these changes were introduced mostly as a reaction to problems with the
> usual flushing (just premature aging), where BIRD sends LSA with MaxAge,
> then forgets the LSA and when reintroduced the LSA later, it starts with
> InitSeqNum. In cases like external route flaps (and similar events for
> other kinds of LSAs) that caused that newer LSA meets MaxAge LSA during
> flood, is considered as older and removed (and combined with other
Yes, but shouldn't "new" MaxAge than be sent back to neighbor
and than back to other neighbors reaching originating router?
(And after that it should generate seq+1 LSA and push it back finishing 
this process) so it sounds a bit more deterministic.

> minor inconsistencies in router behaviors this would lead to all kinds
> of strange events).
>
> The idea behind the behavior is that you should either keep the old
> seqnum for your LSA when it is flushed (and continue in it when you
> reintroduce it), or you should use LSA_MAXSEQNO to ensure that old seqnum
> is eliminated from the OSPF domain so you could forget seqnum and later
> start from InitSeqNum. The behavior is not according to RFC 2328, but it
> is compatible with it. And i have a work-in-progress code that fixes several
> issues in the flooding code together with this.
That sounds great. Do you plan to implement keeping sequence numbers for 
all seen routes?
>