IGP Flexible Algorithm Utilizing Link Bit Error Rate Metric

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 19 January 2027.¶

Copyright Notice

Copyright (c) 2026 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.¶

Table of Contents

1. Introduction

Link Bit Error Rate (hereafter "link BER metric") refers to the percentage of transmitted bits that are received in error over a network link. It is a key metric for network performance evaluation. A high BER metric can impact service quality and forwarding efficiency. To maintain optimal forwarding paths, it is desirable to avoid links with excessive BER metric values during IGP path computation.¶

The IGP Flexible Algorithms enable IGPs to compute constraint-based paths [RFC9350]. Current path computation methods focus on determining the minimum path cost from source to destination. Flex-Algorithm already supports path computation based on IGP cost, minimum link delay, and traffic-engineering metrics. [RFC9843] defines additional generic metric types and constraints.¶

[I-D.gandhi-lsr-ber] defines BER metric advertisement extensions for IS-IS and OSPF. This document specifies a BER-metric-based exclusion constraint for Flex-Algorithm path computation.¶

2. Conventions Used in This Document

3. Overview

This document defines a new Flexible Algorithm Definition (FAD) that exclude links exceeding a configured maximum BER threshold.¶

Existing metric-type (for example, IGP, TE, and delay) remains unchanged.¶

[I-D.gandhi-lsr-ber] defines extensions for advertising Packets with Bit Errors (PER) metric for links. Utilizing the link PER metric for Flex-Algorithm path computation will be covered in the future revision of this document.¶

4. Exclude Maximum Link BER Sub-TLV

A new sub-sub-TLV, the "Exclude Maximum Link BER Sub-TLV", is defined as part of the FAD TLV. To ensure loop-free forwarding, all routers participating in a Flex-Algorithm MUST agree on the FAD definition. Selected nodes within the IGP domain MUST advertise FADs by including them in routing updates, as specified in Sections 5, 6, and 7 of [RFC9350].¶

The "Exclude Maximum Link BER Sub-TLV" defines the maximum allowable BER metric value for links in the Flex-Algorithm topology. When this sub-sub-TLV is present, links whose advertised BER metric exceeds the configured maximum BER metric value are excluded from path computation.¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type     |    Length     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Maximum Link BER                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Type            |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Maximum Link BER               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. Calculation of Flexible Algorithm Paths

The following rule is added to the topology pruning rules in Section 13 of [RFC9350]:¶

1. Check if any exclude FA-EMB rule is part of the Flex-Algorithm definition. If such exclude rule exists and the link has BER metric advertised, check whether the link satisfies the FA-EMB rule. If not, the link MUST be pruned from the computation.¶

6. Operational Considerations

In some deployments, the BER metric may oscillate around the configured threshold, causing repeated topology updates and recomputations. The following mechanisms can improve stability:¶

1. Delayed collection: BER metric values advertised into IGP can be computed over a sufficiently long observation interval.¶
2. Averaging and normalization: BER metric values SHOULD be derived from averaged data (for example EMA) and MAY be normalized to avoid advertising insignificant changes.¶
3. Flapping suppression: Implementations MAY apply dampening or hold-down timers before advertising BER metric changes that repeatedly cross the exclusion threshold.¶

7. Security Considerations

The security considerations in [RFC9350], [RFC8570], [RFC7471], [RFC9479], [RFC9492], and [I-D.gandhi-lsr-ber] apply.¶

8. IANA Considerations

This document requests allocation of two new code points.¶

Acknowledgments

TBA.¶

Author's Address