| Internet-Draft | draft-hu-fantel-area-00 | October 2025 |
| Hu | Expires 21 April 2026 | [Page] |
Fast Notification for Traffic Engineering and Load Balancing (FaNTEL) enables real-time dissemination of network events such as link failure, congestion, or load imbalance. However, unbounded flooding of FaNTEL messages can lead to control plane overload and state explosion.¶
This document defines a scoping mechanism for FaNTEL based on IGP area boundaries. It formally specifies the concept of a FaNTEL Area, the structure of scoped notification messages, and the precise forwarding behavior within and across areas. The mechanism leverages existing IGP topological partitions (e.g., OSPF areas, IS-IS levels) to contain message propagation, ensuring rapid local response while preventing unnecessary global churn. This document focuses exclusively on the propagation model and provides normative rules for implementation.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 April 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC2119] [RFC8174] 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¶