IGP Flex Soft Dataplane

Advertisement of IGP Flex-Algo participation requires a dataplane context. Existing data planes which have been defined include: Segment Routing Dataplane IP Flex Dataplane 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.

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 when, and only when, they appear in all capitals, as shown here.

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.

The IS-IS Soft Dataplane Algorithm Sub-TLV is a sub-TLV of the IS-IS Router Capability TLV and has the following format:

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.

The OSPF Soft Dataplane Algorithm TLV is a top-level TLV of the Router Information Opaque Link State Advertisement (LSA) and has the following format:

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.

This document updates the "OSPF Router Information (RI) TLVs" registry as follows:

Value	TLV Name	Reference
TBD	Soft Dataplane Algorithm	draft-ginsberg-lsr-soft-dataplane

This document updates the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry as follows:

Value	TLV Name	Reference
TBD	Soft Dataplane Algorithm	draft-ginsberg-lsr-soft-dataplane

This document creates no new security issues for the IGPs.