A Scoping Mechanism for Fast Notification Using IGP Areas

The FaNTEL mechanism aims to deliver network event notifications with minimal latency, such as congestion, failure, or load shift. Unlike periodic telemetry, FaNTEL operates as an event-driven push system. However, unrestricted reachability undermines scalability and stability. This document defines a scoped propagation model where FaNTEL message dissemination is bound by IGP area topology. We introduce the formal notion of a FaNTEL Area, aligned with IGP routing domains, and specify the exact message format and forwarding semantics that enforce scope. The goal of this document is not to define FaNTEL signaling end-to-end, but to standardize how far a notification should travel.

IGP: Interior Gateway Protocol FaNTEL: Fast Notification for Traffic Engineering and Load Balancing WAN: Wide Area Network

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

A FaNTEL Area is a set of routers sharing the same IGP area context and participating in a common FaNTEL flooding domain. A router belongs to a FaNTEL Area if: It runs an IGP (OSPF or IS-IS) and is assigned to a specific area. It is configured to participate in FaNTEL. It has established adjacency with at least one other FaNTEL-capable router in the same IGP area. The FaNTEL Area Identifier (FA-ID) is a 32-bit value derived from the underlying IGP's area identification mechanism. The derivation method is protocol-specific and MUST be consistent across all routers within a single deployment.

In OSPF, the topology is partitioned into logical areas identified by a 32-bit Area ID, as defined in [RFC2328] and [RFC5340]. This Area ID is carried in all OSPF packets (Hello, Database Description, LSA headers) and is used to determine adjacency formation and routing information scope. The FA-ID SHALL be set directly to the OSPF Area ID of the interface or router generating the FaNTEL message. The Area ID may be represented in dotted-decimal notation but is interpreted and transmitted as a 32-bit integer in network byte order.

In IS-IS, level-1 routing domains are defined by matching Area Addresses (also known as Area IDs or NSAP prefixes), as specified in [RFC1195]. Unlike OSPF, IS-IS allows multiple Area Addresses per system, and the identifier is variable-length. To derive a consistent 32-bit FA-ID across all routers in the same level-1 domain: The FA-ID SHALL be derived from the set of locally configured IS-IS Area Addresses using a deterministic hashing function. All routers within the same level-1 area MUST use the same hashing algorithm to ensure identical FA-ID computation. If no Area Address is configured for Level-1 routing, the FA-ID MUST be set to 0x00000000.

Before evaluating the scope of a received FaNTEL message, the router MUST authenticate it using a pre-shared key and a cryptographic hash function such as HMAC-SHA256; if authentication fails, the message MUST be dropped immediately without further processing.

The router derives its local_FA-ID from the underlying IGP configuration: for OSPF, the 32-bit Area ID is used directly; for IS-IS, a deterministic 32-bit hash is computed over the set of locally configured Area Addresses, ensuring consistent derivation across all routers in the same domain.

The router compares the message’s Originating FA-ID with its own local_FA-ID(s); if they match, the message is considered locally relevant and proceeds to intra-area processing, otherwise it is discarded unless the router is a border node and administrative policy allows inter-area relay.

Upon successful FA-ID match, the router processes the event (e.g., updates forwarding state), suppresses duplicates using the Originating Router ID and Sequence Number, and reliably floods the message to all FaNTEL-capable neighbors within the same area using a multicast or reliable unicast transport.

A border node that receives a FaNTEL message with a non-matching FA-ID may, based on configured policy, generate a new message in an adjacent area by setting the Originating FA-ID to the target area’s identifier, decrementing the TTL, and optionally summarizing the event before flooding, but MUST NOT forward the original message across areas.

TBD