RTGWG Z. Hu Internet-Draft China Telecom Intended status: Standards Track 18 October 2025 Expires: 21 April 2026 A Scoping Mechanism for Fast Notification Using IGP Areas draft-hu-fantel-area-00 Abstract 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. Status of This Memo 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 Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Hu Expires 21 April 2026 [Page 1] Internet-Draft draft-hu-fantel-area-00 October 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. FaNTEL Area Definition . . . . . . . . . . . . . . . . . . . 3 3.1. For OSPFv2 and OSPFv3 . . . . . . . . . . . . . . . . . . 3 3.2. For IS-IS . . . . . . . . . . . . . . . . . . . . . . . . 4 4. FaNTEL Message Procession . . . . . . . . . . . . . . . . . . 4 4.1. Prerequisites for Processing . . . . . . . . . . . . . . 4 4.2. Local FA-ID Determination . . . . . . . . . . . . . . . . 4 4.3. FA-ID Matching and Decision Logic . . . . . . . . . . . . 4 4.4. Intra-Area Processing Procedure . . . . . . . . . . . . . 5 4.5. Border Node Relay Decision . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction 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. Hu Expires 21 April 2026 [Page 2] Internet-Draft draft-hu-fantel-area-00 October 2025 2. Conventions Used in This Document 2.1. Abbreviations IGP: Interior Gateway Protocol FaNTEL: Fast Notification for Traffic Engineering and Load Balancing WAN: Wide Area Network 2.2. Requirements Language 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. 3. FaNTEL Area Definition 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. 3.1. For OSPFv2 and OSPFv3 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. Hu Expires 21 April 2026 [Page 3] Internet-Draft draft-hu-fantel-area-00 October 2025 3.2. For IS-IS 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. 4. FaNTEL Message Procession 4.1. Prerequisites for Processing 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. 4.2. Local FA-ID Determination 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. 4.3. FA-ID Matching and Decision Logic 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. Hu Expires 21 April 2026 [Page 4] Internet-Draft draft-hu-fantel-area-00 October 2025 4.4. Intra-Area Processing Procedure 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. 4.5. Border Node Relay Decision 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. 5. Security Considerations TBD 6. IANA Considerations TBD 7. Acknowledgments TBD 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References Hu Expires 21 April 2026 [Page 5] Internet-Draft draft-hu-fantel-area-00 October 2025 Author's Address Zehua Hu China Telecom Guangzhou China Email: huzh2@chinatelecom.cn Hu Expires 21 April 2026 [Page 6]