IGP Flex Soft Dataplane

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 15 April 2025.¶

Copyright Notice

Copyright (c) 2024 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

Advertisement of IGP Flex-Algo[RFC9350] participation requires a dataplane context. Existing data planes which have been defined include:¶

Segment Routing Dataplane [RFC8667] [RFC8665]¶

IP Flex Dataplane [RFC9502]¶

The need to use an IGP Flexible Algorithm may occur in deployments where none of the existing dataplanes are supported or suitable.¶

In such cases a "soft dataplane" MAY be used to provide the necessary context for advertisement of Flex-Algo support. This document defines the mechanisms to advertise such a dataplane.¶

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. Use Case Discussion

A deployment may require the use of flex-algo to achieve traffic flows that meet certain constraints. In some cases, flex-algo paths may be used by an application that does not require the use of any of the currently defined dataplanes supported by flex-algo. The use of these dataplanes may not be desired and/or is not supported in the network. IP Flex-algo extends flex-algo so that it can be used directly with IPv4 and IPv6 forwarding, but the use of IPv4/IPv6 Algorithm specific prefix adverisements may not always be possible, especially if the existing deployment does not allow for the lack of reachability using the base IGP SPF (AKA algorithm 0) for these prefixes. The use of a soft dataplane provides context which still allows flex-algo to be deployed in such cases.¶

The new dataplane is referred to as "soft" because the flex-algo paths computed for this dataplane are not expected to be used by forwarding directly - e.g., they will not be installed in the data path. They may be used by an application to create a forwarding state that is maintained by the application itself. One such use case might be to support multicast distribution over a constrained topology in an IP only network.¶

Note that multiple flex algorithms - each defined for a different use case - can be advertised in the context of a single soft dataplane. Therefore, it is expected that a single soft dataplane will suffice for all possible use cases.¶

The following sections define how to advertise flex-algorithm support in the context of the soft dataplane.¶

4. IS-IS Soft Dataplane Algorithm Sub-TLV

The IS-IS [ISO10589] Soft Dataplane Algorithm Sub-TLV is a sub-TLV of the IS-IS Router Capability TLV [RFC7981] and 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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1   |  Algorithm 2  | Algorithm ... |  Algorithm n  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type (1 octet):

Soft Dataplane Algorithm Sub-TLV (Value TBD)¶

Length (1 octet):

Variable¶

Algorithm (1 octet):

Value from 128 to 255¶

The IS-IS Soft Dataplane Algorithm Sub-TLV MUST be propagated throughout the level and MUST NOT be advertised across level boundaries. Therefore, the S bit in the Router Capability TLV, in which the IS-IS Soft Dataplane Algorithm Sub-TLV is advertised, MUST NOT be set.¶

The IS-IS Soft Dataplane Algorithm Sub-TLV is optional. It MUST NOT be advertised more than once at a given level. A router receiving multiple IS-IS Soft Dataplane Algorithm sub-TLVs from the same originator MUST select the first advertisement in the lowest-numbered Link State PDU (LSP), and subsequent instances of the IS-IS Soft Dataplane Algorithm Sub-TLV MUST be ignored.¶

Algorithms outside the Flex-Algorithm range (128-255) MUST be ignored by the receiver. This situation SHOULD be logged as an error.¶

The Flex-Algorithm participation advertised in the IS-IS Soft Dataplane Algorithm Sub-TLV is topology independent. When a router advertises participation in the IS-IS Soft Dataplane Algorithm Sub-TLV, the participation applies to all topologies in which the advertising node participates.¶

5. OSPF Soft Dataplane Algorithm TLV

The OSPF [RFC2328] Soft Dataplane Algorithm TLV is a top-level TLV of the Router Information Opaque Link State Advertisement (LSA) [RFC7770] and 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Algorithm 1 | Algorithm...  |   Algorithm n |               |
+-                                                             -+
|                                                               |
+                                                               +

Type (2 octets):

Soft Dataplane Algorithm TLV (TBD)¶

Length( 2 octets):

Variable¶

Algorithm (1 octet):

Value from 128 to 255¶

The OSPF Soft Dataplane Algorithm TLV is optional. It MUST only be advertised once in the Router Information LSA.¶

Algorithms outside the Flex-Algorithm range (128-255) MUST be ignored by the receiver. This situation SHOULD be logged as an error.¶

When multiple OSPF Soft Dataplane Algorithm TLVs are received from a given router, the receiver MUST use the first occurrence of the TLV in the Router Information LSA. If the OSPF Soft Dataplane Algorithm TLV appears in multiple Router Information LSAs that have different flooding scopes, the OSPF Soft Dataplane Algorithm TLV in the Router Information LSA with the area-scoped flooding scope MUST be used. If the OSPF Soft Dataplane Algorithm TLV appears in multiple Router Information LSAs that have the same flooding scope, the OSPF Soft Dataplane Algorithm TLV in the Router Information LSA with the numerically smallest Instance ID (Opaque ID for OSPFv2 or Link State ID for OSPFv3) MUST be used, and subsequent instances of the OSPF Soft Dataplane Algorithm TLV MUST be ignored.¶

The Router Information LSA can be advertised at any of the defined flooding scopes (link, area, or Autonomous System (AS)). For the purpose of OSPF Soft Dataplane Algorithm TLV advertisement, area or AS-scoped flooding is REQUIRED. The AS flooding scope SHOULD NOT be used unless local configuration policy on the originating router indicates domain-wide flooding.¶

The Flexible Algorithm participation advertised in the OSPF Soft Dataplane Algorithm TLV is topology independent. When a router advertises participation in an OSPF Soft Dataplane Algorithm TLV, the participation applies to all topologies in which the advertising node participates.¶

6. IANA Considerations

Authors' Addresses