draft-ietf-lsr-algorithm-related-adjacency-sid-01.txt   draft-ietf-lsr-algorithm-related-adjacency-sid-02.txt 
LSR Shaofu. Peng LSR Shaofu. Peng
Internet-Draft Ran. Chen Internet-Draft Ran. Chen
Intended status: Standards Track ZTE Corporation Intended status: Standards Track ZTE Corporation
Expires: April 14, 2022 Ketan. Talaulikar Expires: July 22, 2022 Ketan. Talaulikar
Peter. Psenak Peter. Psenak
Cisco Systems Cisco Systems
October 11, 2021 January 18, 2022
Algorithm Related IGP-Adjacency SID Advertisement Algorithm Related IGP-Adjacency SID Advertisement
draft-ietf-lsr-algorithm-related-adjacency-sid-01 draft-ietf-lsr-algorithm-related-adjacency-sid-02
Abstract Abstract
Segment Routing architecture supports the use of multiple routing Segment Routing architecture supports the use of multiple routing
algorithms, i.e, different constraint-based shortest-path algorithms, i.e., different constraint-based shortest-path
calculations can be supported. There are two standard algorithms: calculations can be supported. There are two standard algorithms:
SPF and Strict-SPF, defined in Segment Routing architecture. There SPF and Strict-SPF, defined in Segment Routing architecture. There
are also other user defined algorithms according to Flex-algo are also other user defined algorithms according to Flex-algo
applicaiton. However, an algorithm identifier is often included as applicaiton. However, an algorithm identifier is often included as
part of a Prefix-SID advertisement, that maybe not satisfy some part of a Prefix-SID advertisement, that maybe not satisfy some
scenarios where multiple algorithm share the same link resource. scenarios where multiple algorithm share the same link resource.
This document complement that the algorithm identifier can be also This document complement that the algorithm identifier can be also
included as part of a Adjacency-SID advertisement included as part of a Adjacency-SID advertisement
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2022. This Internet-Draft will expire on July 22, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 47 skipping to change at page 2, line 47
7.3. IANA OSPFv3 Considerations . . . . . . . . . . . . . . . 12 7.3. IANA OSPFv3 Considerations . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
11. Normative References . . . . . . . . . . . . . . . . . . . . 13 11. Normative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Segment Routing architecture [RFC8402] supports the use of multiple Segment Routing architecture [RFC8402] supports the use of multiple
routing algorithms, i.e, different constraint-based shortest-path routing algorithms, i.e., different constraint-based shortest-path
calculations can be supported. There are two standard algorithms, calculations can be supported. There are two standard algorithms,
i.e, SPF and Strict-SPF, that defined in Segment Routing i.e., SPF and Strict-SPF, that defined in Segment Routing
architecture. For SPF, the packet is forwarded along the well known architecture. For SPF, the packet is forwarded along the well known
ECMP-aware Shortest Path First (SPF) algorithm employed by the IGPs. ECMP-aware Shortest Path First (SPF) algorithm employed by the IGPs.
However, it is explicitly allowed for a midpoint to implement another However, it is explicitly allowed for a midpoint to implement another
forwarding based on local policy. For Strict Shortest Path First forwarding based on local policy. For Strict Shortest Path First
(Strict-SPF), it mandates that the packet be forwarded according to (Strict-SPF), it mandates that the packet be forwarded according to
the ECMP-aware SPF algorithm and instructs any router in the path to the ECMP-aware SPF algorithm and instructs any router in the path to
ignore any possible local policy overriding the SPF decision. ignore any possible local policy overriding the SPF decision.
There are also other user defined algorithms according to IGP Flex There are also other user defined algorithms according to IGP Flex
Algorithm [I-D.ietf-lsr-flex-algo]. IGP Flex Algorithm proposes a Algorithm [I-D.ietf-lsr-flex-algo]. IGP Flex Algorithm proposes a
skipping to change at page 3, line 26 skipping to change at page 3, line 26
calculation-type, (b) specify a metric-type, and (c )describe a set 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 of constraints on the topology, that are to be used to compute the
best paths along the constrained topology. A given combination of best paths along the constrained topology. A given combination of
calculation-type, metric-type, and constraints is known as an FAD calculation-type, metric-type, and constraints is known as an FAD
(Flexible Algorithm Definition). (Flexible Algorithm Definition).
However, an algorithm identifier is often included as part of a However, an algorithm identifier is often included as part of a
Prefix-SID advertisement, that maybe not satisfy some scenarios where Prefix-SID advertisement, that maybe not satisfy some scenarios where
multiple algorithm share the same link resource. This document multiple algorithm share the same link resource. This document
complement that the algorithm identifier can be also included as part complement that the algorithm identifier can be also included as part
of an Adjacency-SID advertisement for SR-MPLS. of an Adjacency-SID advertisement for SR-MPLS. Note that SRv6
already has this function.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Use-cases 3. Use-cases
skipping to change at page 5, line 5 skipping to change at page 5, line 5
Weight: 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 Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific treatment algorithm the router uses to apply algorithm specific treatment
configured on the adjacency. configured on the adjacency.
SID/Label/Index: Refer to Adjacency Segment Identifier (Adj-SID) sub- SID/Label/Index: Refer to Adjacency Segment Identifier (Adj-SID) sub-
TLV. TLV.
For a P2P link, an SR-capable router MAY allocate different Adj-SID For a P2P link, an SR-capable router MAY allocate different Adj-SIDs
for different algorithm, if this link joins different algorithm for different algorithms, if this link participates in the plane
related plane. related to different algorithms.
4.1.2. ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm 4.1.2. ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm
Sub-TLV Sub-TLV
ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm Sub-TLV ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm Sub-TLV
has the following format: has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 6 skipping to change at page 6, line 6
Weight: 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 Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific treatment algorithm the router uses to apply algorithm specific treatment
configured on the adjacency. configured on the adjacency.
SID/Label/Index: Refer to Adjacency Segment Identifier (LAN-Adj-SID) SID/Label/Index: Refer to Adjacency Segment Identifier (LAN-Adj-SID)
Sub-TLV. Sub-TLV.
For a broadcast link, an SR-capable router MAY allocate different For a broadcast link, an SR-capable router MAY allocate different
Adj-SID for different algorithm, if this link joins different Adj-SIDs for different algorithms, if this link participates in the
algorithm related plane. plane related to different algorithms.
4.2. OSPFv2 Adjacency Segment Identifier per Algorithm 4.2. OSPFv2 Adjacency Segment Identifier per Algorithm
[RFC8665] describes the OSPFv2 extensions that need to be introduced [RFC8665] describes the OSPFv2 extensions that need to be introduced
for Segment Routing operating on an MPLS data plane. It defined Adj- 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 SID Sub-TLV and LAN Adj-SID Sub-TLV advertised with Extended Link TLV
defined in [RFC7684]. Accordingly, this document defines two new defined in [RFC7684]. Accordingly, this document defines two new
optional Sub-TLVs, "OSPFv2 Adj-SID per Algorithm Sub-TLV" and "OSPFv2 optional Sub-TLVs, "OSPFv2 Adj-SID per Algorithm Sub-TLV" and "OSPFv2
LAN Adj-SID per Algorithm Sub-TLV". LAN Adj-SID per Algorithm Sub-TLV".
skipping to change at page 7, line 5 skipping to change at page 7, line 5
Algorithm: The Algorithm field contains the identifier of the Algorithm: The Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific treatment algorithm the router uses to apply algorithm specific treatment
configured on the adjacency. configured on the adjacency.
MT-ID: Refer to OSPFv2 Adj-SID Sub-TLV. MT-ID: Refer to OSPFv2 Adj-SID Sub-TLV.
Weight: 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. SID/Index/Label: Refer to OSPFv2 Adj-SID Sub-TLV.
For a P2P link, an SR-capable router MAY allocate different Adj-SID For a P2P link, an SR-capable router MAY allocate different Adj-SIDs
for different algorithm, if this link joins different algorithm for different algorithms, if this link participates in the plane
related plane. related to different algorithms.
4.2.2. OSPFv2 LAN Adj-SID per Algorithm Sub-TLV 4.2.2. OSPFv2 LAN Adj-SID per Algorithm Sub-TLV
OSPFv2 LAN Adj-SID per Algorithm Sub-TLV has the following format: OSPFv2 LAN Adj-SID per Algorithm Sub-TLV has the following format:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 48 skipping to change at page 7, line 48
MT-ID: Refer to OSPFv2 LAN Adj-SID Sub-TLV. MT-ID: Refer to OSPFv2 LAN Adj-SID Sub-TLV.
Weight: 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. Neighbor ID: Refer to OSPFv2 LAN Adj-SID Sub-TLV.
SID/Index/Label: 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 For a broadcast link, an SR-capable router MAY allocate different
Adj-SID for different algorithm, if this link joins different Adj-SIDs for different algorithms, if this link participates in the
algorithm related plane. plane related to different algorithms.
4.3. OSPFv3 Adjacency Segment Identifier per Algorithm 4.3. OSPFv3 Adjacency Segment Identifier per Algorithm
[RFC8666] describes the OSPFv3 extensions that need to be introduced [RFC8666] describes the OSPFv3 extensions that need to be introduced
for Segment Routing operating on an MPLS data plane. It defined Adj- 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 SID Sub-TLV and LAN Adj-SID Sub-TLV advertised with Router-Link TLV
as defined in [RFC8362]. Accordingly, this document defines two new as defined in [RFC8362]. Accordingly, this document defines two new
optional Sub-TLVs, "OSPFv3 Adj-SID per Algorithm Sub-TLV" and "OSPFv3 optional Sub-TLVs, "OSPFv3 Adj-SID per Algorithm Sub-TLV" and "OSPFv3
LAN Adj-SID per Algorithm Sub-TLV". LAN Adj-SID per Algorithm Sub-TLV".
skipping to change at page 8, line 49 skipping to change at page 8, line 49
Algorithm: The Algorithm field contains the identifier of the Algorithm: The Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific treatment algorithm the router uses to apply algorithm specific treatment
configured on the adjacency. configured on the adjacency.
Reserved: SHOULD be set to 0 on transmission and MUST be ignored on Reserved: SHOULD be set to 0 on transmission and MUST be ignored on
reception. reception.
SID/Index/Label: Refer to OSPFv3 Adj-SID Sub-TLV. SID/Index/Label: Refer to OSPFv3 Adj-SID Sub-TLV.
For a P2P link, an SR-capable router MAY allocate different Adj-SID For a P2P link, an SR-capable router MAY allocate different Adj-SIDs
for different algorithm, if this link joins different algorithm for different algorithms, if this link participates in the plane
related plane. related to different algorithms.
4.3.2. OSPFv3 LAN Adj-SID per Algorithm Sub-TLV 4.3.2. OSPFv3 LAN Adj-SID per Algorithm Sub-TLV
OSPFv3 LAN Adj-SID per Algorithm Sub-TLV has the following format: OSPFv3 LAN Adj-SID per Algorithm Sub-TLV has the following format:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 45 skipping to change at page 9, line 45
configured on the adjacency. configured on the adjacency.
Reserved: SHOULD be set to 0 on transmission and MUST be ignored on Reserved: SHOULD be set to 0 on transmission and MUST be ignored on
reception. reception.
Neighbor ID: Refer to OSPFv3 LAN Adj-SID Sub-TLV. Neighbor ID: Refer to OSPFv3 LAN Adj-SID Sub-TLV.
SID/Index/Label: 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 For a broadcast link, an SR-capable router MAY allocate different
Adj-SID for different algorithm, if this link joins different Adj-SIDs for different algorithms, if this link participates in the
algorithm related plane. plane related to different algorithms.
5. Operations 5. Operations
The method introduced in this document enables the traffic of The method introduced in this document enables the traffic of
different flex-algo plane to be distinguished on the same link, so different flex-algo plane to be distinguished on the same link, so
that these traffic can be applied with different local treatment that these traffic can be applied with different local treatment
(such as providing different repair path, traffic statistics, etc) (such as providing different repair path, traffic statistics, etc)
per algorithm. per algorithm.
Depending on the implementation, operators can configure multiple Depending on the implementation, operators can configure multiple
Adacency-SIDs each for different algorithm on the same link. One of Adacency-SIDs each for different algorithm on the same link. One of
the difficulties is that during this configuration phase it is not the difficulties is that during this configuration phase it is not
straightforward for a link to be included in an Flex-algo plane, as 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 this can only be determined after all nodes in the network have
negotiated the FAD. A simple way is that as long as an IGP instance negotiated the FAD. A simple way is that as long as an IGP instance
enable an algorithm for a level/area, all links joined to that level/ enable an algorithm for a level/area, all links joined to that level/
area should allocate Adjacency-SIDs for that algorithm statically, area should allocate Adjacency-SIDs for that algorithm statically,
however, this will waste SID resources. Another way is RECOMMENDED however, this will waste SID resources.
to allocate and withdraw Adjacency-SID per algorithm dynamically
according to the result of FAD negotiation, i.e., Adjacency-SID per It is RECOMMENDEDED to allocate and withdraw Adjacency-SID per
algorithm is assigned only to those links that have joined the Flex- algorithm dynamically according to the result of FAD negotiation,
algo plane. i.e., Adjacency-SID per algorithm is assigned only to those links
that have joined the Flex-algo plane.
The following figure shows an example of Adjacency-SID per algorithm. The following figure shows an example of Adjacency-SID per algorithm.
[S1]--------[D]--------[S2] [S1]--------[D]--------[S2]
| | | | | |
| | | | | |
| | | | | |
[A]---------[B]--------[C] [A]---------[B]--------[C]
Figure 7: Flex-algo LFA Path with Adjacency-SID per Algorithm Figure 7: Flex-algo LFA Path with Adjacency-SID per Algorithm
skipping to change at page 10, line 45 skipping to change at page 10, line 46
default metric type for path calculation. In FA-id 128 plane, from 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 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 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 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 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- 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- SID(B)@FA-id128, adjacency-SID(B-D)@FA-id128}, and TI-LFA path of FA-
id 129 plane will be translate to {node-SID(B)@FA-id129, adjacency- id 129 plane will be translate to {node-SID(B)@FA-id129, adjacency-
SID(B-D)@FA-id129}. So that node B can distinguish the flow of FA-id SID(B-D)@FA-id129}. So that node B can distinguish the flow of FA-id
128 and FA-id 129 based on different adjacency-SID(B-D), and take 128 and FA-id 129 based on different adjacency-SID(B-D), and take
different treatment of them when they are send to the same outgoing different treatments of them when they are send to the same outgoing
link B-D. link B-D.
6. Deployment Considerations 6. Deployment Considerations
When multiple flex-algos are deployed in the network and they share When multiple flex-algos are deployed in the network and they share
the same link, multiple algorithm specific Adjacency-SIDs may need to the same link, multiple algorithm specific Adjacency-SIDs may need to
be allocated on such a link, to distinguish the traffic of different be allocated on such a link, to distinguish the traffic of different
algorithms and provide possible different treatment. algorithms and provide possible different treatment.
Even if a link is only used by a single flex-algo, because the link Even if a link is only used by a single flex-algo, because the link
skipping to change at page 11, line 35 skipping to change at page 11, line 35
link. link.
It is not recommended to bind a link to algorithm 1 (Strict SPF) and 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. allocate adj-sid@algo-1. Such Adjacency-SID is no useful.
The operator may configure the policy on the node to turn off the The operator may configure the policy on the node to turn off the
algorithm specific processing capability for each algorithm, and the algorithm specific processing capability for each algorithm, and the
node will not allocate algorithm specific Adjacency-SIDs on the links node will not allocate algorithm specific Adjacency-SIDs on the links
those joined to the flex-algo plane, this is a local behavior. As those joined to the flex-algo plane, this is a local behavior. As
mentioned before, the algorithm specific processing capability can be mentioned before, the algorithm specific processing capability can be
further subdivided into repair path per algo, statistics per algo, further subdivided into repair path per algorithm, statistics per
etc. Assuming that a node only wants to support the capability of algorithm, etc. Assuming that a node only wants to support the
repair path per algo, in this case, for an individual link, it is capability of repair path per algorithm, in this case, for an
also controlled by the adjacency backup capability. When adjacency individual link, it is also controlled by the adjacency backup
backup is disabled, it will let the capablitiy of repair path per capability. When adjacency backup is disabled, it will let the
algo be also invalid, so the link does not need to allocate algorithm capablitiy of repair path per algorithm be also invalid, so the link
specific Adjacency-SIDs. does not need to allocate algorithm specific Adjacency-SIDs.
In any case, when instantiate a segment list (such as a TI-LFA path) 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 within a specific flex-algo plane, for each Adjacency Segment of that
list, if it has a corresponding algorithm specific Adjacency-SID, the list, if it has a corresponding algorithm specific Adjacency-SID, the
algorithm specific Adjacency-SID MUST be used to construct SID list; algorithm specific Adjacency-SID MUST be used to construct SID list;
if it has not, traditional Adjacency-SID can be used. if it has not, traditional Adjacency-SID can be used.
7. IANA Considerations 7. IANA Considerations
7.1. IANA ISIS Considerations 7.1. IANA ISIS Considerations
skipping to change at page 13, line 32 skipping to change at page 13, line 32
Les Ginsberg Les Ginsberg
Cisco Systems, Inc. Cisco Systems, Inc.
United States of America United States of America
Email: ginsberg@cisco.com Email: ginsberg@cisco.com
11. Normative References 11. Normative References
[I-D.ietf-lsr-flex-algo] [I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-17 (work in progress), July 2021. algo-18 (work in progress), October 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>. 2015, <https://www.rfc-editor.org/info/rfc7684>.
skipping to change at page 14, line 44 skipping to change at page 14, line 44
Ran Chen Ran Chen
ZTE Corporation ZTE Corporation
China China
Email: chen.ran@zte.com.cn Email: chen.ran@zte.com.cn
Ketan Talaulikar Ketan Talaulikar
Cisco Systems Cisco Systems
India India
Email: ketant@cisco.com Email: ketant.ietf@gmail.com
Peter Psenak Peter Psenak
Cisco Systems Cisco Systems
Slovakia Slovakia
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
 End of changes. 20 change blocks. 
39 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/