Hi Gabi,
From: OSPF <[email protected]<mailto:[email protected]>> on behalf of
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Reply-To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Date: Thursday, September 8, 2016 at 9:50 AM
To: OSPF WG List <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: [OSPF] Rollover of an LSA sequence number
Hi,
I would like to draw the attention of the list to a possible inaccuracy in RFC
2328 regrading the rollover of an LSA's sequence number. Recently, my
colleagues -- Orna Grumberg and Adi Sosnovich (CC'd) -- and I have noticed a
bug in an older version of Cisco's OSPF implementation.
This was more than 10 years ago during my first tenure at Cisco…
The bug is that following a flush of an LSA having MaxSequenceNumber the router
do not originate a new LSA with the initial sequence number. Cisco already
fixed the bug a while back, however Cisco's security engineer we talked to
suggested that this bug was due to an improper definition in the OSPF
specification. Indeed, in Sec. 12.1.6 the RFC says that it is optional to send
the new LSA instance:
When an attempt is made to increment
the sequence number past the maximum value of N - 1
(0x7fffffff; also referred to as MaxSequenceNumber), the
current instance of the LSA must first be flushed from the
routing domain. This is done by prematurely aging the LSA
(see Section 14.1) and reflooding it. As soon as this flood
has been acknowledged by all adjacent neighbors, a new
instance _can_ be originated with sequence number of
InitialSequenceNumber.
The RFC uses the term "can" and not "must".
This is a possible inaccuracy of the RFC that may mislead other
implementations. I would be happy to get the feedback of the list on whether
this issue warrants a fix.
I would not agree. The intent here is clear that the OSPF router has already
found it necessarily to originate a new version of the LSA and the purging of
the LSA with MaxSequenceNumber must preceded originating the new version. In
fact, a new LSA would not be originated if for some reason reachability changed
while purging the MaxSequenceNumber LSA and a new LSA is no longer warranted.
There is no problem with the specification.
Furthermore, IIRC correctly the bug was in no way related to the “can” vs
“must”. If you unicast the number to me, I can verify that.
Thanks,
Acee
Best regards,
Gabi
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
