IGP Flexible Algorithms (Flex-Algorithm) In IP Networks
draft-ietf-lsr-ip-flexalgo-03

Document Type Active Internet-Draft (lsr WG)
Authors William Britto  , Shraddha Hegde  , Parag Kaneriya  , Rejesh Shetty  , Ron Bonica  , Peter Psenak 
Last updated 2021-05-14
Replaces draft-bonica-lsr-ip-flexalgo
Stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats plain text xml pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Yes
Telechat date
Responsible AD (None)
Send notices to (None)
LSR Working Group                                              W. Britto
Internet-Draft                                                  S. Hegde
Intended status: Standards Track                             P. Kaneriya
Expires: November 15, 2021                                     R. Shetty
                                                               R. Bonica
                                                        Juniper Networks
                                                               P. Psenak
                                                           Cisco Systems
                                                            May 14, 2021

        IGP Flexible Algorithms (Flex-Algorithm) In IP Networks
                     draft-ietf-lsr-ip-flexalgo-03

Abstract

   An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
   constraint-based paths.  As currently defined, IGP Flex-Algorithm is
   used with Segment Routing (SR) data planes - SR MPLS and SRv6.
   Therefore, Flex-Algorithm cannot be deployed in the absence of SR.

   This document extends IGP Flex-Algorithm, so that it can be used for
   regular IPv4 and IPv6 prefixes.  This allows Flex-Algorithm to be
   deployed in any IP network, even in the absence of SR.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 15, 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Britto, et al.          Expires November 15, 2021               [Page 1]
Internet-Draft              IP Flex-Algorithm                   May 2021

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Egress Node Procedures  . . . . . . . . . . . . . . . . . . .   3
   4.  Advertising Flex-Algorithm Definitions (FAD)  . . . . . . . .   3
   5.  Advertising IP Flex-Algorithm Participation . . . . . . . . .   3
     5.1.  The ISIS IP Algorithm Sub-TLV . . . . . . . . . . . . . .   4
     5.2.  The OSPF IP Algorithm TLV . . . . . . . . . . . . . . . .   5
   6.  Advertising IP Flex-Algorthm Reachability . . . . . . . . . .   6
     6.1.  The ISIS IPv4 Algorithm Prefix Reachability TLV . . . . .   6
     6.2.  The ISIS IPv6 Algorithm Prefix Reachability TLV . . . . .   8
     6.3.  The OSPFv2 Algorithm Prefix Reachability TLV  . . . . . .   9
     6.4.  The OSPFv3 Flex-Algorithm IP Prefix Opaque LSA  . . . . .  11
   7.  Calculating of IP Flex-Algorthm Paths . . . . . . . . . . . .  11
   8.  IP Flex-Algorthm Forwarding . . . . . . . . . . . . . . . . .  12
   9.  Deployment Considerations . . . . . . . . . . . . . . . . . .  12
   10. Protection  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     14.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   An IGP Flex-Algorithm as specified in [I-D.ietf-lsr-flex-algo]
   computes a constraint-based path to:

   o  All Flex-Algorithm specific Prefix Segment Identifiers (SIDs)
      [RFC8402].

   o  All Flex-Algorityhm specific SRv6 Locators
      [I-D.ietf-spring-srv6-network-programming].

Britto, et al.          Expires November 15, 2021               [Page 2]
Internet-Draft              IP Flex-Algorithm                   May 2021

   Therefore, Flex-Algorithm cannot be deployed in the absence of SR and
   SRv6.

   This document extends Flex-Algorithm, allowing it to compute paths
   to:

   o  An IPv4 [RFC0791] address.

   o  An IPv6 [RFC8200] address.

   This allows Flex-Algorithm to be deployed in any IP network, even in
   the absence of SR and SRv6.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Egress Node Procedures

   Network operators configure multiple loopback interfaces on an egress
   node.  They associate one or more IP addresses with each loopback
   interface and one Flex-Algorithm with each IP address.

   If a packet is sent to a loopback address, and the loopback address
   is not associated with a Flex-Algorithm, the packet follows the IGP
   least-cost path to the egress node.  If a packet is sent to a
   loopback address, and the loopback address is associated with a Flex-
   Algorithm, the packet follows the constraint-base path that the Flex-
   Algorithm calculated.

4.  Advertising Flex-Algorithm Definitions (FAD)

   To guarantee loop free forwarding, all routers that participate in a
   Flex-Algorithm MUST agree on the Flex-Algorithm Definition (FAD).

   Selected nodes within the IGP domain MUST advertise FADs as described
   in Sections 5, 6 and 7 of [I-D.ietf-lsr-flex-algo].

5.  Advertising IP Flex-Algorithm Participation

   A node may use various algorithms when calculating paths to nodes and
   prefixes.  Algorithm values are defined in the IGP Algorithm Type
   Registry [IANA-ALG].

Britto, et al.          Expires November 15, 2021               [Page 3]
Internet-Draft              IP Flex-Algorithm                   May 2021

   A node MUST participate in a Flex-Algorithm to be:

   o  able to compute path for such Flex-Algorithm

   o  be part of the topology for such Flex-Algorithm

   Flex-Algorithm participation MUST be advertised for each Flex-
   Algorithm application independently, as specified in Section 10.2 of
   [I-D.ietf-lsr-flex-algo].  Using Flex-Algorithm for regular IPv4 and
   IPv6 prefixes represents a new Flex-Algorithm application (IP Flex-
   Algorithm), and as such the Flex-Algorithm participation for the IP
   Flex-Algorithm application MUST be signalled independently of any
   other Flex-Algorithm applications (e.g.  SR).

   Following sections describe how the IP Flex-Algorithm participation
   is advertised in IGP protocols.

5.1.  The ISIS IP Algorithm Sub-TLV

   The ISIS IP Algorithm Sub-TLV is a sub-TLV of the ISIS Router
   Capability TLV [RFC7981] and has the following format:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type        |     Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Algorithm 1   |  Algorithm 2  | Algorithm ... |  Algorithm n  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: ISIS IP Algorithm Sub-TLV

   o  Type: IP Algorithm Sub-TLV (Value 29)

   o  Length: Variable

   o  Algorithm (1 octet): value from 1 to 255.

   The IP Algorithm Sub-TLV MUST be propagated throughout the level and
   MUST NOT be advertised across level boundaries.  Therefore, the S bit
   in the Router Capability TLV, in which the IP Algorithm Sub-TLV is
   advertised, MUST NOT be set.

   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
   sub-TLVs from the same originator SHOULD select the first

Britto, et al.          Expires November 15, 2021               [Page 4]
Internet-Draft              IP Flex-Algorithm                   May 2021

   advertisement in the lowest-numbered LSP and subsequent instances of
   the IP Algorithm Sub-TLV MUST be ignored.

   The IP Algorithm Sub-TLV advertises the participation in Flex-
   Algorithms, and MUST NOT impact the router participation in default
   algorithm 0.  The IP Algorithm Sub-TLV could be used to advertise
   support for non-zero standard algorithms, but that is outside the
   scope of this document.

   The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
   Sub-TLV is topology independent.  When a router advertises
   participation in ISIS IP Algorithm Sub-TLV, the participation applies
   to all topologies in which the advertising node participates.

5.2.  The OSPF IP Algorithm TLV

   The OSPF IP Algorithm TLV is a top-level TLV of the Router
   Information Opaque LSA [RFC7770] and has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Type             |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Algorithm 1 | Algorithm...  |   Algorithm n |               |
      +-                                                             -+
      |                                                               |
      +                                                               +

                      Figure 2: OSPF IP Algorithm TLV

   o  Type: IP Algorithm TLV (Value TBD by IANA)

   o  Length: Variable

   o  Algorithm (1 octet): value from 1 to 255.

   The IP Algorithm TLV is optional.  It SHOULD only be advertised once
   in the Router Information Opaque LSA.

   When multiple IP Algorithm TLVs are received from a given router, the
   receiver MUST use the first occurrence of the TLV in the Router
   Information Opaque LSA.  If the IP Algorithm TLV appears in multiple
   Router Information Opaque LSAs that have different flooding scopes,
   the IP Algorithm TLV in the Router Information Opaque LSA with the
   area-scoped flooding scope MUST be used.  If the IP Algorithm TLV
   appears in multiple Router Information Opaque LSAs that have the same
   flooding scope, the IP Algorithm TLV in the Router Information (RI)

Britto, et al.          Expires November 15, 2021               [Page 5]
Internet-Draft              IP Flex-Algorithm                   May 2021

   Opaque LSA with the numerically smallest Instance ID MUST be used and
   subsequent instances of the IP Algorithm TLV MUST be ignored.

   The RI LSA can be advertised at any of the defined opaque flooding
   scopes (link, area, or Autonomous System (AS)).  For the purpose of
   IP Algorithm TLV advertisement, area-scoped flooding is REQUIRED.

   The IP Algorithm TLV advertises the participation in Flex-Algorithms,
   and MUST NOT impact the router participation in default algorithm 0.
   The IP Algorithm TLV could be used to advertise support for non-zero
   standard algorithms, but that is outside the scope of this document.

   The IP Flex-Algorithm participation advertised in OSPF IP Algorithm
   TLV is topology independent.  When a router advertises participation
   in OSPF IP Algorithm TLV, the participation applies to all topologies
   in which the advertising node participates.

6.  Advertising IP Flex-Algorthm Reachability

   To be able to associate the prefix with the Flex-Algorithm, the
   existing prefix reachability advertisements can not be used, because
   they advertise the prefix reachability in default algorithm 0.
   Instead, a new IP Flex-Algorithm reachability advertisements are
   defined in ISIS and OSPF.

   Two new top-level TLVs are defined in ISIS [ISO10589] to advertise
   prefix reachability associated with a Flex-Algorithm.

   o  The IPv4 Algorithm Prefix Reachability TLV

   o  The IPv6 Algorithm Prefix Reachability TLV

   New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684] is
   defined to advertise prefix reachability associated with a Flex-
   Algorithm in OSPFv2.

6.1.  The ISIS IPv4 Algorithm Prefix Reachability TLV

   A new top level TLV is defined for advertising IPv4 Flex-Algorithm
   Prefix Reachability in ISIS - IPv4 Algorithm Prefix Reachability TLV.

   This new TLV shares the sub-TLV space defined for TLVs 135, 235, 236
   and 237.

   The ISIS IPv4 Algorithm Prefix Reachability TLV has the following
   format:

Britto, et al.          Expires November 15, 2021               [Page 6]
Internet-Draft              IP Flex-Algorithm                   May 2021

       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    |R|R|R|R|    MTID               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                ISIS IPv4 Algorithm Prefix Reachability TLV

   o  Type: IPv4 Algorithm Prefix Reachability TLV (Value 126).

   o  Length: variable.

   o  R bits (4 bits): reserved for future use.  They MUST be set to
      zero on transmission and MUST be ignored on receipt.

   o  MTID (12 bits): Multitopology Identifier as defined in [RFC5120].
      Note that the value 0 is legal.

   Followed by one or more prefix entries of the form:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Metric                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Flags       |  Algorithm    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Pfx Length   |  Prefix (variable)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Sub-tlv-len  |         Sub-TLVs (variable) . . .             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                ISIS IPv4 Algorithm Prefix Reachability TLV

   o  Metric (4 octets): Metric information.

   o  Flags (1 octet):

                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |D|  Reserved   |
                +-+-+-+-+-+-+-+-+

         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.
         Prefixes with the D bit set MUST NOT be leaked from level-1 to
         level-2.  This is to prevent looping.

Britto, et al.          Expires November 15, 2021               [Page 7]
Internet-Draft              IP Flex-Algorithm                   May 2021

   o  Algorithm (1 octet): Associated Algorithm from 1 to 255.

   o  Prefix Len (1 octet): Prefix length measured in bits.

   o  Prefix (variable length): Prefix mapped to Flex-Algorithm.

   o  Optional Sub-TLV-length (1 octet): Number of octets used by sub-
      TLVs

   o  Optional sub-TLVs (variable length).

   A router receiving multiple IPv4 Algorithm Prefix Reachability
   advertisements for the same prefix, from the same originator, each
   with a different Algorithm, MUST select the first advertisement in
   the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm
   Prefix Reachability advertisements for the same prefix for any other
   Algorithm.

   A router receiving multiple IPv4 Algorithm Prefix Reachability
   advertisements 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 both a IPv4
   Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability
   TLV, the IPv4 Prefix Reachability advertisement MUST be preferred
   when installing entries in the forwarding plane.

6.2.  The ISIS IPv6 Algorithm Prefix Reachability TLV

   The ISIS IPv6 Algorithm Prefix Reachability TLV is identical to the
   ISIS IPv4 Algorithm Prefix Reachability TLV, except that it has a
   unique type.  The type is 127.

   A router receiving multiple IPv6 Algorithm Prefix Reachability
   advertisements for the same prefix, from the same originator, each
   with a different Algorithm, MUST select the first advertisement in
   the lowest-numbered LSP and ignore any subsequent IPv6 Algorithm
   Prefix Reachability advertisements for the same prefix for any other
   Algorithm.

   A router receiving multiple IPv6 Algorithm Prefix Reachability
   advertisements 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 both a IPv6
   Prefix Reachability TLV and an IPv6 Algorithm Prefix Reachability

Britto, et al.          Expires November 15, 2021               [Page 8]
Internet-Draft              IP Flex-Algorithm                   May 2021

   TLV, the IPv6 Prefix Reachability advertisement MUST be preferred
   when installing entries in the forwarding plane.

6.3.  The OSPFv2 Algorithm Prefix Reachability TLV

   A new top level TLV of OSPFv2 Extended Prefix Opaque LSA is defined
   for advertising IPv4 Algorithm Prefix Reachability in OSPFv2 - OSPF
   Algorithm Prefix Reachability TLV

   Multiple Algorithm Prefix Reachability TLV MAY be advertised in each
   OSPFv2 Extended Prefix Opaque LSA.  However, since the opaque LSA
   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 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            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Route Type   | Prefix Length |     AF        |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       MT-ID   |  Algorithm    |            Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Address Prefix (variable)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Metric                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Sub-TLVs (variable)                      |
    +-                                                             -+
    |                                                               |

                 OSPFv2 Algorithm Prefix Reachability TLV

      Type: Algorithm Prefix Reachability TLV (Value TBD by IANA).

      Length: Variable dependent on sub-TLVs.

      Route Type (1 octet): type of the OSPF route.  Supported types
      are:

         1 - Intra-Area

         2 - Inter-Area

Britto, et al.          Expires November 15, 2021               [Page 9]
Internet-Draft              IP Flex-Algorithm                   May 2021

         3 - AS External with Type-1 Metric

         4 - AS External with Type-2 Metric

         5 - NSSA External with Type-1 Metric

         6 - NSSA External with Type-2 Metric

      Prefix Length (1 octet): Length of prefix in bits.

      AF (1 octet): Address family for the prefix.  Currently, the only
      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
      include:

         0x80 - A-Flag (Attach flag): An Area Border Router (ABR)
         generating an Extended Prefix TLV for inter-area prefix that is
         locally connected or attached in other connected area SHOULD
         set this flag.

         0x40 - N-Flag (Node Flag): Set when the prefix identifies the
         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]

      Algorithm: (1 octet).  Associated Algorithm from 1 to 255.

      Adress Prefix: For the address family IPv4 unicast, the prefix
      itself encoded as a 32-bit value.  The default route is
      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.

   If this TLV is advertised multiple times for the same prefix in the
   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.

Britto, et al.          Expires November 15, 2021              [Page 10]
Internet-Draft              IP Flex-Algorithm                   May 2021

   If this TLV is advertised multiple times for the same prefix in
   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
   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
   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
   advertising the prefix reachability for algorithm 0 (Router-LSA,
   Summary-LSA, AS-external-LSA or NSSA AS-external LSA) and in an IPv4
   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

   TBD.

7.  Calculating of IP Flex-Algorthm Paths

   IP Flex-Algorthm is considered as yet another application of the
   Flex-Algorithm as described in Section 10 and Section 12 of the
   [I-D.ietf-lsr-flex-algo].

   Participation for the IP Flex-Algorithm is signalled as described in
   Section 5 and is specific to the IP Flex-Algorithm application.

   Calculation of IP Flex-Algorithm paths follows the Section 12 of
   [I-D.ietf-lsr-flex-algo].  This computation uses the IP Flex-
   Algorithm participation and is independent of the Flex-Algorithm
   calculation done for any other Flex-Algorithm applications (e.g.  SR,
   SRv6).

   IP Flex-Algorithm application only considers participating nodes
   during the Flex-Algorithm calculation.  When computing paths for a

Britto, et al.          Expires November 15, 2021              [Page 11]
Internet-Draft              IP Flex-Algorithm                   May 2021

   given Flex-Algorithm, all nodes that do not advertise participation
   for IP Flex-Algorithm, as described in Section 5, MUST be pruned from
   the topology.

8.  IP Flex-Algorthm Forwarding

   IP Algorithm Prefix Reachability advertisement as described in
   Section 5 includes the MTID value that associates the prefix with a
   specific topology.  Algorithm Prefix Reachability advertisement also
   includes an Algorithm value that explicitly associates the prefix
   with a specific Flex-Algorithm.  The paths to the prefix MUST be
   calculated using the specified Flex-Algorithm in the associated
   topology.

   Forwarding entries for the IP Flex-Algorithm prefixes advertised in
   IGPs MUST be installed in the forwarding plane of the receiving IP
   Flex-Algorithm prefix capable routers when they participate in the
   associated topology and algorithm.  Forwarding entries for IP Flex-
   Algorithm prefixes associated with Flex-Algorithms in which the node
   is not participating MUST NOT be installed in the forwarding plane.

   When the IP Flex-Algorithm prefix is associated with a Flex-
   Algorithm, LFA paths to the prefix MUST be calculated using such
   Flex-Algorithm in the associated topology, to guarantee that they
   follow the same constraints as the calculation of the primary paths.

9.  Deployment Considerations

   IGP Flex-Algorithm can be used by many applications.  Original
   specification was done for SR and SRv6, this specification adds IP as
   another application that can use IGP Flex-Algorithm.  Other
   applications may be defined in the future.  This section provides
   some details about the coexistence of the various applications of the
   IGP Flex-Algorithm.

   Flex-Algorithm definition (FAD), as described in
   [I-D.ietf-lsr-flex-algo], is application independent and is used by
   all Flex-Algorithm applications.

   Participation in the Flex-Algorithm, as described in
   [I-D.ietf-lsr-flex-algo], is application specific.

   Calculation of the flex-algo paths is application specific and uses
   application specific participation advertisements.

   Application specific participation and calculation guarantee that the
   forwarding of the traffic over the Flex-Algorithm application

Britto, et al.          Expires November 15, 2021              [Page 12]
Internet-Draft              IP Flex-Algorithm                   May 2021

   specific paths is consistent between all nodes over which the traffic
   is being forwarded.

   Multiple application can use the same Flex-Algorithm value at the
   same time and and as such share the FAD for it.  For example SR-MPLS
   and IP can both use such common Flex-Algorithm.  Traffic for SR-MPLS
   will be forwarded based on Flex-algorithm specific SR SIDs.  Traffic
   for IP Flex-Algorithm will be forwarded based on Flex-Algorithm
   specific prefix reachability announcements.

10.  Protection

   In many networks where IGP Flexible Algorithms are deployed, IGP
   restoration will be fast and additional protection mechanisms will
   not be required.  IGP restoration may be enhanced by Equal Cost
   Multipath (ECMP).

   In other networks, operators can deploy additional protection
   mechanisms.  The following are examples:

   o  Loop Free Alternates (LFA) [RFC5286]

   o  Remote Loop Free Alternates (R-LFA) [RFC7490]

   LFA and R-LFA computations MUST be restricted to the flex-algo
   topology and the computed backup nexthops should be programmed for
   the IP flex-algo prefixes.

11.  IANA Considerations

   This specification updates the OSPF Router Information (RI) TLVs
   Registry as follows:

         +-------+------------------+---------------------------+
         | Value | TLV Name         | Reference                 |
         +-------+------------------+---------------------------+
         | TBD   | IP Algorithm TLV | This Document Section 5.2 |
         +-------+------------------+---------------------------+

   This document also updates the "Sub-TLVs for TLV 242" registry as
   follows:

       +-------+----------------------+---------------------------+
       | Value | TLV Name             | Reference                 |
       +-------+----------------------+---------------------------+
       | 29    | IP Algorithm Sub-TLV | This Document Section 5.1 |
       +-------+----------------------+---------------------------+

Britto, et al.          Expires November 15, 2021              [Page 13]
Internet-Draft              IP Flex-Algorithm                   May 2021

   This document also updates the "ISIS TLV Codepoints Registry"
   registry as follows:

   +-------+------------------+-----+-----+-----+-------+--------------+
   | Value | TLV Name         | IIH | LSP | SNP | Purge | Reference    |
   +-------+------------------+-----+-----+-----+-------+--------------+
   | 126   | IPv4 Algorithm   | N   | Y   | N   | N     | This         |
   |       | Prefix           |     |     |     |       | document,    |
   |       | Reachability TLV |     |     |     |       | Section 6.1  |
   | 127   | IPv6 Algorithm   | N   | Y   | N   | N     | This         |
   |       | Prefix           |     |     |     |       | document,    |
   |       | Reachability TLV |     |     |     |       | Section 6.2  |
   +-------+------------------+-----+-----+-----+-------+--------------+

   This document updates the "OSPFv2 Extended Prefix Opaque LSA TLVs"
   registry as follows::

   +-------+----------------------------------+------------------------+
   | Value | TLV Name                         | Reference              |
   +-------+----------------------------------+------------------------+
   | TBD   | OSPFv2 Algorithm Prefix          | This Document,         |
   |       | Reachability TLV                 | Section 6.1            |
   +-------+----------------------------------+------------------------+

12.  Security Considerations

   This document inherits security considerations from
   [I-D.ietf-lsr-flex-algo].

13.  Acknowledgements

   Thanks to Bruno Decraene for his contributions to this document.

14.  References

14.1.  Normative References

   [I-D.ietf-lsr-flex-algo]
              Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
              A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
              algo-15 (work in progress), April 2021.

   [ISO10589]
              IANA, "Intermediate system to Intermediate system routing
              information exchange protocol for use in conjunction with
              the Protocol for providing the Connectionless-mode Network
              Service (ISO 8473)", August 1987, <ISO/IEC 10589:2002>.

Britto, et al.          Expires November 15, 2021              [Page 14]
Internet-Draft              IP Flex-Algorithm                   May 2021

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <https://www.rfc-editor.org/info/rfc2328>.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              DOI 10.17487/RFC3630, September 2003,
              <https://www.rfc-editor.org/info/rfc3630>.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, DOI 10.17487/RFC4915, June 2007,
              <https://www.rfc-editor.org/info/rfc4915>.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120,
              DOI 10.17487/RFC5120, February 2008,
              <https://www.rfc-editor.org/info/rfc5120>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <https://www.rfc-editor.org/info/rfc5340>.

   [RFC7684]  Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
              Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
              Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
              2015, <https://www.rfc-editor.org/info/rfc7684>.

   [RFC7770]  Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
              S. Shaffer, "Extensions to OSPF for Advertising Optional
              Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
              February 2016, <https://www.rfc-editor.org/info/rfc7770>.

Britto, et al.          Expires November 15, 2021              [Page 15]
Internet-Draft              IP Flex-Algorithm                   May 2021

   [RFC7981]  Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
              for Advertising Router Information", RFC 7981,
              DOI 10.17487/RFC7981, October 2016,
              <https://www.rfc-editor.org/info/rfc7981>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

14.2.  Informative References

   [I-D.ietf-spring-srv6-network-programming]
              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, "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY
              TLV)", August 1987, <https://www.iana.org/assignments/igp-
              parameters/igp-parameters.xhtml#igp-algorithm-types>.

   [RFC5286]  Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
              IP Fast Reroute: Loop-Free Alternates", RFC 5286,
              DOI 10.17487/RFC5286, September 2008,
              <https://www.rfc-editor.org/info/rfc5286>.

   [RFC7490]  Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
              So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
              RFC 7490, DOI 10.17487/RFC7490, April 2015,
              <https://www.rfc-editor.org/info/rfc7490>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

Authors' Addresses

Britto, et al.          Expires November 15, 2021              [Page 16]
Internet-Draft              IP Flex-Algorithm                   May 2021

   William Britto
   Juniper Networks
   Elnath-Exora Business Park Survey
   Bangalore, Karnataka  560103
   India

   Email: bwilliam@juniper.net

   Shraddha Hegde
   Juniper Networks
   Elnath-Exora Business Park Survey
   Bangalore, Karnataka  560103
   India

   Email: shraddha@juniper.net

   Parag Kaneriya
   Juniper Networks
   Elnath-Exora Business Park Survey
   Bangalore, Karnataka  560103
   India

   Email: pkaneria@juniper.net

   Rejesh Shetty
   Juniper Networks
   Elnath-Exora Business Park Survey
   Bangalore, Karnataka  560103
   India

   Email: mrajesh@juniper.net

   Ron Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, Virginia  20171
   USA

   Email: rbonica@juniper.net

Britto, et al.          Expires November 15, 2021              [Page 17]
Internet-Draft              IP Flex-Algorithm                   May 2021

   Peter Psenak
   Cisco Systems
   Apollo Business Center
   Mlynske nivy 43, Bratislava  82109
   Slovakia

   Email: ppsenak@cisco.com

Britto, et al.          Expires November 15, 2021              [Page 18]