| Internet-Draft | IGP Flex-Algorithm with Common Address | July 2022 |
| Hu, et al. | Expires 8 January 2023 | [Page] |
An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. IGP Flex-Algorithm can be used with Segment Routing (SR) or IP data plane. When used with SR data plane, Flex-Algorithm requires to allocate algorithm specific Prefix Segment Identifiers (SIDs) or algorithm specific SRv6 Locators. When used with IP data plane, Flex-Algorithm requires to allocate algorithm specfic IPv4 or IPv6 prefixes. This increases the complexity and overhead of managing, advertising and maintaining additional SR SIDs, SRv6 Locators and IPv4 or IPv6 prefixes, which may not be affordable to some networks and network devices.¶
This document extends IGP Flex-Algorithm to allow the use of common SR SIDs, SRv6 Locators and IP prefixes among multiple Flex-Algorithms.¶
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.¶
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 8 January 2023.¶
Copyright (c) 2022 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.¶
The IGP Flexible Algorithm (Flex-Algorithm) [I-D.ietf-lsr-flex-algo] specifies a way of computing a constraint-based path using IGP. IGP Flex-Algorithm can be used with Segment Routing (SR) or IP data plane . When used with SR data plane, Flex-Algorithm requires to allocate algorithm specific Prefix Segment Identifiers (SIDs) [RFC8402] or algorithm specific SRv6 Locators [RFC8986]. When used with IP data plane, Flex-Algorithm requires to allocate algorithm specfic IPv4 or IPv6 prefixes [I-D.ietf-lsr-ip-flexalgo]. The current Flex-Algorithm mechanism increases the complexity and overhead of managing, advertising and maintaining additional SR SIDs, SRv6 Locators and IPv4 prefixes, which may not be affordable to some networks and devices.¶
For example, [I-D.ietf-lsr-isis-srv6-extensions] and [I-D.ietf-lsr-ospfv3-srv6-extensions] define the IGP Extensions to support SRv6. For each Flex-Algorithm, separate SRv6 locators, End SIDs and End.X SIDs needs to be allocated and advertised. As the number of Flex-Algorithm increases, it the pressure on the IGP would increase accordingly.¶
In addition, SInce the SRv6 VPN SIDs are always associated with the Flex-Algorithm to which the SRv6 Locator is allocated, it is impossible to steer different service flows of an SRv6 VPN using different Flex-Algorithm.¶
To overcome the above issues and limitation with IGP Flex-Algo, this document defines the Common Address (CA) Flex-Algorithm extensions to allow the use of the same set of SR SIDs, SRv6 Locators, or IP prefixes among multiple Flex-Algorithms. Here the term Common Address (CA) refers to the common set of SR SIDs, SRv6 Locators or IP prefixes respectively for SR or IP data plane.¶
Based on the CA Flex-Algo mechanism, constrainet-based path computation is done for each Flex-Algorithm, and the routing entries for each Flex-Algorithm is maintained in a separate Routing Information Base (RIB). For packet forwarding, some additional data plane field in packet header is needed to select the correct RIB for the incoming packet lookup to make the forwarding decision. [I-D.li-6man-topology-id] proposes the IPv6 extensions to carry the topology and/or Algorithm ID in the data plane. The extensions to other data plane are for further study. Such data plane mechanisms together with the control plane extensions in this document provides a CA Flex-Algo solution.¶
To guarantee loop free forwarding, all routers that participate in a Flex-Algorithm MUST agree on the Flex-Algorithm Definition (FAD).¶
The advertisement of FAD for CA Flex-Algorithm is not changed. Selected nodes within the IGP domain MUST advertise FADs as described in Sections 5, 6, and 7 of [I-D.ietf-lsr-flex-algo].¶
When a router is configured to support a particular CA Flex-Algorithm, we say it is participating in that CA Flex-Algorithm.To guarantee the presence of the application specific forwarding state associated with a particular Flex-Algorithm, a router MUST advertise its participation for a particular Flex-Algorithm.¶
The following sections describe how the CA Flex-Algorithm participation is advertised in IGP protocols.¶
The ISIS [ISO10589] CA 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: TBD¶
Length: Variable¶
Algorithm (1 octet): Value from 128 to 255.¶
The CA 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 CA Algorithm Sub-TLV is advertised, MUST NOT be set.¶
The CA Algorithm Sub-TLV is optional. It MUST NOT be advertised more than once at a given level. A router receiving multiple CA Algorithm sub-TLVs from the same originator MUST select the first advertisement in the lowest-numbered LSP and subsequent instances of the CA Algorithm Sub-TLV MUST be ignored.¶
The CA Flex-Algorithm participation advertised in the IS-IS CA Algorithm Sub-TLV is topology independent. When a router advertises participation in the IS-IS CA Algorithm Sub-TLV, the participation applies to all topologies in which the advertising node participates.¶
The CA Algorithm TLV is a top-level TLV of the OSPFv3 Router Information Opaque 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 2 | Algorithm ... | Algorithm n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD¶
Length: Variable¶
Algorithm (1 octet): Value from 128 to 255.¶
When multiple of the CA Algorithm TLVs are received from a given router, the receiver MUST use the first occurrence of the TLV in the OSPFv3 Router Information Opaque LSA. If the CA Algorithm TLV appears in multiple Router Information Opaque LSAs that have different flooding scopes, the CA Algorithm TLV in the Router Information Opaque LSA with the area-scoped flooding scope MUST be used. If the CA Algorithm TLV appears in multiple Router Information Opaque LSAs that have the same flooding scope, the CA Algorithm TLV in the Router Information (RI) Opaque LSA with the numerically smallest Instance ID MUST be used and subsequent instances of the CA Algorithm TLV MUST be ignored.¶
The RI LSA can be advertised at any of the defined opaque flooding scopes (link, area, or Autonomous System (AS)). For the purpose of CA Algorithm TLV advertisement, area-scoped flooding is REQUIRED.¶
The SRv6 locator TLV is defined in [I-D.ietf-lsr-isis-srv6-extensions] and [I-D.ietf-lsr-ospfv3-srv6-extensions], which contains an algorithm and indicates that the locator only performs path calculation in this algorithm plane.¶
This document defines a new flag in the SRv6 Locator TLV to indicate that the locator has the ability to be used for path calculations in multiple CA Flex-Algorithms planes. The position of this flag is BIT(1) in IS-IS and BIT(2) in OSPFv3.¶
This bit is set in the Flags in the Locator TLV in which the value of the algorithm field is 0. When the algorithm is non-zero, the flag MUST NOT be set.¶
C-Flag: CA Flex-Algorithm Flag.¶
A receiver do not support machanisms defined in this document MUST ignore this flag.¶
The SRv6 SIDs associated with Adjacencies is defined in [I-D.ietf-lsr-isis-srv6-extensions] and [I-D.ietf-lsr-ospfv3-srv6-extensions] and is explicitly allocated by the locator.¶
A new Flag calle is defined to specify that the locator associated with the adjacent SID has the C flag.¶
C-Flag: CA Flex-Algorithm Flag.¶
The position of this flag is BIT(4) in IS-IS and OSPFv3.¶
This bit is set in Flags in SRv6 END.X and LAN END.X SID TLV in which the value of the algorithm field is 0. When the Locator corresponding to the End.X SID does not have the C flag set, the C flag in the END.X and LAN END.X SID TLV MUST NOT be set.¶
A receiver do not support machanisms defined in this document MUST ignore this flag.¶
The CA Flex-Algorthm can considered as yet another data-plane of the Flex-Algorithm as described [I-D.ietf-lsr-flex-algo].¶
Participation for the CA Flex-Algorithm is signalled as described in Section 3 and is specific to the CA Flex-Algorithm data-plane.¶
The calculation of CA Flex-Algorithm paths follows what is described in [I-D.ietf-lsr-flex-algo]. This computation uses the CA Flex- Algorithm data-plane participation and is independent of the Flex-Algorithm calculation done for native SR or IP data plane.¶
The CA Flex-Algorithm data-plane only considers the participating nodes during the Flex-Algorithm calculation. When computing paths for a given CA Flex-Algorithm, all nodes that do not advertise participation for the CA Flex-Algorithm, as described in Section 3, MUST be pruned from the topology.¶
This document updates the ISIS "Sub-TLVs for TLV 242" registry as follows:¶
+-------+--------------------------------+---------------------------+
| Value | TLV Name | Reference |
+-------+--------------------------------+---------------------------+
| TBD | CA Algorithm Sub-TLV | This Document Section 3.1 |
+-------+----------------------+-------------------------------------+
This document updates the OSPFv3 Router Information (RI) TLVs registry as follows:¶
+-------+--------------------------------+---------------------------+
| Value | TLV Name | Reference |
+-------+--------------------------------+---------------------------+
| TBD | CA Algorithm Sub-TLV | This Document Section 3.2 |
+-------+--------------------------------+---------------------------+
This document updates the ISIS Locator Flags registry as follows:¶
Bit # Name
------------------ ------------------------------
TBD(suggest bit 1) CA Flex-Algorithm Flag (C-flag)
This document updates the OSPFv3 Locator Flags registry as follows:¶
Bit # Name
------------------ ------------------------------
TBD(suggest bit 2) CA Flex-Algorithm Flag (C-flag)
This document also updates the ISIS and OSPFv3 SRv6 END.X and LAN END.X SID TLV Flags registry as follows:¶
Bit # Name
------------------ ------------------------------
TBD(suggest bit 4) CA Flex-Algorithm Flag (C-flag)