Dear Acee, Thanks for the quick response.
My concern stems from implementations that *do* keep link-scoped LSAs in the area LSDB, as you mentioned. If the Helper aggregates all link-local Type-9 LSAs into the area LSDB without per-interface tracking, the collision on Opaque ID becomes an issue for deterministic flushing. Is there an existing RFC clarification that mandates how Helpers must treat identical Opaque IDs originating from the same Restarter when they are known to be on parallel links? Regards, Ramachandran Sathianandan On Thu, Jan 22, 2026 at 4:25 PM Acee Lindem <[email protected]> wrote: > Since the OSPF Grace Opaque LSA is scoped to an interface, what you are > suggesting really > isn't necessary. Conceptually, there is a separate LSDB per interface. > Some implementations > have avoided this and keep link-scoped LSAs in the the area LSDB. If you > do this, you need > to handle the case of multiple link-scoped LSA with the same opaque type > and ID (or not be > compatible with RFC 5250). > > Thanks, > Acee > > > On Jan 21, 2026, at 11:44 PM, Ramachandran Sathianandan < > [email protected]> wrote: > > > > Abstract > > This observation highlights an architectural limitation in RFC 3623 > (Graceful OSPF Restart) regarding the construction of Grace-LSAs (Type-9) > when multiple adjacencies exist between the same Restarter and Helper pair > (parallel links). The current specification does not mandate unique Opaque > IDs per link, leading to ambiguous Flush (MaxAge) handling on the Helper. > This often forces a fallback to "Grace Timer Expiry" rather than a > successful "Graceful Restart" termination. > > > > Description of Limitation > > RFC 3623, Section 2.1 ("Entering Graceful Restart"), specifies that the > Restarter must originate Link-Local Opaque-LSAs (Grace-LSAs). However, the > RFC does not enforce a mechanism to ensure the uniqueness of the Link-State > ID when multiple Grace-LSAs are generated for the same neighbor on > different interfaces. > > > > In a topology where the Restarter and Helper are connected via multiple > back-to-back links in the same area: > > > > - The Restarter generates a Grace-LSA for each link. > > - If the implementation defaults the Opaque ID (24 bits) to a static > value for all instances, the Helper receives multiple Type-9 LSAs with > identical Link-State IDs and Advertising Router IDs. > > - Although Type-9 LSAs are link-local, the Helper’s state machine faces > ambiguity during the termination phase. > > - When the Restarter completes the restart and flushes the Grace-LSAs, > the Helper cannot deterministically map a specific MaxAge LSA event to the > corresponding underlying link session if IDs collide. > > > > Consequently, the Helper fails to process the explicit restart > completion signal and retains the Helper state until the Grace Timer > expires. > > > > Reference to Specification > > > > - RFC 3623, Section 2.1: Does not specify encoding the ifIndex or a > unique identifier into the Opaque ID. > > - RFC 5250, Section 3.1: Defines the Opaque ID as an arbitrary value to > differentiate LSAs of the same type. > > > > Proposed Enhancement / Clarification > > To resolve collisions on parallel links and allow for deterministic > signaling, I propose that future implementations or updates recommend: > > > > "When originating Grace-LSAs on multiple interfaces, the Restarter > SHOULD ensure the Opaque ID is unique for each link—for example, by > encoding the local Interface Index (ifIndex) into the 24-bit Opaque ID > field." > > > > This enhancement would allow the Helper to uniquely identify and flush > specific grace sessions, preventing unnecessary timer-based exits. > > > > Regards, > > Ramachandran Sathianandan > > > > > > > > > > _______________________________________________ > > Lsr mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
