draft-ietf-lsr-ip-flexalgo-03.txt   draft-ietf-lsr-ip-flexalgo-04.txt 
LSR Working Group W. Britto LSR Working Group W. Britto
Internet-Draft S. Hegde Internet-Draft S. Hegde
Intended status: Standards Track P. Kaneriya Intended status: Standards Track P. Kaneriya
Expires: November 15, 2021 R. Shetty Expires: 22 June 2022 R. Shetty
R. Bonica R. Bonica
Juniper Networks Juniper Networks
P. Psenak P. Psenak
Cisco Systems Cisco Systems
May 14, 2021 19 December 2021
IGP Flexible Algorithms (Flex-Algorithm) In IP Networks IGP Flexible Algorithms (Flex-Algorithm) In IP Networks
draft-ietf-lsr-ip-flexalgo-03 draft-ietf-lsr-ip-flexalgo-04
Abstract Abstract
An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
constraint-based paths. As currently defined, IGP Flex-Algorithm is constraint-based paths. As currently defined, IGP Flex-Algorithm is
used with Segment Routing (SR) data planes - SR MPLS and SRv6. used with Segment Routing (SR) data planes - SR MPLS and SRv6.
Therefore, Flex-Algorithm cannot be deployed in the absence of SR. Therefore, Flex-Algorithm cannot be deployed in the absence of SR.
This document extends IGP Flex-Algorithm, so that it can be used for This document extends IGP Flex-Algorithm, so that it can be used for
regular IPv4 and IPv6 prefixes. This allows Flex-Algorithm to be regular IPv4 and IPv6 prefixes. This allows Flex-Algorithm to be
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 November 15, 2021. This Internet-Draft will expire on 22 June 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Egress Node Procedures . . . . . . . . . . . . . . . . . . . 3 3. Egress Node Procedures . . . . . . . . . . . . . . . . . . . 3
4. Advertising Flex-Algorithm Definitions (FAD) . . . . . . . . 3 4. Advertising Flex-Algorithm Definitions (FAD) . . . . . . . . 3
5. Advertising IP Flex-Algorithm Participation . . . . . . . . . 3 5. Advertising IP Flex-Algorithm Participation . . . . . . . . . 3
5.1. The ISIS IP Algorithm Sub-TLV . . . . . . . . . . . . . . 4 5.1. The ISIS IP Algorithm Sub-TLV . . . . . . . . . . . . . . 4
5.2. The OSPF IP Algorithm TLV . . . . . . . . . . . . . . . . 5 5.2. The OSPF IP Algorithm TLV . . . . . . . . . . . . . . . . 5
6. Advertising IP Flex-Algorthm Reachability . . . . . . . . . . 6 6. Advertising IP Flex-Algorthm Reachability . . . . . . . . . . 6
6.1. The ISIS IPv4 Algorithm Prefix Reachability TLV . . . . . 6 6.1. The ISIS IPv4 Algorithm Prefix Reachability TLV . . . . . 6
6.2. The ISIS IPv6 Algorithm Prefix Reachability TLV . . . . . 8 6.2. The ISIS IPv6 Algorithm Prefix Reachability TLV . . . . . 8
6.3. The OSPFv2 Algorithm Prefix Reachability TLV . . . . . . 9 6.3. The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV . . . 9
6.4. The OSPFv3 Flex-Algorithm IP Prefix Opaque LSA . . . . . 11 6.4. The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV . . . 10
7. Calculating of IP Flex-Algorthm Paths . . . . . . . . . . . . 11 6.5. The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV . . . 11
8. IP Flex-Algorthm Forwarding . . . . . . . . . . . . . . . . . 12 7. Calculating of IP Flex-Algorthm Paths . . . . . . . . . . . . 13
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 8. IP Flex-Algorthm Forwarding . . . . . . . . . . . . . . . . . 13
10. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . 16 14.1. Normative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 14.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
An IGP Flex-Algorithm as specified in [I-D.ietf-lsr-flex-algo] An IGP Flex-Algorithm as specified in [I-D.ietf-lsr-flex-algo]
computes a constraint-based path to: computes a constraint-based path to:
o All Flex-Algorithm specific Prefix Segment Identifiers (SIDs) * All Flex-Algorithm specific Prefix Segment Identifiers (SIDs)
[RFC8402]. [RFC8402].
o All Flex-Algorityhm specific SRv6 Locators * All Flex-Algorityhm specific SRv6 Locators [RFC8986].
[I-D.ietf-spring-srv6-network-programming].
Therefore, Flex-Algorithm cannot be deployed in the absence of SR and Therefore, Flex-Algorithm cannot be deployed in the absence of SR and
SRv6. SRv6.
This document extends Flex-Algorithm, allowing it to compute paths This document extends Flex-Algorithm, allowing it to compute paths
to: to:
o An IPv4 [RFC0791] address. * An IPv4 [RFC0791] address.
o An IPv6 [RFC8200] address. * An IPv6 [RFC8200] address.
This allows Flex-Algorithm to be deployed in any IP network, even in This allows Flex-Algorithm to be deployed in any IP network, even in
the absence of SR and SRv6. the absence of SR and SRv6.
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
skipping to change at page 4, line 7 skipping to change at page 3, line 52
in Sections 5, 6 and 7 of [I-D.ietf-lsr-flex-algo]. in Sections 5, 6 and 7 of [I-D.ietf-lsr-flex-algo].
5. Advertising IP Flex-Algorithm Participation 5. Advertising IP Flex-Algorithm Participation
A node may use various algorithms when calculating paths to nodes and A node may use various algorithms when calculating paths to nodes and
prefixes. Algorithm values are defined in the IGP Algorithm Type prefixes. Algorithm values are defined in the IGP Algorithm Type
Registry [IANA-ALG]. Registry [IANA-ALG].
A node MUST participate in a Flex-Algorithm to be: A node MUST participate in a Flex-Algorithm to be:
o able to compute path for such Flex-Algorithm * able to compute path for such Flex-Algorithm
* be part of the topology for such Flex-Algorithm
o be part of the topology for such Flex-Algorithm
Flex-Algorithm participation MUST be advertised for each Flex- Flex-Algorithm participation MUST be advertised for each Flex-
Algorithm application independently, as specified in Section 10.2 of Algorithm application independently, as specified in Section 10.2 of
[I-D.ietf-lsr-flex-algo]. Using Flex-Algorithm for regular IPv4 and [I-D.ietf-lsr-flex-algo]. Using Flex-Algorithm for regular IPv4 and
IPv6 prefixes represents a new Flex-Algorithm application (IP Flex- IPv6 prefixes represents a new Flex-Algorithm application (IP Flex-
Algorithm), and as such the Flex-Algorithm participation for the IP Algorithm), and as such the Flex-Algorithm participation for the IP
Flex-Algorithm application MUST be signalled independently of any Flex-Algorithm application MUST be signalled independently of any
other Flex-Algorithm applications (e.g. SR). other Flex-Algorithm applications (e.g. SR).
Following sections describe how the IP Flex-Algorithm participation Following sections describe how the IP Flex-Algorithm participation
skipping to change at page 4, line 37 skipping to change at page 4, line 32
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ISIS IP Algorithm Sub-TLV Figure 1: ISIS IP Algorithm Sub-TLV
o Type: IP Algorithm Sub-TLV (Value 29) * Type: IP Algorithm Sub-TLV (Value 29)
o Length: Variable * Length: Variable
o Algorithm (1 octet): value from 1 to 255. * Algorithm (1 octet): value from 1 to 255.
The IP Algorithm Sub-TLV MUST be propagated throughout the level and The IP Algorithm Sub-TLV MUST be propagated throughout the level and
MUST NOT be advertised across level boundaries. Therefore, the S bit MUST NOT be advertised across level boundaries. Therefore, the S bit
in the Router Capability TLV, in which the IP Algorithm Sub-TLV is in the Router Capability TLV, in which the IP Algorithm Sub-TLV is
advertised, MUST NOT be set. advertised, MUST NOT be set.
The IP Algorithm Sub-TLV is optional. It MUST NOT be advertised more The IP Algorithm Sub-TLV is optional. It MUST NOT be advertised more
than once at a given level. A router receiving multiple IP Algorithm than once at a given level. A router receiving multiple IP Algorithm
sub-TLVs from the same originator SHOULD select the first sub-TLVs from the same originator SHOULD select the first
advertisement in the lowest-numbered LSP and subsequent instances of advertisement in the lowest-numbered LSP and subsequent instances of
skipping to change at page 5, line 35 skipping to change at page 5, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm... | Algorithm n | | | Algorithm 1 | Algorithm... | Algorithm n | |
+- -+ +- -+
| | | |
+ + + +
Figure 2: OSPF IP Algorithm TLV Figure 2: OSPF IP Algorithm TLV
o Type: IP Algorithm TLV (Value TBD by IANA) * Type: IP Algorithm TLV (Value TBD by IANA)
o Length: Variable * Length: Variable
o Algorithm (1 octet): value from 1 to 255. * Algorithm (1 octet): value from 1 to 255.
The IP Algorithm TLV is optional. It SHOULD only be advertised once The IP Algorithm TLV is optional. It SHOULD only be advertised once
in the Router Information Opaque LSA. in the Router Information Opaque LSA.
When multiple IP Algorithm TLVs are received from a given router, the When multiple IP Algorithm TLVs are received from a given router, the
receiver MUST use the first occurrence of the TLV in the Router receiver MUST use the first occurrence of the TLV in the Router
Information Opaque LSA. If the IP Algorithm TLV appears in multiple Information Opaque LSA. If the IP Algorithm TLV appears in multiple
Router Information Opaque LSAs that have different flooding scopes, Router Information Opaque LSAs that have different flooding scopes,
the IP Algorithm TLV in the Router Information Opaque LSA with the the IP Algorithm TLV in the Router Information Opaque LSA with the
area-scoped flooding scope MUST be used. If the IP Algorithm TLV area-scoped flooding scope MUST be used. If the IP Algorithm TLV
skipping to change at page 6, line 29 skipping to change at page 6, line 27
in which the advertising node participates. in which the advertising node participates.
6. Advertising IP Flex-Algorthm Reachability 6. Advertising IP Flex-Algorthm Reachability
To be able to associate the prefix with the Flex-Algorithm, the To be able to associate the prefix with the Flex-Algorithm, the
existing prefix reachability advertisements can not be used, because existing prefix reachability advertisements can not be used, because
they advertise the prefix reachability in default algorithm 0. they advertise the prefix reachability in default algorithm 0.
Instead, a new IP Flex-Algorithm reachability advertisements are Instead, a new IP Flex-Algorithm reachability advertisements are
defined in ISIS and OSPF. defined in ISIS and OSPF.
The M-flag in FAD is not applicable to IP Algorithm Prefixes. Any IP
Algorithm Prefix advertisement includes the Algorithm and Metric
fields. When IP Algorithm Prefix is advertised between areas or
domains, the metric field in the IP Algorithm Prefix advertisement
MUST be used irrespective of the M-flag in the FAD advertisement.
Two new top-level TLVs are defined in ISIS [ISO10589] to advertise Two new top-level TLVs are defined in ISIS [ISO10589] to advertise
prefix reachability associated with a Flex-Algorithm. prefix reachability associated with a Flex-Algorithm.
o The IPv4 Algorithm Prefix Reachability TLV * The IPv4 Algorithm Prefix Reachability TLV
o The IPv6 Algorithm Prefix Reachability TLV * The IPv6 Algorithm Prefix Reachability TLV
New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684] is New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684] is
defined to advertise prefix reachability associated with a Flex- defined to advertise prefix reachability associated with a Flex-
Algorithm in OSPFv2. Algorithm in OSPFv2.
6.1. The ISIS IPv4 Algorithm Prefix Reachability TLV 6.1. The ISIS IPv4 Algorithm Prefix Reachability TLV
A new top level TLV is defined for advertising IPv4 Flex-Algorithm A new top level TLV is defined for advertising IPv4 Flex-Algorithm
Prefix Reachability in ISIS - IPv4 Algorithm Prefix Reachability TLV. Prefix Reachability in ISIS - IPv4 Algorithm Prefix Reachability TLV.
skipping to change at page 7, line 11 skipping to change at page 7, line 14
The ISIS IPv4 Algorithm Prefix Reachability TLV has the following The ISIS IPv4 Algorithm Prefix Reachability TLV has the following
format: 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 |R|R|R|R| MTID | | Type | Length |R|R|R|R| MTID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ISIS IPv4 Algorithm Prefix Reachability TLV Figure 3: ISIS IPv4 Algorithm Prefix Reachability TLV
o Type: IPv4 Algorithm Prefix Reachability TLV (Value 126). * Type: IPv4 Algorithm Prefix Reachability TLV (Value 126).
o Length: variable. * Length: variable.
o R bits (4 bits): reserved for future use. They MUST be set to * R bits (4 bits): reserved for future use. They MUST be set to
zero on transmission and MUST be ignored on receipt. zero on transmission and MUST be ignored on receipt.
o MTID (12 bits): Multitopology Identifier as defined in [RFC5120]. * MTID (12 bits): Multitopology Identifier as defined in [RFC5120].
Note that the value 0 is legal. Note that the value 0 is legal.
Followed by one or more prefix entries of the form: Followed by one or more prefix entries of the form:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | | Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pfx Length | Prefix (variable)... | Pfx Length | Prefix (variable)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-tlv-len | Sub-TLVs (variable) . . . | | Sub-tlv-len | Sub-TLVs (variable) . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ISIS IPv4 Algorithm Prefix Reachability TLV Figure 4: ISIS IPv4 Algorithm Prefix Reachability TLV
o Metric (4 octets): Metric information. * Metric (4 octets): Metric information.
o Flags (1 octet): * Flags (1 octet):
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|D| Reserved | |D| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
D-flag: When the Prefix is leaked from level-2 to level-1, the D-flag: When the Prefix is leaked from level-2 to level-1, the
D bit MUST be set. Otherwise, this bit MUST be clear. D bit MUST be set. Otherwise, this bit MUST be clear.
Prefixes with the D bit set MUST NOT be leaked from level-1 to Prefixes with the D bit set MUST NOT be leaked from level-1 to
level-2. This is to prevent looping. level-2. This is to prevent looping.
o Algorithm (1 octet): Associated Algorithm from 1 to 255. * Algorithm (1 octet): Associated Algorithm from 1 to 255.
o Prefix Len (1 octet): Prefix length measured in bits. * Prefix Len (1 octet): Prefix length measured in bits.
o Prefix (variable length): Prefix mapped to Flex-Algorithm. * Prefix (variable length): Prefix mapped to Flex-Algorithm.
o Optional Sub-TLV-length (1 octet): Number of octets used by sub- * Optional Sub-TLV-length (1 octet): Number of octets used by sub-
TLVs TLVs
o Optional sub-TLVs (variable length). * Optional sub-TLVs (variable length).
A router receiving multiple IPv4 Algorithm Prefix Reachability A router receiving multiple IPv4 Algorithm Prefix Reachability
advertisements for the same prefix, from the same originator, each advertisements for the same prefix, from the same originator, each
with a different Algorithm, MUST select the first advertisement in with a different Algorithm, MUST select the first advertisement in
the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm
Prefix Reachability advertisements for the same prefix for any other Prefix Reachability advertisements for the same prefix for any other
Algorithm. Algorithm.
A router receiving multiple IPv4 Algorithm Prefix Reachability A router receiving multiple IPv4 Algorithm Prefix Reachability
advertisements for the same prefix, from different originators, each advertisements for the same prefix, from different originators, each
skipping to change at page 9, line 7 skipping to change at page 9, line 15
A router receiving multiple IPv6 Algorithm Prefix Reachability A router receiving multiple IPv6 Algorithm Prefix Reachability
advertisements for the same prefix, from different originators, each advertisements for the same prefix, from different originators, each
with a different Algorithm, MUST ignore all of them and MUST NOT with a different Algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements. install any forwarding entries based on these advertisements.
In cases where a prefix advertisement is received in both a IPv6 In cases where a prefix advertisement is received in both a IPv6
Prefix Reachability TLV and an IPv6 Algorithm Prefix Reachability Prefix Reachability TLV and an IPv6 Algorithm Prefix Reachability
TLV, the IPv6 Prefix Reachability advertisement MUST be preferred TLV, the IPv6 Prefix Reachability advertisement MUST be preferred
when installing entries in the forwarding plane. when installing entries in the forwarding plane.
6.3. The OSPFv2 Algorithm Prefix Reachability TLV 6.3. The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV
A new top level TLV of OSPFv2 Extended Prefix Opaque LSA is defined A new Sub-TLV of OSPFv2 Extended Prefix TLV is defined for
for advertising IPv4 Algorithm Prefix Reachability in OSPFv2 - OSPF advertising IP Algorithm Prefix Reachability in OSPFv2 - OSPFv2 IP
Algorithm Prefix Reachability TLV Algorithm Prefix Reachability Sub-TLV.
Multiple Algorithm Prefix Reachability TLV MAY be advertised in each The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV has the following
OSPFv2 Extended Prefix Opaque LSA. However, since the opaque LSA format:
type defines the flooding scope, the LSA flooding scope MUST satisfy
the application specific requirements for all the prefixes included
in a single OSPFv2 Extended Prefix Opaque LSA. The Algorithm Prefix
Reachability 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Prefix Length | AF | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | Algorithm | Reserved | | MT-ID | Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| |
OSPFv2 Algorithm Prefix Reachability TLV Figure 5: OSPFv2 IP Algorithm Prefix Reachability Sub-TLV
Type: Algorithm Prefix Reachability TLV (Value TBD by IANA). * Type (2 octets) : The value is TBD.
Length: Variable dependent on sub-TLVs. * Length (1 octet): 8
Route Type (1 octet): type of the OSPF route. Supported types * MT-ID (1 octet): Multi-Topology ID as defined in [RFC8402]
are:
1 - Intra-Area * Algorithm (1 octet): Associated Algorithm from 1 to 255.
Algorithm values are defined in the IGP Algorithm Type registry.
If the value of Algorithm is 0 the TLV MUST be ignored.
2 - Inter-Area * Reserved: (2 octets). SHOULD be set to 0 on transmission and MUST
3 - AS External with Type-1 Metric be ignored on reception.
4 - AS External with Type-2 Metric * Metric (3 octets): The algorithm specific metric value.
5 - NSSA External with Type-1 Metric A OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix
Reachability Sub-TLVs in the same OSPFv2 Extended Prefix TLV, MUST
select the first advertisement of this Sub-TLV and MUST ignore all
remaining occurences of this Sub-TLV in the OSPFv2 Extended Prefix
TLV.
6 - NSSA External with Type-2 Metric A OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix
Reachability TLVs for the same prefix, from different originators,
each with a different Algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements.
Prefix Length (1 octet): Length of prefix in bits. In cases where a prefix advertisement is received in any of the LSAs
advertising the prefix reachability for algorithm 0 (Router-LSA,
Summary-LSA, AS-external-LSA or NSSA AS-external LSA) and in an
OSPFv2 IP Algorithm Prefix Reachability TLV, only the prefix
reachability advertisement for algorithm 0 MUST be used and all
occurences of the OSPFv2 IP Algorithm Prefix Reachability TLV MUST be
ignored.
AF (1 octet): Address family for the prefix. Currently, the only 6.4. The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV
supported value is 0 for IPv4 unicast. The inclusion of address
family in this TLV allows for future extension.
Flags (1 octet): Flags applicable to the prefix. Supported Flags The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is defined for
include: advertisement of the IP Algorithm Prefix Reachability in OSPFv3.
0x80 - A-Flag (Attach flag): An Area Border Router (ABR) The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is a sub-TLV of
generating an Extended Prefix TLV for inter-area prefix that is the following OSPFv3 TLVs defined in [RFC8362]:
locally connected or attached in other connected area SHOULD
set this flag.
0x40 - N-Flag (Node Flag): Set when the prefix identifies the * Intra-Area-Prefix TLV
advertising router i.e., the prefix is a host prefix
advertising a globally reachable address typically associated
with a loopback address. The advertising router MAY choose to
not set this flag even when the above conditions are met. If
the flag is set and the prefix length is not a host prefix then
the flag MUST be ignored. The flag is preserved when the
OSPFv2 Extended Prefix Opaque LSA is propagated between areas.
MT-ID (1 octet): Multi-Topology ID as defined in [RFC8402] * Inter-Area-Prefix TLV
Algorithm: (1 octet). Associated Algorithm from 1 to 255. * External-Prefix TLV
Adress Prefix: For the address family IPv4 unicast, the prefix The format of OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is
itself encoded as a 32-bit value. The default route is shown below:
represented by a prefix of length 0. Prefix encoding for other
address families is beyond the scope of this specification.
Metric (4 octets): Metric information. 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If this TLV is advertised multiple times for the same prefix in the Figure 6: OSPFv3 Algorithm Prefix Sub-TLV
same OSPFv2 Extended Prefix Opaque LSA, only the first instance of
the TLV is used by receiving OSPFv2 Routers. This situation SHOULD
be logged as an error.
If this TLV is advertised multiple times for the same prefix in Where:
different OSPFv2 Extended Prefix Opaque LSAs originated by the same
OSPF router, the OSPF advertising router is re-originating Extended
Prefix Opaque LSAs for multiple prefixes and is most likely repacking
Algorithm Prefix Reachability TLVs in Extended Prefix Opaque LSAs.
In this case, the Algorithm Prefix Reachability TLV in the Extended
Prefix Opaque LSA with the smallest Opaque ID is used by receiving
OSPFv2 Routers. This situation may be logged as a warning.
It is RECOMMENDED that OSPF routers advertising Algorithm Prefix Type (2 octets): The value is TBD.
Reachability TLVs in different Extended Prefix Opaque LSAs re-
originate these LSAs in ascending order of Opaque ID to minimize the
disruption.
A router receiving multiple Algorithm Prefix Reachability TLVs for Length (2 octets): 4.
the same prefix, from different originators, each with a different
Algorithm, MUST ignore all of them and MUST NOT install any
forwarding entries based on these advertisements.
In cases where a prefix advertisement is received in any of the LSAs Algorithm (1 octet): Associated Algorithm from 1 to 255.
advertising the prefix reachability for algorithm 0 (Router-LSA, Algorithm values are defined in the IGP Algorithm Type registry.
Summary-LSA, AS-external-LSA or NSSA AS-external LSA) and in an IPv4 If the value of Algorithm is 0 the TLV MUST be ignored.
Algorithm Prefix Reachability TLV, the prefix reachability
advertisement for algorithm 0 MUST be preferred when installing
entries in the forwarding plane, regardless of the Route Type
advertised in IPv4 Algorithm Prefix Reachability TLV.
6.4. The OSPFv3 Flex-Algorithm IP Prefix Opaque LSA Metric (3 octets): The algorithm specific metric value.
TBD. When the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is present,
the metric value in its parent TLV MUST be set to LSInfinity
([RFC2328]). If the metric value in the parent TLV is not set to
LSInfinity, the OSPFv3 IP Algorithm Prefix Sub-TLV MUST be ignored by
the receiver.
A OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix
Reachability Sub-TLVs in the same parent TLV, MUST select the first
advertisement of this Sub-TLV and MUST ignore all remaining
occurences of this Sub-TLV in the parent TLV.
A OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix
Reachability TLVs for the same prefix, from different originators,
each with a different Algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements.
In cases where a prefix advertisement is received in any of the TLVs
advertising the prefix reachability for algorithm 0 (Intra-Area-
Prefix TLV, Inter-Area-Prefix TLV, or External-Prefix TLV) with
metric other then LSInfinity, all OSPFv3 IP Algorithm Prefix TLVs
received for the prefix MUST be ignored.
6.5. The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV
Section 10.2 of the [I-D.ietf-lsr-flex-algo] defines the OSPF
Flexible Algorithm ASBR Metric Sub-TLV (FAAM) that is used by OSPFv2
and OSPFv3 to advertise Flex-Algorithm specific metric associated
with a given ASBR reachability advertisement by an ABR.
As described in section 11 of [I-D.ietf-lsr-flex-algo] each
application signals the participation independently. IP Flex-
Algorithm participation is signalled independently of the Segment
Routing (SR) Flex-Algorithm participation. As a result, the
calculated topologies for SR and IP Flex-Algorithm could be
different. Such difference prevents the usage of FAAM for the
purpose of the IP Flex-Algorithm.
The OSPF IP Flexible Algorithm ASBR Metric (IPFAAM) Sub-TLV is
defined for the advertisement of the IP Flex-Algorithm specific
metric associated with an ASBR by the ABR.
The IPFAAM Sub-TLV is a Sub-TLV of the:
- OSPFv2 Extended Inter-Area ASBR TLV as defined in
[I-D.ietf-lsr-flex-algo]
- OSPFv3 Inter-Area-Router TLV defined in [RFC8362]
OSPF IPFAAM 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type (2 octets): TBD for OSPFv2, TBD for OSPFv3.
Length (2 octets): 8.
Algorithm (1 octet): Associated Algorithm from 1 to 255.
Algorithm values are defined in the IGP Algorithm Type registry.
If the value of Algorithm is 0 the TLV MUST be ignored.
Reserved: (3 octets). SHOULD be set to 0 on transmission and MUST
be ignored on reception.
Metric (4 octets): The algorithm specific metric value.
The usage of the IPFAAM Sub-TLV is similar to the usage of the FAAM
Sub-TLV defined in [I-D.ietf-lsr-flex-algo], but it is used to
advertise IP Flex-Algorithm metric.
An OSPF ABR MUST include the OSPF IPFAAM Sub-TLVs as part of the ASBR
reachability advertisement between areas for every IP Flex-Algorithm
in which it participates and the ASBR is reachable in.
FAAM Sub-TLV as defined in [I-D.ietf-lsr-flex-algo] MUST NOT be used
during IP Flex-Algorithm path calculation, IPFAAM Sub-TLV MUST be
used instead.
7. Calculating of IP Flex-Algorthm Paths 7. Calculating of IP Flex-Algorthm Paths
IP Flex-Algorthm is considered as yet another application of the IP Flex-Algorthm is considered as yet another application of the
Flex-Algorithm as described in Section 10 and Section 12 of the Flex-Algorithm as described in Section 10 and Section 12 of the
[I-D.ietf-lsr-flex-algo]. [I-D.ietf-lsr-flex-algo].
Participation for the IP Flex-Algorithm is signalled as described in Participation for the IP Flex-Algorithm is signalled as described in
Section 5 and is specific to the IP Flex-Algorithm application. Section 5 and is specific to the IP Flex-Algorithm application.
skipping to change at page 13, line 24 skipping to change at page 14, line 46
10. Protection 10. Protection
In many networks where IGP Flexible Algorithms are deployed, IGP In many networks where IGP Flexible Algorithms are deployed, IGP
restoration will be fast and additional protection mechanisms will restoration will be fast and additional protection mechanisms will
not be required. IGP restoration may be enhanced by Equal Cost not be required. IGP restoration may be enhanced by Equal Cost
Multipath (ECMP). Multipath (ECMP).
In other networks, operators can deploy additional protection In other networks, operators can deploy additional protection
mechanisms. The following are examples: mechanisms. The following are examples:
o Loop Free Alternates (LFA) [RFC5286] * Loop Free Alternates (LFA) [RFC5286]
o Remote Loop Free Alternates (R-LFA) [RFC7490] * Remote Loop Free Alternates (R-LFA) [RFC7490]
LFA and R-LFA computations MUST be restricted to the flex-algo LFA and R-LFA computations MUST be restricted to the flex-algo
topology and the computed backup nexthops should be programmed for topology and the computed backup nexthops should be programmed for
the IP flex-algo prefixes. the IP flex-algo prefixes.
11. IANA Considerations 11. IANA Considerations
This specification updates the OSPF Router Information (RI) TLVs This specification updates the OSPF Router Information (RI) TLVs
Registry as follows: Registry as follows:
+-------+------------------+---------------------------+ +=======+==================+===========================+
| Value | TLV Name | Reference | | Value | TLV Name | Reference |
+-------+------------------+---------------------------+ +=======+==================+===========================+
| TBD | IP Algorithm TLV | This Document Section 5.2 | | TBD | IP Algorithm TLV | This Document Section 5.2 |
+-------+------------------+---------------------------+ +-------+------------------+---------------------------+
Table 1
This document also updates the "Sub-TLVs for TLV 242" registry as This document also updates the "Sub-TLVs for TLV 242" registry as
follows: follows:
+-------+----------------------+---------------------------+ +=======+======================+===========================+
| Value | TLV Name | Reference | | Value | TLV Name | Reference |
+-------+----------------------+---------------------------+ +=======+======================+===========================+
| 29 | IP Algorithm Sub-TLV | This Document Section 5.1 | | 29 | IP Algorithm Sub-TLV | This Document Section 5.1 |
+-------+----------------------+---------------------------+ +-------+----------------------+---------------------------+
Table 2
This document also updates the "ISIS TLV Codepoints Registry" This document also updates the "ISIS TLV Codepoints Registry"
registry as follows: registry as follows:
+-------+------------------+-----+-----+-----+-------+--------------+ +=======+==================+=====+=====+=====+=======+=============+
| Value | TLV Name | IIH | LSP | SNP | Purge | Reference | | Value | TLV Name | IIH | LSP | SNP | Purge | Reference |
+-------+------------------+-----+-----+-----+-------+--------------+ +=======+==================+=====+=====+=====+=======+=============+
| 126 | IPv4 Algorithm | N | Y | N | N | This | | 126 | IPv4 Algorithm | N | Y | N | N | This |
| | Prefix | | | | | document, | | | Prefix | | | | | document, |
| | Reachability TLV | | | | | Section 6.1 | | | Reachability TLV | | | | | Section 6.1 |
| 127 | IPv6 Algorithm | N | Y | N | N | This | +-------+------------------+-----+-----+-----+-------+-------------+
| | Prefix | | | | | document, | | 127 | IPv6 Algorithm | N | Y | N | N | This |
| | Reachability TLV | | | | | Section 6.2 | | | Prefix | | | | | document, |
+-------+------------------+-----+-----+-----+-------+--------------+ | | Reachability TLV | | | | | Section 6.2 |
+-------+------------------+-----+-----+-----+-------+-------------+
This document updates the "OSPFv2 Extended Prefix Opaque LSA TLVs" Table 3
registry as follows::
+-------+----------------------------------+------------------------+ This document updates the "OSPFv2 Extended Prefix TLV Sub-TLVs"
| Value | TLV Name | Reference | registry as follows:
+-------+----------------------------------+------------------------+
| TBD | OSPFv2 Algorithm Prefix | This Document, | +=======+=========================+================+
| | Reachability TLV | Section 6.1 | | Value | TLV Name | Reference |
+-------+----------------------------------+------------------------+ +=======+=========================+================+
| TBD | OSPFv2 IP Algorithm | This Document, |
| | Prefix Reachability TLV | Section 6.3 |
+-------+-------------------------+----------------+
Table 4
This document updates the "OSPFv3 Extended-LSA Sub-TLVs" registry as
follows:
+=======+==============================+================+
| Value | TLV Name | Reference |
+=======+==============================+================+
| TBD | OSPFv3 IP Algorithm Prefix | This Document, |
| | Reachability Sub-TLV | Section 6.4 |
+-------+------------------------------+----------------+
| TBD | OSPFv3 IP Flexible Algorithm | This Document, |
| | ASBR Metric Sub-TLV | Section 6.5 |
+-------+------------------------------+----------------+
Table 5
This document updates the "OSPFv2 Extended Inter-Area ASBR Sub-TLVs"
registry as follows:
+=======+============================+================+
| Value | TLV Name | Reference |
+=======+============================+================+
| 2 | OSPF IP Flexible Algorithm | This Document, |
| | ASBR Metric Sub-TLV | Section 6.5 |
+-------+----------------------------+----------------+
Table 6
12. Security Considerations 12. Security Considerations
This document inherits security considerations from This document inherits security considerations from
[I-D.ietf-lsr-flex-algo]. [I-D.ietf-lsr-flex-algo].
13. Acknowledgements 13. Acknowledgements
Thanks to Bruno Decraene for his contributions to this document. Thanks to Bruno Decraene for his contributions to this document.
Special thanks to Petr Bonbon Adamec of Cesnet for supporting
interoperability testing.
14. References 14. References
14.1. Normative References 14.1. 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", Work in Progress,
algo-15 (work in progress), April 2021. Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October
2021, <https://www.ietf.org/archive/id/draft-ietf-lsr-
flex-algo-18.txt>.
[ISO10589] [ISO10589] IANA, "Intermediate system to Intermediate system routing
IANA, "Intermediate system to Intermediate system routing
information exchange protocol for use in conjunction with information exchange protocol for use in conjunction with
the Protocol for providing the Connectionless-mode Network the Protocol for providing the Connectionless-mode Network
Service (ISO 8473)", August 1987, <ISO/IEC 10589:2002>. Service (ISO 8473)", August 1987, <ISO/IEC 10589:2002>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[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,
skipping to change at page 16, line 10 skipping to change at page 18, line 24
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <https://www.rfc-editor.org/info/rfc7770>. February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981, for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016, DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>. <https://www.rfc-editor.org/info/rfc7981>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
14.2. Informative References [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>.
[I-D.ietf-spring-srv6-network-programming] 14.2. Informative References
Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", draft-ietf-spring-srv6-
network-programming-28 (work in progress), December 2020.
[IANA-ALG] [IANA-ALG] IANA, "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY
IANA, "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY
TLV)", August 1987, <https://www.iana.org/assignments/igp- TLV)", August 1987, <https://www.iana.org/assignments/igp-
parameters/igp-parameters.xhtml#igp-algorithm-types>. parameters/igp-parameters.xhtml#igp-algorithm-types>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286, IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008, DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>. <https://www.rfc-editor.org/info/rfc5286>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015, RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>. <https://www.rfc-editor.org/info/rfc7490>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
Authors' Addresses Authors' Addresses
William Britto William Britto
Juniper Networks Juniper Networks
Elnath-Exora Business Park Survey Elnath-Exora Business Park Survey
Bangalore, Karnataka 560103 Bangalore 560103
Karnataka
India India
Email: bwilliam@juniper.net Email: bwilliam@juniper.net
Shraddha Hegde Shraddha Hegde
Juniper Networks Juniper Networks
Elnath-Exora Business Park Survey Elnath-Exora Business Park Survey
Bangalore, Karnataka 560103 Bangalore 560103
Karnataka
India India
Email: shraddha@juniper.net Email: shraddha@juniper.net
Parag Kaneriya Parag Kaneriya
Juniper Networks Juniper Networks
Elnath-Exora Business Park Survey Elnath-Exora Business Park Survey
Bangalore, Karnataka 560103 Bangalore 560103
Karnataka
India India
Email: pkaneria@juniper.net Email: pkaneria@juniper.net
Rejesh Shetty Rejesh Shetty
Juniper Networks Juniper Networks
Elnath-Exora Business Park Survey Elnath-Exora Business Park Survey
Bangalore, Karnataka 560103 Bangalore 560103
Karnataka
India India
Email: mrajesh@juniper.net Email: mrajesh@juniper.net
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, Virginia 20171 Herndon, Virginia 20171
USA United States of America
Email: rbonica@juniper.net Email: rbonica@juniper.net
Peter Psenak Peter Psenak
Cisco Systems Cisco Systems
Apollo Business Center Apollo Business Center
Mlynske nivy 43, Bratislava 82109 82109 Mlynske nivy 43
Slovakia Slovakia
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
 End of changes. 93 change blocks. 
184 lines changed or deleted 302 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/