draft-ietf-lsr-flex-algo-07.txt   draft-ietf-lsr-flex-algo-08.txt 
Network Working Group P. Psenak, Ed. Network Working Group P. Psenak, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track S. Hegde Intended status: Standards Track S. Hegde
Expires: October 3, 2020 Juniper Networks, Inc. Expires: January 11, 2021 Juniper Networks, Inc.
C. Filsfils C. Filsfils
K. Talaulikar K. Talaulikar
Cisco Systems, Inc. Cisco Systems, Inc.
A. Gulko A. Gulko
Thomson Reuters Refinitiv
April 1, 2020 July 10, 2020
IGP Flexible Algorithm IGP Flexible Algorithm
draft-ietf-lsr-flex-algo-07.txt draft-ietf-lsr-flex-algo-08.txt
Abstract Abstract
IGP protocols traditionally compute best paths over the network based IGP protocols traditionally compute best paths over the network based
on the IGP metric assigned to the links. Many network deployments on the IGP metric assigned to the links. Many network deployments
use RSVP-TE based or Segment Routing based Traffic Engineering to use RSVP-TE based or Segment Routing based Traffic Engineering to
enforce traffic over a path that is computed using different metrics enforce traffic over a path that is computed using different metrics
or constraints than the shortest IGP path. This document proposes a or constraints than the shortest IGP path. This document proposes a
solution that allows IGPs themselves to compute constraint based solution that allows IGPs themselves to compute constraint based
paths over the network. This document also specifies a way of using paths over the network. This document also specifies a way of using
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 October 3, 2020. This Internet-Draft will expire on January 11, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Flexible Algorithm . . . . . . . . . . . . . . . . . . . . . 5 4. Flexible Algorithm . . . . . . . . . . . . . . . . . . . . . 5
5. Flexible Algorithm Definition Advertisement . . . . . . . . . 5 5. Flexible Algorithm Definition Advertisement . . . . . . . . . 6
5.1. ISIS Flexible Algorithm Definition Sub-TLV . . . . . . . 6 5.1. ISIS Flexible Algorithm Definition Sub-TLV . . . . . . . 6
5.2. OSPF Flexible Algorithm Definition TLV . . . . . . . . . 7 5.2. OSPF Flexible Algorithm Definition TLV . . . . . . . . . 7
5.3. Common Handling of Flexible Algorithm Definition TLV . . 9 5.3. Common Handling of Flexible Algorithm Definition TLV . . 9
6. Sub-TLVs of ISIS FAD Sub-TLV . . . . . . . . . . . . . . . . 10 6. Sub-TLVs of ISIS FAD Sub-TLV . . . . . . . . . . . . . . . . 10
6.1. ISIS Flexible Algorithm Exclude Admin Group Sub-TLV . . . 10 6.1. ISIS Flexible Algorithm Exclude Admin Group Sub-TLV . . . 10
6.2. ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV . 11 6.2. ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV . 11
6.3. ISIS Flexible Algorithm Include-All Admin Group Sub-TLV . 11 6.3. ISIS Flexible Algorithm Include-All Admin Group Sub-TLV . 11
6.4. ISIS Flexible Algorithm Definition Flags Sub-TLV . . . . 11 6.4. ISIS Flexible Algorithm Definition Flags Sub-TLV . . . . 11
6.5. ISIS Flexible Algorithm Exclude SRLG Sub-TLV . . . . . . 12 6.5. ISIS Flexible Algorithm Exclude SRLG Sub-TLV . . . . . . 12
7. Sub-TLVs of OSPF FAD TLV . . . . . . . . . . . . . . . . . . 13 7. Sub-TLVs of OSPF FAD TLV . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 6 skipping to change at page 3, line 6
10.1. Advertisement of Node Participation for Segment Routing 18 10.1. Advertisement of Node Participation for Segment Routing 18
10.2. Advertisement of Node Participation for Other 10.2. Advertisement of Node Participation for Other
Applications . . . . . . . . . . . . . . . . . . . . . . 19 Applications . . . . . . . . . . . . . . . . . . . . . . 19
11. Advertisement of Link Attributes for Flex-Algorithm . . . . . 19 11. Advertisement of Link Attributes for Flex-Algorithm . . . . . 19
12. Calculation of Flexible Algorithm Paths . . . . . . . . . . . 20 12. Calculation of Flexible Algorithm Paths . . . . . . . . . . . 20
12.1. Multi-area and Multi-domain Considerations . . . . . . . 21 12.1. Multi-area and Multi-domain Considerations . . . . . . . 21
13. Flex-Algorithm and Forwarding Plane . . . . . . . . . . . . . 22 13. Flex-Algorithm and Forwarding Plane . . . . . . . . . . . . . 22
13.1. Segment Routing MPLS Forwarding for Flex-Algorithm . . . 22 13.1. Segment Routing MPLS Forwarding for Flex-Algorithm . . . 22
13.2. SRv6 Forwarding for Flex-Algorithm . . . . . . . . . . . 23 13.2. SRv6 Forwarding for Flex-Algorithm . . . . . . . . . . . 23
13.3. Other Applications' Forwarding for Flex-Algorithm . . . 24 13.3. Other Applications' Forwarding for Flex-Algorithm . . . 24
14. Backward Compatibility . . . . . . . . . . . . . . . . . . . 24 14. Operational considerations . . . . . . . . . . . . . . . . . 24
15. Security Considerations . . . . . . . . . . . . . . . . . . . 24 14.1. Inter-area Considerations . . . . . . . . . . . . . . . 24
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 14.2. Usage of SRLG Exclude Rule with Flex-Algorithm . . . . . 25
16.1. IGP IANA Considerations . . . . . . . . . . . . . . . . 25 14.3. Max-metric consideration . . . . . . . . . . . . . . . . 26
16.1.1. IGP Algorithm Types Registry . . . . . . . . . . . . 25 15. Backward Compatibility . . . . . . . . . . . . . . . . . . . 26
16.1.2. Flexible Algorithm Definition Metric-Type Registry . 25 16. Security Considerations . . . . . . . . . . . . . . . . . . . 26
16.2. Flex-Algorithm Definition Flags Registry . . . . . . . . 26 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
16.3. ISIS IANA Considerations . . . . . . . . . . . . . . . . 26 17.1. IGP IANA Considerations . . . . . . . . . . . . . . . . 27
16.3.1. Sub TLVs for Type 242 . . . . . . . . . . . . . . . 26 17.1.1. IGP Algorithm Types Registry . . . . . . . . . . . . 27
16.3.2. Sub TLVs for for TLVs 135, 235, 236, and 237 . . . . 26 17.1.2. IGP Metric-Type Registry . . . . . . . . . . . . . . 27
16.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub- 17.2. Flex-Algorithm Definition Flags Registry . . . . . . . . 27
TLV . . . . . . . . . . . . . . . . . . . . . . . . 26 17.3. ISIS IANA Considerations . . . . . . . . . . . . . . . . 28
16.4. OSPF IANA Considerations . . . . . . . . . . . . . . . . 27 17.3.1. Sub TLVs for Type 242 . . . . . . . . . . . . . . . 28
16.4.1. OSPF Router Information (RI) TLVs Registry . . . . . 27 17.3.2. Sub TLVs for for TLVs 135, 235, 236, and 237 . . . . 28
16.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs . . . . . . . . 28 17.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-
16.4.3. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . 28 TLV . . . . . . . . . . . . . . . . . . . . . . . . 28
16.4.4. OSPF Flexible Algorithm Definition TLV Sub-TLV 17.4. OSPF IANA Considerations . . . . . . . . . . . . . . . . 29
Registry . . . . . . . . . . . . . . . . . . . . . . 28 17.4.1. OSPF Router Information (RI) TLVs Registry . . . . . 29
16.4.5. Link Attribute Applications Registry . . . . . . . . 29 17.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs . . . . . . . . 30
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 17.4.3. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . 30
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 17.4.4. OSPF Flexible Algorithm Definition TLV Sub-TLV
18.1. Normative References . . . . . . . . . . . . . . . . . . 30 Registry . . . . . . . . . . . . . . . . . . . . . . 30
18.2. Informative References . . . . . . . . . . . . . . . . . 32 17.4.5. Link Attribute Applications Registry . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
19.1. Normative References . . . . . . . . . . . . . . . . . . 32
19.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
An IGP computed path based on the shortest IGP metric must often be An IGP computed path based on the shortest IGP metric must often be
replaced by a traffic engineered path due to the traffic requirements replaced by a traffic engineered path due to the traffic requirements
which are not reflected by the IGP metric. Some networks engineer which are not reflected by the IGP metric. Some networks engineer
the IGP metric assignments in a way that the IGP Metric reflects the the IGP metric assignments in a way that the IGP Metric reflects the
link bandwidth or delay. If, for example, the IGP metric is link bandwidth or delay. If, for example, the IGP metric is
reflecting the bandwidth on the link and the application traffic is reflecting the bandwidth on the link and the application traffic is
delay sensitive, the best IGP path may not reflect the best path from delay sensitive, the best IGP path may not reflect the best path from
skipping to change at page 21, line 8 skipping to change at page 21, line 8
definition. If such exclude rule exists, check if any color that definition. If such exclude rule exists, check if any color that
is part of the exclude rule is also set on the link. If such a is part of the exclude rule is also set on the link. If such a
color is set, the link MUST be pruned from the computation. color is set, the link MUST be pruned from the computation.
2. Check if any exclude SRLG rule is part of the Flex-Algorithm 2. Check if any exclude SRLG rule is part of the Flex-Algorithm
definition. If such exclude rule exists, check if the link is definition. If such exclude rule exists, check if the link is
part of any SRLG that is also part of the SRLG exclude rule. If part of any SRLG that is also part of the SRLG exclude rule. If
the link is part of such SRLG, the link MUST be pruned from the the link is part of such SRLG, the link MUST be pruned from the
computation. computation.
4. Check if any include-any rule is part of the Flex-Algorithm 3. Check if any include-any rule is part of the Flex-Algorithm
definition. If such include-any rule exists, check if any color definition. If such include-any rule exists, check if any color
that is part of the include-any rule is also set on the link. If that is part of the include-any rule is also set on the link. If
no such color is set, the link MUST be pruned from the no such color is set, the link MUST be pruned from the
computation. computation.
4. Check if any include-all rule is part of the Flex-Algorithm 4. Check if any include-all rule is part of the Flex-Algorithm
definition. If such include-all rule exists, check if all colors definition. If such include-all rule exists, check if all colors
that are part of the include-all rule are also set on the link. that are part of the include-all rule are also set on the link.
If all such colors are not set on the link, the link MUST be If all such colors are not set on the link, the link MUST be
pruned from the computation. pruned from the computation.
skipping to change at page 24, line 38 skipping to change at page 24, line 38
13.3. Other Applications' Forwarding for Flex-Algorithm 13.3. Other Applications' Forwarding for Flex-Algorithm
Any application that wants to use Flex-Algorithm specific forwarding Any application that wants to use Flex-Algorithm specific forwarding
needs to install some form of Flex-Algorithm specific forwarding needs to install some form of Flex-Algorithm specific forwarding
entries. entries.
Application specific forwarding for Flex-Algorithm MUST be defined Application specific forwarding for Flex-Algorithm MUST be defined
for each application and is outside of the scope of this document. for each application and is outside of the scope of this document.
14. Backward Compatibility 14. Operational considerations
14.1. Inter-area Considerations
The scope of the FA computation is an area, so is the scope of the
FAD. In ISIS the Router Capability TLV in which the FAD Sub-TLV is
present MUST have the S-bit clear, which prevents it to be flooded
outside of level in which it was originated. Even though in OSPF the
FAD Sub-TLV can be flooded in the RI LSA that has AS flooding scope,
the FAD selection is performed for individual area in which it is
being used.
There is no requirement for FAD for a particular Flex-Algorithm to be
identical in all areas in the network. For example, traffic for the
same Flex-Algorithm may be optimized for minimal delay (e.g., using
delay metric) in one area or level, while being optimized for
available bandwidth (e.g., using IGP metric) in the other area or
level.
As described in Section 5.1, ISIS allows the re-generation of the
winning FAD from level 2, without any modification to it, into a
level 1 area. This allows the operator to configure the FAD in one
or multiple routers in the level 2, without the need to repeat the
same task in each level 1 area, if the intent is to have the same FAD
for the particular Flex-Algorithm across all levels. Similar can be
achieved in OSPF by using the AS flooding scope of the RI LSA in
which the FAD Sub-TLV for the particular Flex-Algoritm is advertised.
Re-generation of FAD from level 1 area to level 2 area is not
supported in ISIS, so if the intent is to regenerate the FAD between
ISIS levels, the FAD MUST be defined on router(s) that are in level
2. In OSPF the FAD definition can be done in any area and be
propagated to all router in AS by the AS flooding scope of the RI
LSA.
14.2. Usage of SRLG Exclude Rule with Flex-Algorithm
There are two different ways in which SRLG information can be used
with Flex-Algorithm:
In a context of a single Flex-Algorithm, it can be used for
computation of backup paths, as described in
[I-D.ietf-rtgwg-segment-routing-ti-lfa]. This usage does not
require association of any specific SRLG constraint with the given
Flex-Algorithm definition.
In the context of multiple Flex-Algorithms, it can be used for
creating disjoint sets of paths by pruning the links belonging to
a specific SRLG from the topology on which a specific Flex-
Algorithm computes its paths. This usage:
Facilitates the usage of already deployed SRLG configurations
for setup of disjoint paths between two or more Flex-
Algorithms.
Requires explicit association of a given Flex-Algorithm with a
specific set of SRLG constraints as defined in Section 6.5 and
Section 7.5.
The two usages mentioned above are orthogonal.
14.3. Max-metric consideration
Both ISIS and OSPF have a mechanism to set the IGP metric on a link
to a value that would make the link either non-reachable or to serve
as the link of last resort. Similar functionality would be needed
for the Min Unidirectional Link Delay and TE metric, as these can be
used to compute Flex-Algorithm paths.
The link can be made un-reachable for all Flex-Algorithms that use
Min Unidirectional Link Delay as metric, as described in Section 5.1,
by removing the Flex-Algorithm ASLA Min Unidirectional Link Delay
advertisement for the link. The link can be made the link of last
resort by setting the delay value in the Flex-Algorithm ASLA delay
advertisement for the link to the value of 16,777,215 (2^24 - 1).
The link can be made un-reachable for all Flex-Algorithms that use TE
metric, as described in Section 5.1, by removing the Flex-Algorithm
ASLA TE metric advertisement for the link. The link can be made the
link of last resort by setting the TE metric value in the Flex-
Algorithm ASLA delay advertisement for the link to the value of (2^24
- 1) in ISIS and (2^32 - 1) in OSPF.
15. Backward Compatibility
This extension brings no new backward compatibility issues. This extension brings no new backward compatibility issues.
15. Security Considerations 16. Security Considerations
This draft adds two new ways to disrupt the IGP networks: This draft adds two new ways to disrupt the IGP networks:
An attacker can hijack a particular Flex-Algorithm by advertising An attacker can hijack a particular Flex-Algorithm by advertising
a FAD with a priority of 255 (or any priority higher than that of a FAD with a priority of 255 (or any priority higher than that of
the legitimate nodes). the legitimate nodes).
An attacker could make it look like a router supports a particular An attacker could make it look like a router supports a particular
Flex-Algorithm when it actually doesn't, or vice versa. Flex-Algorithm when it actually doesn't, or vice versa.
Both of these attacks can be addressed by the existing security Both of these attacks can be addressed by the existing security
extensions as described in [RFC5304] and [RFC5310] for ISIS, in extensions as described in [RFC5304] and [RFC5310] for ISIS, in
[RFC2328] and [RFC7474] for OSPFv2 and in [RFC5340] and [RFC4552] for [RFC2328] and [RFC7474] for OSPFv2 and in [RFC5340] and [RFC4552] for
OSPFv3. OSPFv3.
16. IANA Considerations 17. IANA Considerations
17.1. IGP IANA Considerations
16.1. IGP IANA Considerations
16.1.1. IGP Algorithm Types Registry 17.1.1. IGP Algorithm Types Registry
This document makes the following registrations in the "IGP Algorithm This document makes the following registrations in the "IGP Algorithm
Types" registry: Types" registry:
Type: 128-255. Type: 128-255.
Description: Flexible Algorithms. Description: Flexible Algorithms.
Reference: This document (Section 4). Reference: This document (Section 4).
16.1.2. Flexible Algorithm Definition Metric-Type Registry 17.1.2. IGP Metric-Type Registry
IANA is requested to set up a registry called "Flexible Algorithm IANA is requested to set up a registry called "IGP Metric-Type
Definition Metric-Type Registry" under a "Interior Gateway Protocol Registry" under a "Interior Gateway Protocol (IGP) Parameters" IANA
(IGP) Parameters" IANA registries. The registration policy for this registries. The registration policy for this registry is "Standards
registry is "Standards Action" ([RFC8126] and [RFC7120]). Action" ([RFC8126] and [RFC7120]).
Values in this registry come from the range 0-255. Values in this registry come from the range 0-255.
This document registers following values in the "Flexible Algorithm This document registers following values in the "IGP Metric-Type
Definition Metric-Type Registry": Registry":
Type: 0 Type: 0
Description: IGP metric Description: IGP metric
Reference: This document (Section 5.1) Reference: This document (Section 5.1)
Type: 1 Type: 1
Description: Min Unidirectional Link Delay [RFC7810] Description: Min Unidirectional Link Delay [RFC7810]
skipping to change at page 26, line 4 skipping to change at page 27, line 44
Type: 1 Type: 1
Description: Min Unidirectional Link Delay [RFC7810] Description: Min Unidirectional Link Delay [RFC7810]
Reference: This document (Section 5.1) Reference: This document (Section 5.1)
Type: 2 Type: 2
Description: TE Default Metric [RFC5305] Description: TE Default Metric [RFC5305]
Reference: This document (Section 5.1) Reference: This document (Section 5.1)
16.2. Flex-Algorithm Definition Flags Registry 17.2. Flex-Algorithm Definition Flags Registry
IANA is requested to set up a registry called "ISIS Flex-Algorithm IANA is requested to set up a registry called "ISIS Flex-Algorithm
Definition Flags Registry" under a "Interior Gateway Protocol (IGP) Definition Flags Registry" under a "Interior Gateway Protocol (IGP)
Parameters" IANA registries. The registration policy for this Parameters" IANA registries. The registration policy for this
registry is "Standards Action" ([RFC8126] and [RFC7120]). registry is "Standards Action" ([RFC8126] and [RFC7120]).
This document defines the following single bit in Flex-Algorithm This document defines the following single bit in Flex-Algorithm
Definition Flags registry: Definition Flags registry:
Bit # Name Bit # Name
----- ------------------------------ ----- ------------------------------
0 Prefix Metric Flag (M-flag) 0 Prefix Metric Flag (M-flag)
Reference: This document (Section 6.4, Section 7.4). Reference: This document (Section 6.4, Section 7.4).
16.3. ISIS IANA Considerations 17.3. ISIS IANA Considerations
16.3.1. Sub TLVs for Type 242 17.3.1. Sub TLVs for Type 242
This document makes the following registrations in the "sub-TLVs for This document makes the following registrations in the "sub-TLVs for
TLV 242" registry. TLV 242" registry.
Type: 26. Type: 26.
Description: Flexible Algorithm Definition. Description: Flexible Algorithm Definition.
Reference: This document (Section 5.1). Reference: This document (Section 5.1).
16.3.2. Sub TLVs for for TLVs 135, 235, 236, and 237 17.3.2. Sub TLVs for for TLVs 135, 235, 236, and 237
This document makes the following registrations in the "Sub-TLVs for This document makes the following registrations in the "Sub-TLVs for
for TLVs 135, 235, 236, and 237" registry. for TLVs 135, 235, 236, and 237" registry.
Type: 6 Type: 6
Description: Flex-Algorithm Prefix Metric. Description: Flex-Algorithm Prefix Metric.
Reference: This document (Section 8). Reference: This document (Section 8).
16.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV 17.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV
This document creates the following Sub-Sub-TLV Registry: This document creates the following Sub-Sub-TLV Registry:
Registry: Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV Registry: Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV
Registration Procedure: Expert review Registration Procedure: Expert review
Reference: This document (Section 5.1) Reference: This document (Section 5.1)
This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs
for Flexible Algorithm Definition Sub-TLV" registry: for Flexible Algorithm Definition Sub-TLV" registry:
Type: 1 Type: 1
Description: Flexible Algorithm Exclude Admin Group Description: Flexible Algorithm Exclude Admin Group
skipping to change at page 27, line 41 skipping to change at page 29, line 38
Description: Flexible Algorithm Definition Flags Description: Flexible Algorithm Definition Flags
Reference: This document (Section 6.4). Reference: This document (Section 6.4).
Type: 5 Type: 5
Description: Flexible Algorithm Exclude SRLG Description: Flexible Algorithm Exclude SRLG
Reference: This document (Section 6.5). Reference: This document (Section 6.5).
16.4. OSPF IANA Considerations 17.4. OSPF IANA Considerations
16.4.1. OSPF Router Information (RI) TLVs Registry 17.4.1. OSPF Router Information (RI) TLVs Registry
This specification updates the OSPF Router Information (RI) TLVs This specification updates the OSPF Router Information (RI) TLVs
Registry. Registry.
Type: 16 Type: 16
Description: Flexible Algorithm Definition TLV. Description: Flexible Algorithm Definition TLV.
Reference: This document (Section 5.2). Reference: This document (Section 5.2).
16.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs 17.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs
This document makes the following registrations in the "OSPFv2 This document makes the following registrations in the "OSPFv2
Extended Prefix TLV Sub-TLVs" registry. Extended Prefix TLV Sub-TLVs" registry.
Type: 3 Type: 3
Description: Flex-Algorithm Prefix Metric. Description: Flex-Algorithm Prefix Metric.
Reference: This document (Section 9). Reference: This document (Section 9).
16.4.3. OSPFv3 Extended-LSA Sub-TLVs 17.4.3. OSPFv3 Extended-LSA Sub-TLVs
This document makes the following registrations in the "OSPFv3 This document makes the following registrations in the "OSPFv3
Extended-LSA Sub-TLVs" registry. Extended-LSA Sub-TLVs" registry.
Type: 26 Type: 26
Description: Flex-Algorithm Prefix Metric. Description: Flex-Algorithm Prefix Metric.
Reference: This document (Section 9). Reference: This document (Section 9).
16.4.4. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry 17.4.4. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry
This document creates the following registry: This document creates the following registry:
Registry: OSPF Flexible Algorithm Definition TLV sub-TLV Registry: OSPF Flexible Algorithm Definition TLV sub-TLV
Registration Procedure: Expert review Registration Procedure: Expert review
Reference: This document (Section 5.2) Reference: This document (Section 5.2)
The "OSPF Flexible Algorithm Definition TLV sub-TLV" registry will The "OSPF Flexible Algorithm Definition TLV sub-TLV" registry will
skipping to change at page 29, line 37 skipping to change at page 31, line 34
Reference: This document (Section 7.5). Reference: This document (Section 7.5).
Types in the range 32768-33023 are for experimental use; these will Types in the range 32768-33023 are for experimental use; these will
not be registered with IANA, and MUST NOT be mentioned by RFCs. not be registered with IANA, and MUST NOT be mentioned by RFCs.
Types in the range 33024-65535 are not to be assigned at this time. Types in the range 33024-65535 are not to be assigned at this time.
Before any assignments can be made in the 33024-65535 range, there Before any assignments can be made in the 33024-65535 range, there
MUST be an IETF specification that specifies IANA Considerations that MUST be an IETF specification that specifies IANA Considerations that
covers the range being assigned. covers the range being assigned.
16.4.5. Link Attribute Applications Registry 17.4.5. Link Attribute Applications Registry
This document registers following bit in the Link Attribute This document registers following bit in the Link Attribute
Applications registry: Applications Registry:
Bit-3 Bit-3
Description: Flexible Algorithm (X-bit) Description: Flexible Algorithm (X-bit)
Reference: This document (Section 11). Reference: This document (Section 11).
17. Acknowledgements 18. Acknowledgements
This draft, among other things, is also addressing the problem that This draft, among other things, is also addressing the problem that
the [I-D.gulkohegde-routing-planes-using-sr] was trying to solve. the [I-D.gulkohegde-routing-planes-using-sr] was trying to solve.
All authors of that draft agreed to join this draft. All authors of that draft agreed to join this draft.
Thanks to Eric Rosen, Tony Przygienda for their detailed review and Thanks to Eric Rosen, Tony Przygienda for their detailed review and
excellent comments. excellent comments.
Thanks to Cengiz Halit for his review and feedback during initial Thanks to Cengiz Halit for his review and feedback during initial
phase of the solution definition. phase of the solution definition.
Thanks to Kenji Kumaki for his comments. Thanks to Kenji Kumaki for his comments.
Thanks to William Britto A J. for his suggestions. Thanks to William Britto A J. for his suggestions.
18. References 19. References
18.1. Normative References 19.1. Normative References
[BCP14] , <https://tools.ietf.org/html/bcp14>. [BCP14] , <https://tools.ietf.org/html/bcp14>.
[I-D.ietf-isis-te-app] [I-D.ietf-isis-te-app]
Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
J. Drake, "IS-IS TE Attributes per application", draft- J. Drake, "IS-IS Application-Specific Link Attributes",
ietf-isis-te-app-12 (work in progress), March 2020. draft-ietf-isis-te-app-19 (work in progress), June 2020.
[I-D.ietf-lsr-isis-srv6-extensions] [I-D.ietf-lsr-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extension to Support Segment Routing over Z. Hu, "IS-IS Extension to Support Segment Routing over
IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-07 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08
(work in progress), March 2020. (work in progress), April 2020.
[I-D.ietf-lsr-ospf-reverse-metric]
Talaulikar, K., Psenak, P., and H. Johnston, "OSPF Reverse
Metric", draft-ietf-lsr-ospf-reverse-metric-01 (work in
progress), June 2020.
[I-D.ietf-lsr-ospfv3-srv6-extensions] [I-D.ietf-lsr-ospfv3-srv6-extensions]
Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,
"OSPFv3 Extensions for SRv6", draft-ietf-lsr- "OSPFv3 Extensions for SRv6", draft-ietf-lsr-
ospfv3-srv6-extensions-00 (work in progress), February ospfv3-srv6-extensions-00 (work in progress), February
2020. 2020.
[I-D.ietf-ospf-te-link-attr-reuse] [I-D.ietf-ospf-te-link-attr-reuse]
Psenak, P., Ginsberg, L., Henderickx, W., Tantsura, J., Psenak, P., Ginsberg, L., Henderickx, W., Tantsura, J.,
and J. Drake, "OSPF Link Traffic Engineering Attribute and J. Drake, "OSPF Application-Specific Link Attributes",
Reuse", draft-ietf-ospf-te-link-attr-reuse-10 (work in draft-ietf-ospf-te-link-attr-reuse-16 (work in progress),
progress), October 2019. June 2020.
[ISO10589] [ISO10589]
International Organization for Standardization, International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain "Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in routeing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO/ connectionless-mode Network Service (ISO 8473)", ISO/
IEC 10589:2002, Second Edition, Nov 2002. IEC 10589:2002, Second Edition, Nov 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 32, line 21 skipping to change at page 34, line 26
[RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions
for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, for Segment Routing", RFC 8666, DOI 10.17487/RFC8666,
December 2019, <https://www.rfc-editor.org/info/rfc8666>. December 2019, <https://www.rfc-editor.org/info/rfc8666>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667, Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019, DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>. <https://www.rfc-editor.org/info/rfc8667>.
18.2. Informative References 19.2. Informative References
[I-D.gulkohegde-routing-planes-using-sr] [I-D.gulkohegde-routing-planes-using-sr]
Hegde, S. and a. arkadiy.gulko@thomsonreuters.com, Hegde, S. and a. arkadiy.gulko@thomsonreuters.com,
"Separating Routing Planes using Segment Routing", draft- "Separating Routing Planes using Segment Routing", draft-
gulkohegde-routing-planes-using-sr-00 (work in progress), gulkohegde-routing-planes-using-sr-00 (work in progress),
March 2017. March 2017.
[I-D.ietf-rtgwg-segment-routing-ti-lfa]
Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B.,
Francois, P., Voyer, D., Clad, F., and P. Camarillo,
"Topology Independent Fast Reroute using Segment Routing",
draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in
progress), March 2020.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway
Protocol (IGP) Routes Over Traffic Engineering Tunnels", Protocol (IGP) Routes Over Traffic Engineering Tunnels",
RFC 3906, DOI 10.17487/RFC3906, October 2004, RFC 3906, DOI 10.17487/RFC3906, October 2004,
<https://www.rfc-editor.org/info/rfc3906>. <https://www.rfc-editor.org/info/rfc3906>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
skipping to change at page 34, line 20 skipping to change at page 36, line 28
Ketan Talaulikar Ketan Talaulikar
Cisco Systems, Inc. Cisco Systems, Inc.
S.No. 154/6, Phase I, Hinjawadi S.No. 154/6, Phase I, Hinjawadi
PUNE, MAHARASHTRA 411 057 PUNE, MAHARASHTRA 411 057
India India
Email: ketant@cisco.com Email: ketant@cisco.com
Arkadiy Gulko Arkadiy Gulko
Thomson Reuters Refinitiv
Email: arkadiy.gulko@thomsonreuters.com Email: arkadiy.gulko@refinitiv.com
 End of changes. 38 change blocks. 
68 lines changed or deleted 168 lines changed or added

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