[OSPF]Re: [Lsr] Operational Observation: RFC 3623 Grace LSA Ambiguity on Parallel Links

Acee Lindem <acee.ietf@gmail.com> Thu, 22 January 2026 11:11 UTC

Return-Path: <acee.ietf@gmail.com>
X-Original-To: ospf@mail2.ietf.org
Delivered-To: ospf@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 8886DAB6B0A2 for <ospf@mail2.ietf.org>; Thu, 22 Jan 2026 03:11:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level:
X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMZvhZjMr9Jh for <ospf@mail2.ietf.org>; Thu, 22 Jan 2026 03:11:11 -0800 (PST)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B6CB3AB69DF7 for <OSPF@ietf.org>; Thu, 22 Jan 2026 02:55:33 -0800 (PST)
Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-88a2e3bd3cdso9025916d6.0 for <OSPF@ietf.org>; Thu, 22 Jan 2026 02:55:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769079325; x=1769684125; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gF/OBVAXCeYgrAlcxzHa//fDu/OdJktlWd6/FIhzjeY=; b=bifWJSpzbDeAncN9pd3eG228RkbuLrlstn64GhrkCvi7zYijYZNuA1hw9oNat/TnGJ /l6MRnMobEQp+LmkBdC3cRs9+5nH1g4YzwUuTvXcMVTa0k5d8HS+wehFUohYl6sUhUX2 zpfkcknTini1LYy9tKdN48HtReaUdew8xdore/NBJavNWibiTzjAt9SftewXbuhCm4fG Feldl3/KUsUpsXSDeEmuXeGVElFxWbrh1VVYD04DL0wB7E1iupc978it4/s3q5eOC4/V 1fGs+MMmEpS8nxnmwLwZunkJGCkdYAcUUcS6d7UC3WYzapGUACCaPWvCUszW2FVQBDyI k+pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769079325; x=1769684125; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gF/OBVAXCeYgrAlcxzHa//fDu/OdJktlWd6/FIhzjeY=; b=PEM1390LCnY1mDW1NGi7yaizBYuWUk4Q3G6MUjc/aNG9zdQPLVH2/Nv/1CVxqhq2bZ NPmuM0oV+eFidZO6ikJUWNSFKPdDV+bpQNE0THL7QD7pe4IFWTfXBFNKidqlZpP4VOwG vqqiZ+mm9rTxW/n6ZZP0t4u/3nVu/WfKC+i9Dam2SrSH24VNyfMWF2l540/A1oayb5N1 19j9bPVMliPpUIjAmtLcQB+So3OpeYZS/2I8Q9l23slzAaFfTGBRqYcGsnAMVwL1XzkP pnsemz5cAuclLfhs6luO8iHvuOg8FGpq0a3ow/GedSo1UgY3gpZQydntou6vQeVhNS1R ahqQ==
X-Forwarded-Encrypted: i=1; AJvYcCWDJpMWA7odgI9XGGv+Zbyy2AyOqr3ued3nx0hcrxfmkOGazBgtIFOGlTbO+ZbZTy0VGnMT@ietf.org
X-Gm-Message-State: AOJu0YzLasi8ck6V2/oCj4EOHLchZ5peA4qPW0Mf6n8PkiYcUp8mhs5n IyKrMPgijH8Wv/ucXPsuZ7hzoRsclZOq2O1STjMnE4o41j/k/fJNo3S1
X-Gm-Gg: AZuq6aIKqzSAnpXoL9WgQyAyxoYpW7HLQNj/WMNanB7zK3WjyOBemxM3+Nm4BtioYtC n2n78NxZm4NzZNfBoYjac1uKLinHiYPVcgNZyjA8M5UyL2+oqe+PU2UIDZJ8rpCtdznKvGIt84e tN9xMtdU4ANQoPoA69icwoqCdFUrSdHv9mIK6/kVA3pJ+O3p5VZy+ApkKqaWJpnyvQiSzNswerg 9BzgriIUOfFCly23bR0+Wy/UsHGq69pn4Mee5/K6Tda55Oh8z/VNnuTyv8OEOqTYIch6nRlKenb 5G6PKn20McUtMQ4S3brLPUjS0RHeaeRXCXq0qLR6KKMJk0IxV6RIqsyWHIIre7Rj6cZTQvNTzBn 0zOBaHoJ8VEId1MzHZmMvd45kbZ9t/zHcYaDef8vGpupAbEjFo2fj1czWBrtrkiTs/qgrL7suJk GWP5f110xN9Pj1TiukKC/bZDZ4dYDWJZmQ1OdRzKVrPHI=
X-Received: by 2002:a0c:c344:0:b0:894:7ddf:d4af with SMTP id 6a1803df08f44-8947df54908mr23126576d6.6.1769079325517; Thu, 22 Jan 2026 02:55:25 -0800 (PST)
Received: from smtpclient.apple ([2605:a601:a6e6:6300:88ab:b36a:3613:ed35]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8942e603a8bsm142952246d6.17.2026.01.22.02.55.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jan 2026 02:55:25 -0800 (PST)
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>
X-Mailer: Apple Mail (2.3864.300.41.1.7)
Message-ID-Hash: DYJVOEEBBPZUMYDGAJTRMMG3OKJVT5PM
X-Message-ID-Hash: DYJVOEEBBPZUMYDGAJTRMMG3OKJVT5PM
X-MailFrom: acee.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ospf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OSPF]Re: [Lsr] Operational Observation: RFC 3623 Grace LSA Ambiguity on Parallel Links
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/FrnIkbQXrxj5O1XAwpOen2IHjvk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Owner: <mailto:ospf-owner@ietf.org>
List-Post: <mailto:ospf@ietf.org>
List-Subscribe: <mailto:ospf-join@ietf.org>
List-Unsubscribe: <mailto:ospf-leave@ietf.org>

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 <chandran.raams@gmail.com> 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 -- lsr@ietf.org
> To unsubscribe send an email to lsr-leave@ietf.org