LSR Shaofu. Peng Internet-Draft Ran. Chen Intended status: Standards Track ZTE Corporation Expires: 27 November 2023 Ketan. Talaulikar Arrcus, Inc Peter. Psenak Cisco Systems 26 May 2023 Algorithm Related IGP-Adjacency SID Advertisement draft-ietf-lsr-algorithm-related-adjacency-sid-05 Abstract Segment Routing architecture supports the use of multiple routing algorithms, i.e., different constraint-based shortest-path calculations can be supported. There are two standard algorithms: SPF and Strict-SPF, defined in Segment Routing architecture. There are also other user defined algorithms according to Flex-algo applicaiton. However, an algorithm identifier is often included as part of a Prefix-SID advertisement, that maybe not satisfy some scenarios where multiple algorithm share the same link resource. This document complement that the algorithm identifier can be also included as part of a Adjacency-SID advertisement. 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 27 November 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Peng, et al. Expires 27 November 2023 [Page 1]
Internet-Draft algo-related adj-sid May 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Adjacency Segment Identifier per Algorithm . . . . . . . . . 4 4.1. ISIS Adjacency Segment Identifier per Algorithm . . . . . 4 4.1.1. ISIS Adjacency-SID per Algorithm Sub-TLV . . . . . . 4 4.1.2. ISIS LAN Adjacency-SID per Algorithm Sub-TLV . . . . 5 4.2. OSPFv2 Adjacency Segment Identifier per Algorithm . . . . 6 4.2.1. OSPFv2 Adjacency-SID per Algorithm Sub-TLV . . . . . 6 4.2.2. OSPFv2 LAN Adjacency-SID per Algorithm Sub-TLV . . . 7 4.3. OSPFv3 Adjacency Segment Identifier per Algorithm . . . . 8 4.3.1. OSPFv3 Adjacency-SID per Algorithm Sub-TLV . . . . . 8 4.3.2. OSPFv3 LAN Adjacency-SID per Algorithm Sub-TLV . . . 9 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Examples of Algorithm Specific Adjacency-SID . . . . . . 12 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7.1. IANA ISIS Considerations . . . . . . . . . . . . . . . . 13 7.2. IANA OSPFv2 Considerations . . . . . . . . . . . . . . . 14 7.3. IANA OSPFv3 Considerations . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction Segment Routing architecture [RFC8402] supports the use of multiple routing algorithms, i.e., different constraint-based shortest-path calculations can be supported. There are two standard algorithms, i.e., SPF and Strict-SPF, that defined in Segment Routing architecture. For SPF, the packet is forwarded along the well known ECMP-aware Shortest Path First (SPF) algorithm employed by the IGPs. However, it is explicitly allowed for a midpoint to implement another forwarding based on local policy. For Strict Shortest Path First (Strict-SPF), it mandates that the packet be forwarded according to Peng, et al. Expires 27 November 2023 [Page 2]
Internet-Draft algo-related adj-sid May 2023 the ECMP-aware SPF algorithm and instructs any router in the path to ignore any possible local policy overriding the SPF decision. There are also other user defined algorithms according to IGP Flex Algorithm [RFC9350]. IGP Flex Algorithm proposes a solution that allows IGPs themselves to compute constraint based paths over the network, and it also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint- based paths. It specifies a set of extensions to ISIS, OSPFv2 and OSPFv3 that enable a router to send TLVs that identify (a) calculation-type, (b) specify a metric-type, and (c) describe a set of constraints on the topology, that are to be used to compute the best paths along the constrained topology. A given combination of calculation-type, metric-type, and constraints is known as an FAD (Flexible Algorithm Definition). However, an algorithm identifier is often included as part of a Prefix-SID advertisement, that maybe not satisfy some scenarios where multiple algorithm share the same link resource. In addition to Prefix-SID, this document complement that the algorithm identifier can be also included as part of an Adjacency-SID advertisement for SR-MPLS, so that each Flex-algo plane corresponding to different algorithm types can be allocated with a dedicated segment ID related to the corresponding algorithm type. 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-cases The algorithm related SID can be used to apply different treatments for packets classified into different algorithms. Some known treatments are described in the following use cases: * One use-case is that a TI-LFA backup path computed in Flex-algo plane may contain Adjacency Segments and require to contain an algorithm-aware Adjacency-SID, which can not only steer the traffic towards the link, but also distinguish traffic between different algorithms. Benefit from this, for the protected Adjacency-SID which belongs to a TI-LFA path within specific Flex- algo plane, the backup path of such Adjacency-SID can continue to follow the algorithm specific constraints that is consistent with the primary path. Peng, et al. Expires 27 November 2023 [Page 3]
Internet-Draft algo-related adj-sid May 2023 * Another use-case is to help the enhancement PHB (per hop behavior) related with specific algorithm type on the data plane. Generally, QoS policies related to the algorithm type of each Flex-algo plane can be configured and installed, and the packets can be forwarded based one the algorithm related SID and QoS policy. * Another use-case is to help the enhancement OAM related with specific algorithm type on the control plane and data plane, such as statistics of traffic of different algorithms on the same link, ping/traceroute detection (or other tools) for specific algorithm. There may be other potential use cases. Note that the specification details of these treatments are beyond the scope of this document. This document only provides foundation required for these treatments. 4. Adjacency Segment Identifier per Algorithm This section describe that the algorithm related segment ID is flooded through the IGP protocol. 4.1. ISIS Adjacency Segment Identifier per Algorithm [RFC8667] describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane. It defined Adjacency Segment Identifier (Adj-SID) sub-TLV advertised with TLV- 22/222/23/223/141, and Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV advetised with TLV-22/222/23/223. Accordingly, this document defines two new optional Sub-TLVs, "ISIS Adjacency-SID per Algorithm Sub-TLV" and "ISIS LAN Adjacency-SID per Algorithm Sub-TLV", which contains a field representing the algorithm type. 4.1.1. ISIS Adjacency-SID per Algorithm Sub-TLV ISIS Adjacency-SID per Algorithm Sub-TLV 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 | Flags | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ISIS Adjacency-SID per Algorithm Format Peng, et al. Expires 27 November 2023 [Page 4]
Internet-Draft algo-related adj-sid May 2023 where: Type: TBA1. Length: 6 or 7 depending on size of the SID. Flags: Refer to Adjacency Segment Identifier (Adj-SID) sub-TLV. Weight: Refer to Adjacency Segment Identifier (Adj-SID) sub-TLV. Algorithm: The Algorithm field contains the identifier of the algorithm the router uses to apply algorithm specific treatment configured on the adjacency. SID/Label/Index: Refer to Adjacency Segment Identifier (Adj-SID) sub- TLV. For a P2P link, an SR-capable router MAY allocate different Adjacency-SIDs for different algorithms, if this link participates in the plane related to different algorithms. 4.1.2. ISIS LAN Adjacency-SID per Algorithm Sub-TLV ISIS LAN Adjacency-SID per Algorithm Sub-TLV 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 | Flags | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor System-ID (ID length octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: ISIS LAN Adjacency-SID per Algorithm Format where: Type: TBA2. Peng, et al. Expires 27 November 2023 [Page 5]
Internet-Draft algo-related adj-sid May 2023 Length: Variable. Flags: Refer to Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV. Weight: Refer to Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV. Algorithm: The Algorithm field contains the identifier of the algorithm the router uses to apply algorithm specific treatment configured on the adjacency. SID/Label/Index: Refer to Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV. For a broadcast link, an SR-capable router MAY allocate different Adjacency-SIDs for different algorithms, if this link participates in the plane related to different algorithms. 4.2. OSPFv2 Adjacency Segment Identifier per Algorithm [RFC8665] describes the OSPFv2 extensions that need to be introduced for Segment Routing operating on an MPLS data plane. It defined Adj- SID Sub-TLV and LAN Adj-SID Sub-TLV advertised with Extended Link TLV defined in [RFC7684]. Accordingly, this document defines two new optional Sub-TLVs, "OSPFv2 Adjacency-SID per Algorithm Sub-TLV" and "OSPFv2 LAN Adjacency-SID per Algorithm Sub-TLV", which contains a field representing the algorithm type. 4.2.1. OSPFv2 Adjacency-SID per Algorithm Sub-TLV OSPFv2 Adjacency-SID per Algorithm Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm | MT-ID | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: OSPFv2 Adjacency-SID per Algorithm Format where: Type: TBA3 Peng, et al. Expires 27 November 2023 [Page 6]
Internet-Draft algo-related adj-sid May 2023 Length: 7 or 8 octets, depending on the V-Flag. Flags: Refer to OSPFv2 Adj-SID Sub-TLV. Algorithm: The Algorithm field contains the identifier of the algorithm the router uses to apply algorithm specific treatment configured on the adjacency. MT-ID: Refer to OSPFv2 Adj-SID Sub-TLV. Weight: Refer to OSPFv2 Adj-SID Sub-TLV. SID/Index/Label: Refer to OSPFv2 Adj-SID Sub-TLV. For a P2P link, an SR-capable router MAY allocate different Adjacency-SIDs for different algorithms, if this link participates in the plane related to different algorithms. 4.2.2. OSPFv2 LAN Adjacency-SID per Algorithm Sub-TLV OSPFv2 LAN Adjacency-SID per Algorithm Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm | MT-ID | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: OSPFv2 LAN Adjacency-SID per Algorithm Format where: Type: TBA4 Length: 11 or 12 octets, depending on the V-Flag. Flags: Refer to OSPFv2 LAN Adjacency-SID Sub-TLV. Peng, et al. Expires 27 November 2023 [Page 7]
Internet-Draft algo-related adj-sid May 2023 Algorithm: The Algorithm field contains the identifier of the algorithm the router uses to apply algorithm specific treatment configured on the adjacency. MT-ID: Refer to OSPFv2 LAN Adj-SID Sub-TLV. Weight: Refer to OSPFv2 LAN Adj-SID Sub-TLV. Neighbor ID: Refer to OSPFv2 LAN Adj-SID Sub-TLV. SID/Index/Label: Refer to OSPFv2 LAN Adj-SID Sub-TLV. For a broadcast link, an SR-capable router MAY allocate different Adjacency-SIDs for different algorithms, if this link participates in the plane related to different algorithms. 4.3. OSPFv3 Adjacency Segment Identifier per Algorithm [RFC8666] describes the OSPFv3 extensions that need to be introduced for Segment Routing operating on an MPLS data plane. It defined Adj- SID Sub-TLV and LAN Adj-SID Sub-TLV advertised with Router-Link TLV as defined in [RFC8362]. Accordingly, this document defines two new optional Sub-TLVs, "OSPFv3 Adjacency-SID per Algorithm Sub-TLV" and "OSPFv3 LAN Adjacency-SID per Algorithm Sub-TLV", which contains a field representing the algorithm type. 4.3.1. OSPFv3 Adjacency-SID per Algorithm Sub-TLV OSPFv3 Adjacency-SID per Algorithm Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: OSPFv3 Adjacency-SID per Algorithm Format where: Type: TBA5 Length: 7 or 8 octets, depending on the V-Flag. Peng, et al. Expires 27 November 2023 [Page 8]
Internet-Draft algo-related adj-sid May 2023 Flags: Refer to OSPFv3 Adj-SID Sub-TLV. Weight: Refer to OSPFv3 Adj-SID Sub-TLV. Algorithm: The Algorithm field contains the identifier of the algorithm the router uses to apply algorithm specific treatment configured on the adjacency. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. SID/Index/Label: Refer to OSPFv3 Adj-SID Sub-TLV. For a P2P link, an SR-capable router MAY allocate different Adjacency-SIDs for different algorithms, if this link participates in the plane related to different algorithms. 4.3.2. OSPFv3 LAN Adjacency-SID per Algorithm Sub-TLV OSPFv3 LAN Adjacency-SID per Algorithm Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: OSPFv3 LAN Adjacency-SID per Algorithm Format where: Type: TBA6 Length: 11 or 12 octets, depending on the V-Flag. Flags: Refer to OSPFv3 LAN Adj-SID Sub-TLV. Weight: Refer to OSPFv3 LAN Adj-SID Sub-TLV. Peng, et al. Expires 27 November 2023 [Page 9]
Internet-Draft algo-related adj-sid May 2023 Algorithm: The Algorithm field contains the identifier of the algorithm the router uses to apply algorithm specific treatment configured on the adjacency. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. Neighbor ID: Refer to OSPFv3 LAN Adj-SID Sub-TLV. SID/Index/Label: Refer to OSPFv3 LAN Adj-SID Sub-TLV. For a broadcast link, an SR-capable router MAY allocate different Adjacency-SIDs for different algorithms, if this link participates in the plane related to different algorithms. 5. Procedures The method introduced in this document enables the traffic of different flex-algo plane to be distinguished when they are routed on the same link, and can be applied with different local treatment (such as providing different repair paths, traffic statistics, QoS policies, etc) per algorithm. A node may, according to each flex-algo plane (corresponding to the specific algorithm types) which it participated in, allocate segment identifiers corresponding to each algorithm types, and these segment identifiers need to be flooded through IGP. As defined in Section 4, algorithm field must be encoded in the flooded packet. Depending on implementation, SIDs allocation is generally triggered by configuration. For algorithm specific Adjacency-SID, one of the difficulties is that during this configuration phase it is not straightforward for a link to be included in an Flex-algo plane, as this can only be determined after all nodes in the network have negotiated the FAD. Note that Node-SID per algorithm may also face similar difficulties (considering the abnormal situation where nodes have to stop participating in the flex-algo plane after FAD negotiation, referring to section 5.3 of [RFC9350]). Developers can flexibly refer to any of the following implementation choices. * One choice is that as long as an IGP instance with an algorithm enabled for a level/area is configured on the node, the node may allocate Adjacency-SIDs for that algorithm statically for all links joined to that level/area. Similar way may be also applied to node-SID per algorithm. That is, algorithm specific SID can be allocated regardless of the felx-algo participation and wining Peng, et al. Expires 27 November 2023 [Page 10]
Internet-Draft algo-related adj-sid May 2023 FAD. If the router stops participating, or the link is excluded from the flex-algo, the advertised algorithm specific SID does not cause any issue, but is just not used. * Another choice is to allocate and withdraw algorithm specific Adjacency-SID dynamically according to the result of FAD negotiation, i.e., algorithm specific Adjacency-SID is allocated and advertised only for those links that have joined the Flex-algo plane. Similar choice may be also applied to node-SID per algorithm. This choice is RECOMMENDED. The RECOMMENDED implementation choice also make sense for other type of states per algorithm. A node may, according to each flex-algo plane (corresponding to the specific algorithm types) which it participated in, config local treatments (such as repair paths, traffic statistics counters, QoS policies, etc) corresponding to each algorithm types and apply them to the links that participated in the corresponding flex-algo plane. In this case, the node may dynamically create or delete these local treatments according to the result of FAD negotiation. The (LAN) Adjacency-SID per Algorithm Sub-TLV MUST not be used to advertise algorithm 0 specific SIDS. Note that the advertisement specification defined in Section 4 does not have any requirements for the SID allocation rules. Some particular advertisement method based on particular allocation rules are not within the scope of this document. Once the node originates an algorithm specific Adjacency-SID and sends it to the network, the coresponding local SID entry (i.e., an MPLS label forwarding entry) must be installed on the fowarding plane. The local SID entry, combined with local treatments (such as QoS polices), are used to continue to forward data packets in the context of the specific algorithm. A node may receive different algo-SIDs (corresponding to different algorithm types with the related flex-algo plane) originated from other nodes and flooded by IGP. As defined in Section 4, the algorithm field can be gotten from the flooded packet to indicate algorithm specific SIDs. Then, algo-SIDs, with other SIDs, are maintained in the link state database. If the received algorithm is not within the range [128,255], the related (LAN) Adjacency-SID per Algorithm Sub-TLV MUST be ingored. Peng, et al. Expires 27 November 2023 [Page 11]
Internet-Draft algo-related adj-sid May 2023 When a node receives a forwarding data packet whose active segment is an algorithm specific Adjacency-SID and matches the coresponding local SID entry, the node forwards the data packet to the corresponding outgoing port and applies algorithm related local treatments (such as QoS policies) to the packet. The local treatments may also be applied for the case of algorithm specific Node-SID. 5.1. Examples of Algorithm Specific Adjacency-SID The following figure shows an example of algorithm specific Adjacency-SID. [S1]--------[D]--------[S2] | | | | | | | | | [A]---------[B]--------[C] Figure 7: Flex-algo LFA Path with Algorithm Specific Adjacency-SID Suppose that node S1, A, B, D and their inter-connected links belongs to FA-id 128 plane, and S2, B, C, D and their inter-connected links belongs to FA-id 129 plane. The IGP metric of link B-D is 100, and all other links have IGP metric 1. Both FA-id 128 and 129 use IGP default metric type for path calculation. In FA-id 128 plane, from S1 to destination D, the primary path is S1-D, and the TI-LFA backup path is segment list {node(B), adjacency(B-D)}. Similarly, In FA-id 129 plane, from S2 to destination D, the primary path is S2-D, and the TI-LFA backup path is segment list {node(B), adjacency(B-D)}. The above TI-LFA path of FA-id 128 plane can be translated to {node- SID(B)@FA-id128, adjacency-SID(B-D)@FA-id128}, and TI-LFA path of FA- id 129 plane will be translated to {node-SID(B)@FA-id129, adjacency- SID(B-D)@FA-id129}. So that node B can distinguish the flows of FA-id 128 and FA-id 129 based on different adjacency-SID(B-D) and their related label forwarding entries, and take different treatments of them when they are forwarded to the same outgoing link B-D. 6. Deployment Considerations When multiple flex-algos are deployed in the network and they share the same link, multiple algorithm specific Adjacency-SIDs may need to be allocated on such a link, to distinguish the traffic of different algorithms and provide possible different treatment. Peng, et al. Expires 27 November 2023 [Page 12]
Internet-Draft algo-related adj-sid May 2023 Even if a link is only used by a single flex-algo, because the link always belongs to algorithm 0 by default, both the traditional Adjacency-SID (termd as adj-sid@algo-0) and the algorithm specific Adjacency-SID (termd as adj-sid@algo-x) may need to be allocated on that link, so that the potentional repair paths of the two Adjacency- SIDs can be distinguished. If the topology of multiple flex-algo planes, and physical topology, are isomorphic, that is, they contain the same nodes and same inter- connected links, but due to the differences between these FADs (such as different metric types), different repair paths will also be calculated on the same topology. Therefore, multiple algorithm specific Adjacency-SIDs may still need to be provided on the same link. It is not recommended to bind a link to algorithm 1 (Strict SPF) and allocate adj-sid@algo-1. Such Adjacency-SID is no useful. The operator may configure the policy on the node to turn off the algorithm specific processing capability for each algorithm, and the node will not allocate algorithm specific Adjacency-SIDs on the links those joined to the flex-algo plane, this is a local behavior. As mentioned before, the algorithm specific processing capability can be further subdivided into repair path per algorithm, statistics per algorithm, QoS policy per algorithm, etc. Assuming that a node wants to support the capability of repair path per algorithm, in this case, for an individual link, it is also controlled by the adjacency backup capability. When adjacency backup is disabled, it will let the capablitiy of repair path per algorithm be also invalid, so the link does not need to allocate algorithm specific Adjacency-SIDs. In any case, when instantiate a segment list (such as a TI-LFA path) within a specific flex-algo plane, for each Adjacency Segment of that list, if it has a corresponding algorithm specific Adjacency-SID, the algorithm specific Adjacency-SID MUST be used to construct SID list; if it has not, traditional Adjacency-SID can be used. 7. IANA Considerations 7.1. IANA ISIS Considerations This document makes the following registrations in the "Sub-TLVs for TLV 22, 23, 25, 141, 222, and 223" registry. Peng, et al. Expires 27 November 2023 [Page 13]
Internet-Draft algo-related adj-sid May 2023 +------+--------------------+----+----+----+-----+-----+-----+ | Type | Description | 22 | 23 | 25 | 141 | 222 | 223 | +======+====================+====+====+====+=====+=====+=====+ | | Adjacency-SID per | | | | | | | | TBA1 | Algorithm | y | y | n | y | y | y | +------+--------------------+----+----+----+-----+-----+-----+ | | LAN Adjacency-SID | | | | | | | | TBA2 | per Algorithm | y | y | n | y | y | y | +------+--------------------+----+----+----+-----+-----+-----+ 7.2. IANA OSPFv2 Considerations This document makes the following registrations in the OSPFv2 Extended Link TLV Sub-TLVs Registry. +-------+------------------------------------+---------------+ | Value | Description | Reference | +=======+====================================+===============+ | TBA3 | OSPFv2 Adjacency-SID | This document | | | per Algorithm Sub-TLV | | +-------+------------------------------------+---------------+ | TBA4 | OSPFv2 LAN Adjacency-SID | This document | | | per Algorithm Sub-TLV | | +-------+------------------------------------+---------------+ 7.3. IANA OSPFv3 Considerations This document makes the following registrations in the "OSPFv3 Extended-LSA Sub-TLVs" Registry. +-------+------------------------------------+---------------+ | Value | Description | Reference | +=======+====================================+===============+ | TBA5 | OSPFv3 Adjacency-SID | This document | | | per Algorithm Sub-TLV | | +-------+------------------------------------+---------------+ | TBA6 | OSPFv3 LAN Adjacency-SID | This document | | | per Algorithm Sub-TLV | | +-------+------------------------------------+---------------+ 8. Security Considerations There are no new security issues introduced by the extensions in this document. Refer to [RFC8665], [RFC8666], [RFC8667] for other security considerations. Peng, et al. Expires 27 November 2023 [Page 14]
Internet-Draft algo-related adj-sid May 2023 9. Acknowledgements We would like to thank Aijun Wang, Robert Raszuk, Gyan Mishra, Jie Dong and Xuesong Geng for their reviews and discussions to the content of this document. 10. Contributors The following people gave a substantial contribution to the content of this document. Les Ginsberg Cisco Systems, Inc. United States of America Email: ginsberg@cisco.com 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [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, November 2015, <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, May 2017, <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, April 2018, <https://www.rfc-editor.org/info/rfc8362>. [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>. [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/info/rfc8665>. Peng, et al. Expires 27 November 2023 [Page 15]
Internet-Draft algo-related adj-sid May 2023 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019, <https://www.rfc-editor.org/info/rfc8666>. [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>. [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, <https://www.rfc-editor.org/info/rfc9350>. Authors' Addresses Shaofu Peng ZTE Corporation China Email: peng.shaofu@zte.com.cn Ran Chen ZTE Corporation China Email: chen.ran@zte.com.cn Ketan Talaulikar Arrcus, Inc India Email: ketant.ietf@gmail.com Peter Psenak Cisco Systems Slovakia Email: ppsenak@cisco.com Peng, et al. Expires 27 November 2023 [Page 16]