Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\))
From: Acee Lindem <acee.ietf@gmail.com>
In-Reply-To: 
 <CACwenemt8tu5oMDXg5-Tt6SLzu0OrHYuoeM46N=yLT7FVjAphA@mail.gmail.com>
Date: Thu, 22 Jan 2026 05:55:14 -0500
Cc: lsr <lsr@ietf.org>,
 OSPF List <OSPF@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <26D47A3F-610F-4423-8192-5EF73C7D5756@gmail.com>
References: 
 <CACwenemt8tu5oMDXg5-Tt6SLzu0OrHYuoeM46N=yLT7FVjAphA@mail.gmail.com>
To: Ramachandran Sathianandan <chandran.raams@gmail.com>
Message-ID-Hash: DYJVOEEBBPZUMYDGAJTRMMG3OKJVT5PM
Precedence: list
Subject: =?utf-8?q?=5BOSPF=5DRe=3A_=5BLsr=5D_Operational_Observation=3A_RFC_3623_Grac?=
 =?utf-8?q?e_LSA_Ambiguity_on_Parallel_Links?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ospf/FrnIkbQXrxj5O1XAwpOen2IHjvk>

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).=20

Thanks,
Acee

> On Jan 21, 2026, at 11:44=E2=80=AFPM, Ramachandran Sathianandan =
<chandran.raams@gmail.com> wrote:
>=20
> 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.
>=20
> 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.
>=20
> In a topology where the Restarter and Helper are connected via =
multiple back-to-back links in the same area:
>=20
> - 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=E2=80=99s 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.
>=20
> Consequently, the Helper fails to process the explicit restart =
completion signal and retains the Helper state until the Grace Timer =
expires.
>=20
> Reference to Specification
>=20
> - 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.
>=20
> Proposed Enhancement / Clarification
> To resolve collisions on parallel links and allow for deterministic =
signaling, I propose that future implementations or updates recommend:
>=20
> "When originating Grace-LSAs on multiple interfaces, the Restarter =
SHOULD ensure the Opaque ID is unique for each link=E2=80=94for example, =
by encoding the local Interface Index (ifIndex) into the 24-bit Opaque =
ID field."
>=20
> This enhancement would allow the Helper to uniquely identify and flush =
specific grace sessions, preventing unnecessary timer-based exits.
>=20
> Regards,
> Ramachandran Sathianandan
>=20
>=20
>=20
>=20
> _______________________________________________
> Lsr mailing list -- lsr@ietf.org
> To unsubscribe send an email to lsr-leave@ietf.org