Internet-Draft IGP Flex-Algorithm with Link Loss February 2024
Wang, et al. Expires 23 August 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-wang-lsr-flex-algo-link-loss-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
Y. Wang
Huawei
G. Xu
Huawei
X. Geng
Huawei
J. Dong
Huawei

IGP Flexible Algorithm with Link Loss

Abstract

IGP Flexible Algorithms allow IGPs to compute constraint-based paths. Since link packet loss rate plays an important role in network evaluation, links with high packet loss rate should be bypassed during forwarding. This draft proposes a path computation method based on a maximum link loss constraint to prune unsatisfied links in Flexible Algorithms.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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.

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 23 August 2024.

Table of Contents

1. Introduction

Link packet loss rate (link loss) is a measure of the percentage of data packets that are lost during transmission over a network. It is an important performance metric that directly impacts the quality of service, network congestion, security, and overall network efficiency. Ensuring a low packet loss rate is essential for maintaining efficient and secure network operations. Consequently, It is necessary to avoid passing through links with a high packet loss rate during forwarding.

The link loss is advertised by the Unidirectional Link Loss Sub-TLV defined in [RFC8570] by IS-IS and [RFC7471] by OSPF, which describes the loss (as a packet percentage) between two directly connected IS-IS neighbors. This Sub-TLV is carried in the Application-Specific Link Attributes Sub-TLV advertised by IS-IS [RFC9479] or OSPF [RFC9492]. The link packet loss rate can be measured by methods such as TWAMP [RFC5357] and STAMP [RFC8762], which is beyond the scope of this document.

IGP Flexible Algorithms allow IGPs to compute constraint-based paths [RFC9350]. Current path computation methods are based on calculating the minimum cost of the path from the source to the destination. Flex-Algorithm has already supported path computation with the IGP cost, the minimum link delay and the traffic-engineering metric. [I-D.ietf-lsr-flex-algo-bw-con] defines a family of generic metrics (e.g. bandwidth based metric type) and bandwidth related constraints to support path computation based on bandwidth. However, current calculation types and metric types cannot support path computation based on link loss, since the cost of the path should be defined as the maximum/minimum value among all passing links.

To overcome the above issue, there are two solutions. First, new operators like maximum value operator can be defined, which works as a step function. When the link loss exceeds a threshold, the cost of the link is set to the maximum. Second, new Flexible Algorithm Definition (FAD) constraints can be defined to exclude links that do not meet the link loss requirements during path calculation. The second method is specifically demonstrated in this document. The general ideas are as below.

With a new FAD constraint Sub-TLV advertised by IGP, links with low packet loss rate will be selected for path computation. The new Exclude Maximum Link Loss Sub-TLVs are defined in Section 2. The Flex-Algorithm calculation method based on link loss is presented in Section 3. Link packet loss rate is obtained from the existing Unidirectional Link Loss Sub-TLV defined in RFC9479 and RFC9492.

A new Exclude Maximum Link Loss Sub-TLV is defined as a sub-TLV of the FAD TLV. To guarantee loop free forwarding, all routers that participate in a Flex-Algorithm MUST agree on the FAD. Selected nodes within the IGP domain MUST advertise FADs as described in Sections 5, 6, and 7 of [RFC9350].

The Exclude Maximum Link Loss Sub-TLV is proposed to specify the upper limit of the link loss. When this Sub-TLV is carried in a FAD TLV, all links with packet loss rate larger than the defined maximum link loss value will be excluded from the Flex-Algorithm topology.

IS-IS Flex-Algorithm Exclude Maximum Link Loss Sub-TLV (FAEML) is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type     |    Length     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Max Link Loss                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type: 252(TBA)

      Length: 3 octets

      Max Link Loss:  This 24-bit field carries link packet loss as a
    percentage of the total traffic sent over a configurable interval.
    The basic unit is 0.000003%, where (2^24 - 2) is 50.331642%. This
    value is the highest packet-loss percentage that can be expressed.
    Therefore, measured values that are larger than the field maximum
    SHOULD be encoded as the maximum value.
Figure 1: IS-IS FAEML Sub-TLV

The FAEML sub-TLV MUST appear at most once in the FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-TLV MUST be ignored by the receiver.

The maximum link loss advertised in FAEML Sub-TLV MUST be compared with the link loss advertised in Sub-Sub-TLV 36 [RFC8570] of ASLA Sub- TLV [RFC9479]. If L-Flag is set in the ASLA sub-TLV, the maximum link loss advertised in FAEML sub-TLV MUST be compared with the link loss advertised by the sub-TLV 36 of the TLV 22/222/23/223/141 [RFC5305] as defined in [RFC9479] Section 4.2.

If the link loss is larger than the maximum link loss advertised in FAEML sub-TLV, the link MUST be excluded from the Flex-Algorithm topology. If a link does not have the link loss advertised but the FAD contains the FAEML sub-TLV, then it MUST NOT be excluded from the Flex-Algorithm topology.

OSPF Flex-Algorithm Exclude Maximum Link Loss Sub-TLV (FAEML) is a sub-TLV of the OSPF FAD sub-TLV. It has the following format:

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Type            |            Length           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Max Link Loss                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type: 252(TBA)

      Length: 3 octets

      Max Link Loss:  This 24-bit field carries link packet loss as a
    percentage of the total traffic sent over a configurable interval.
    The basic unit is 0.000003%, where (2^24 - 2) is 50.331642%. This
    value is the highest packet-loss percentage that can be expressed.
    Therefore, measured values that are larger than the field maximum
    SHOULD be encoded as the maximum value.
Figure 2: OSPF FAEML Sub-TLV

The FAEML sub-TLV MUST appear at most once in the FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-TLV MUST be ignored by the receiver.

The maximum link loss advertised in FAEML Sub-TLV MUST be compared with the link loss advertised in Sub-Sub-TLV 30 [RFC7471] of ASLA Sub- TLV [RFC9492]. The ASLA Sub-TLV is advertised in Extended Link Opaque LSAs [RFC7684] for OSPFv2 and E-Router-LSAs [RFC8362] for OSPFv3.

If the link loss is larger than the maximum link loss advertised in FAEML sub-TLV, the link MUST be excluded from the Flex-Algorithm topology. If a link does not have the link loss advertised but the FAD contains the FAEML sub-TLV, then it MUST NOT be excluded from the Flex-Algorithm topology.

3. Calculation of Flexible Algorithm Paths

A new rule is added to the rules used to prune links from the topology during the Flex-Algorithm computation in Section 13 of [RFC9350].

4. Operational Considerations

In some scenarios, the link packet loss rate may fluctuate around the threshold value. Consequently, the link status can be frequently changed between available and unavailable, which could lead to frequent flex-algo calculation. To solve this problem, a suppression mechanism can be developed. When the packet loss rate is detected on a frequent change, a timer can be set to delay the update process.

5. IANA Considerations

5.1. IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV

Type: 252(TBA)

Description: IS-IS Exclude Maximum Link Loss Sub-TLV

Reference: This document Section 2.1

5.2. OSPF Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV

Type: 252(TBA)

Description: OSPF Exclude Maximum Link Loss Sub-TLV

Reference: This document Section 2.2

6. References

6.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5305]
Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, , <https://www.rfc-editor.org/info/rfc5305>.
[RFC7684]
Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, , <https://www.rfc-editor.org/info/rfc7684>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8362]
Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, , <https://www.rfc-editor.org/info/rfc8362>.
[RFC9350]
Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, , <https://www.rfc-editor.org/info/rfc9350>.
[RFC9479]
Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, "IS-IS Application-Specific Link Attributes", RFC 9479, DOI 10.17487/RFC9479, , <https://www.rfc-editor.org/info/rfc9479>.
[RFC9492]
Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, J., and J. Drake, "OSPF Application-Specific Link Attributes", RFC 9492, DOI 10.17487/RFC9492, , <https://www.rfc-editor.org/info/rfc9492>.

6.2. Informative References

[I-D.ietf-lsr-flex-algo-bw-con]
Hegde, S., Britto, W., Shetty, R., Decraene, B., Psenak, P., and T. Li, "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints", Work in Progress, Internet-Draft, draft-ietf-lsr-flex-algo-bw-con-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-07>.
[RFC5357]
Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, , <https://www.rfc-editor.org/info/rfc5357>.
[RFC7471]
Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, , <https://www.rfc-editor.org/info/rfc7471>.
[RFC8570]
Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, , <https://www.rfc-editor.org/info/rfc8570>.
[RFC8762]
Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, , <https://www.rfc-editor.org/info/rfc8762>.

Authors' Addresses

Yifan Wang
Huawei
Huawei Bld., No. 156 Beiqing Rd.
Beijing
100095
China
Guoqi Xu
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing
100095
China
Xuesong Geng
Huawei
Huawei Bld., No. 156 Beiqing Rd.
Beijing
100095
China
Jie Dong
Huawei
Huawei Bld., No. 156 Beiqing Rd.
Beijing
100095
China