



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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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]
