Skip to main content

RIFT Auto-IS-IS
draft-head-rift-auto-is-is-00

Document Type Active Internet-Draft (individual)
Authors Jordan Head , Tony Przygienda , Colby Barth , Luis Tomotaki , Brant Brockdorff
Last updated 2024-10-11
Replaces draft-head-rift-auto-fr
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-head-rift-auto-is-is-00
RIFT                                                        J. Head, Ed.
Internet-Draft                                             T. Przygienda
Intended status: Standards Track                                C. Barth
Expires: 14 April 2025                                  Juniper Networks
                                                             L. Tomotaki
                                                           B. Brockdorff
                                                                 Verizon
                                                         11 October 2024

                            RIFT Auto-IS-IS
                     draft-head-rift-auto-is-is-00

Abstract

   This document specifies procedures where RIFT can automatically
   provision IS-IS topologies by leveraging its native no-touch ZTP
   architecture.

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 14 April 2025.

Copyright Notice

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

Head, et al.              Expires 14 April 2025                 [Page 1]
Internet-Draft               RIFT Auto IS-IS                October 2024

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Design Considerations . . . . . . . . . . . . . . . . . . . .   3
   3.  Auto-IS-IS  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Device Roles  . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  All Participating Nodes . . . . . . . . . . . . . . .   4
       3.1.2.  Top-of-Fabric Nodes . . . . . . . . . . . . . . . . .   4
       3.1.3.  Spine Nodes . . . . . . . . . . . . . . . . . . . . .   4
       3.1.4.  Leaf Nodes  . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Variable Derivation . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  RIFT System ID  . . . . . . . . . . . . . . . . . . .   5
       3.2.2.  Auto-IS-IS Version  . . . . . . . . . . . . . . . . .   5
       3.2.3.  IS-IS System ID . . . . . . . . . . . . . . . . . . .   6
       3.2.4.  IS-IS NET Address . . . . . . . . . . . . . . . . . .   6
       3.2.5.  Loopback Address  . . . . . . . . . . . . . . . . . .   6
     3.3.  IS-IS Flood Reflection Topologies . . . . . . . . . . . .   6
       3.3.1.  Device Roles  . . . . . . . . . . . . . . . . . . . .   7
         3.3.1.1.  All Participating Nodes . . . . . . . . . . . . .   7
         3.3.1.2.  Flood Reflectors  . . . . . . . . . . . . . . . .   7
         3.3.1.3.  Flood Reflector Spines  . . . . . . . . . . . . .   8
         3.3.1.4.  Flood Reflectors Clients  . . . . . . . . . . . .   8
       3.3.2.  Auto-FR Variable Derivation . . . . . . . . . . . . .   8
         3.3.2.1.  RIFT System ID  . . . . . . . . . . . . . . . . .   8
         3.3.2.2.  Auto-FR Version . . . . . . . . . . . . . . . . .   8
         3.3.2.3.  Flood Reflection Cluster ID . . . . . . . . . . .   9
         3.3.2.4.  Flood Reflection Preference . . . . . . . . . . .   9
         3.3.2.5.  IS-IS System ID . . . . . . . . . . . . . . . . .   9
         3.3.2.6.  IS-IS NET Address . . . . . . . . . . . . . . . .  10
         3.3.2.7.  Loopback Address  . . . . . . . . . . . . . . . .  10
   4.  RIFT Requirements . . . . . . . . . . . . . . . . . . . . . .  11
     4.1.  RIFT FSM / LIE Validation Requirements  . . . . . . . . .  12
     4.2.  RIFT Node-TIE Advertisements  . . . . . . . . . . . . . .  12
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .  12
     5.1.  RIFT Underlay with an IS-IS Flood Reflection Topology . .  12
     5.2.  Auto-FR Analytics . . . . . . . . . . . . . . . . . . . .  14
       5.2.1.  Auto-FR Analytics (Global) Key/Value Pair . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16

Head, et al.              Expires 14 April 2025                 [Page 2]
Internet-Draft               RIFT Auto IS-IS                October 2024

   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
   Appendix A.  YANG Model . . . . . . . . . . . . . . . . . . . . .  17
   Appendix B.  Thrift Models  . . . . . . . . . . . . . . . . . . .  18
     B.1.  common.thrift . . . . . . . . . . . . . . . . . . . . . .  18
     B.2.  encoding.thrift . . . . . . . . . . . . . . . . . . . . .  18
     B.3.  common_flood_reflection.thrift  . . . . . . . . . . . . .  19
   Appendix C.  auto_flood_reflection_kv.thrift  . . . . . . . . . .  20
   Appendix D.  Auto-FR Variable Derivation  . . . . . . . . . . . .  22
   Appendix E.  Auto-IS-IS Variable Derivation . . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

1.  Introduction

   [RIFT] is a protocol that focuses heavily on operational simplicity.
   It natively supports Zero Touch Provisioning (ZTP) functionality that
   allows each node to automatically derive its place in the topology
   and configure itself accordingly when properly cabled as a Clos, Fat-
   Tree, or other similarly structured variant.

   Given the prominence of IP fabrics within modern day networks and
   that IS-IS [ISO10589] is a popular IGP in those networks, it is
   beneficial to consider how deployment and operation could be
   simplified.  This document specifies methods that leverages these
   properties of RIFT so that nodes can self-configure and provide
   relevant the operational state using [RIFT-KV], specifically for IS-
   IS topologies.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Design Considerations

   The methods specified in this document leverage existing IS-IS
   standards without requiring any modification.  In essence, this
   document provides normative algorithms to derive the necessary IS-IS
   configuration variables in a distributed fashion.  For example, in a
   Flood Reflection topology a leaf node must consider the Cluster ID
   while deriving its loopback address.  Whereas in a generic IS-IS
   topology a Cluster ID is not present and such consideration is not
   necessary.

Head, et al.              Expires 14 April 2025                 [Page 3]
Internet-Draft               RIFT Auto IS-IS                October 2024

   Similar considerations are necessary with respect to operations and
   management.

3.  Auto-IS-IS

   This section describes how RIFT nodes can automatically self-
   configure to form IS-IS topologies in a completely distributed
   fashion using RIFT's ZTP functionality.

3.1.  Device Roles

3.1.1.  All Participating Nodes

   Nodes that need to configure themselves in an Auto-IS-IS topology
   MUST be capable of deriving the following variables:

      *IPv6 Loopback Address*
         Unique IPv6 loopback address.

      *IS-IS System ID*
         The IS-IS System Identifier used in deriving the IS-IS NET
         Address.

      *IS-IS NET Address*
         The IS-IS NET Address used to uniquely identify an IS-IS node.

3.1.2.  Top-of-Fabric Nodes

   This section describes any Top-of-Fabric-specific functions for IS-IS
   nodes at the top of the fabric.

   Fabrics running IS-IS might be L1, L2, or possibly another variant.
   Nodes MAY use their device role as a means to indicate that some
   interfaces can be adjusted to fit the desired outcome (e.g., Flood
   Reflection).

      *Future Consideration*
         Future Consideration

3.1.3.  Spine Nodes

   This section describes any Spine-specific functions for IS-IS nodes
   that are not at the top of the fabric or at the bottom of the fabric
   (i.e., leaf nodes).

Head, et al.              Expires 14 April 2025                 [Page 4]
Internet-Draft               RIFT Auto IS-IS                October 2024

   Fabrics running IS-IS might be L1, L2, or possibly another variant.
   Nodes MAY use their device role as a means to indicate that some
   interfaces can be adjusted to fit the desired outcome (e.g., Flood
   Reflection).

      *Future Consideration*
         Future Consideration

3.1.4.  Leaf Nodes

   This section describes any Leaf-specific functions for IS-IS nodes
   that are at the bottom of the fabric.

   Fabrics running IS-IS might be L1, L2, or possibly another variant.
   Nodes MAY use their device role as a means to indicate that some
   interfaces can be adjusted to fit the desired outcome (e.g., Flood
   Reflection).

      *Future Consideration*
         Future Consideration

3.2.  Variable Derivation

   It is important to mention that all Auto-IS-IS variable derivation is
   in some way based on the RIFT System ID and/or Fabric ID and MUST
   comply precisely with calculation methods specified in the Auto-IS-IS
   Variable Derivation section to allow interoperability between
   different implementations.  All necessary foundational code elements
   are also mentioned there.

3.2.1.  RIFT System ID

   The 64-bit RIFT System ID that uniquely identifies a node as defined
   in RIFT [RIFT].  This is not derived specifically for Auto-IS-IS, but
   for all RIFT nodes and is used in the derivation procedures described
   in this section.

3.2.2.  Auto-IS-IS Version

   This section serves as a placeholder to describe extensions to both
   the RIFT LIE and Node-TIE packet schemas in the form of a 16-bit
   value that identifies the Auto-IS-IS Version.  Auto-IS-IS capable
   nodes MUST support this extension, but MAY choose not to advertise it
   in LIEs and Node-TIEs when Auto-IS-IS is not being utilized.

Head, et al.              Expires 14 April 2025                 [Page 5]
Internet-Draft               RIFT Auto IS-IS                October 2024

   The complete encoding.thrift schema documented in RIFT [RIFT]
   describes both major and minor protocol/schema versions.  Auto-IS-IS
   Version calculation will be described in a future version of this
   document.

   This section will also describes an extension to the NodeCapabilities
   schema indicating whether or not a node supports Auto-IS-IS.

   A future version of this document will define any changes required
   for the LIEPacket, NodeTIEElement, and NodeCapabilities Thrift
   schemas.

3.2.3.  IS-IS System ID

   Auto-IS-IS nodes MUST derive a unique 6-byte IS-IS System ID for use
   in deriving the IS-IS NET Address.  Calculation of this value will be
   described in a future version of this document.

3.2.4.  IS-IS NET Address

   Auto-FR nodes MUST derive a unique 10-byte IS-IS NET (Network Entity
   Title) Address to uniquely identify itself within the Flood
   Reflection topology.  The 1st byte (which indicates the AFI) MUST
   have a value of "49".  The last byte (i.e. the NSEL) MUST have a
   value of 0.  Calculation of this value will be described in a future
   version of this document.

3.2.5.  Loopback Address

   Auto-FR nodes MUST derive a ULA-scoped IPv6 loopback address to be
   used in IS-IS.  Calculation of this value will be described in a
   future version of this document.

3.3.  IS-IS Flood Reflection Topologies

   IS-IS Flood Reflection [RFC9377] is a mechanism that enables flat
   single-area Level 2 IS-IS topologies to scale well beyond their
   typical properties when deployed in similar topological structures
   by:

   1.  Reducing the number of required links and adjacencies.

   2.  Reducing the size of the Link-State Database.

   3.  Reducing the amount of flooding.

   4.  Reducing the number of SPF computations.

Head, et al.              Expires 14 April 2025                 [Page 6]
Internet-Draft               RIFT Auto IS-IS                October 2024

   5.  Reducing the maximum SPF computation time.

   This section describes an OPTIONAL "sub-mode" of Auto-IS-IS that RIFT
   can use to automatically provision IS-IS Flood Reflection topologies
   in a completely distributed fashion using RIFT's ZTP functionality.

3.3.1.  Device Roles

   Auto Flood Reflection requires that each node understands its given
   role within the scope of the Flood Reflection deployment so that each
   node derives the necessary variables and resulting configuration.

3.3.1.1.  All Participating Nodes

   All nodes in the topology MUST be capable of deriving the following
   variables:

      *Flood Reflection Cluster ID*
         The Flood Reflection Cluster ID us to distinguish reflection
         domains (similar to the Cluster ID use in BGP Route
         Reflection).

      *IPv6 Loopback Address*
         Unique IPv6 loopback address.

      *IS-IS System ID*
         The IS-IS System Identifier used in deriving the IS-IS NET
         Address.

      *IS-IS NET Address*
         The IS-IS NET Address used to uniquely identify an IS-IS node.

3.3.1.2.  Flood Reflectors

   This section defines an Auto-FR role whereby some ToF (Top-of-Fabric)
   nodes act as IS-IS Flood Reflectors.  It is expected that Flood
   Reflectors will establish Level 2 IS-IS adjacencies with Flood
   Reflector Clients in the same area, in the same fabric.  The typical
   Flood Reflector requirements do not change, however, determining
   which specific values to use requires further consideration.

   ToF nodes performing Flood Reflector functionality MUST derive the
   following variables:

      *IPv6 Flood Reflector Loopback Address*
         Unique IPv6 loopback address.

Head, et al.              Expires 14 April 2025                 [Page 7]
Internet-Draft               RIFT Auto IS-IS                October 2024

3.3.1.3.  Flood Reflector Spines

   A "spine" can simply be thought of as a Flood Reflection node not
   acting as a Flood Reflector (ToF) or Flood Reflector Client (leaf).
   While a spine node requires no specific variable derivation, it is
   REQUIRED so that it can function in the context of a Flood Reflection
   topology as a IS-IS level 1 node.  It may also be desirable to do so
   to facilitate the use of Auto-FR specific Key-Value TIEs.

   This section also serves as a placeholder for future considerations
   and enhancements.

      *Future Consideration*
         Future Consideration

3.3.1.4.  Flood Reflectors Clients

   Although no specific variables for Flood Reflector Clients are
   described at this time, the generic role is specified as a
   placeholder for future enhancements.

      *Future Consideration*
         Future Consideration

3.3.2.  Auto-FR Variable Derivation

   Like with Auto-IS-IS, Auto-FR variable derivation is in some way
   based on the RIFT System ID and/or Cluster ID and MUST comply
   precisely with calculation methods specified in the Auto-FR Variable
   Derivation section to allow interoperability between different
   implementations.  All necessary foundational code elements are also
   mentioned there.

3.3.2.1.  RIFT System ID

   The 64-bit RIFT System ID that uniquely identifies a node as defined
   in Section 3.2.1.

3.3.2.2.  Auto-FR Version

   This section describes extensions to both the RIFT LIE and Node-TIE
   packet schemas in the form of a 16-bit value that identifies the
   Auto-FR Version.  Auto-FR capable nodes MUST support this extension,
   but MAY choose not to advertise it in LIEs and Node-TIEs when Auto-FR
   is not being utilized.

Head, et al.              Expires 14 April 2025                 [Page 8]
Internet-Draft               RIFT Auto IS-IS                October 2024

   The complete encoding.thrift schema documented in RIFT [RIFT]
   describes both major and minor protocol/schema versions.  Auto-FR
   Version calculation is done by multiiplying a static value of 256 by
   the major version then adding the minor version, that is to say - 256
   * MAJOR + MINOR.

   This section also describes an extension to the NodeCapabilities
   schema indicating whether or not a node supports Auto-FR.

   The appendix (Appendix B) details necessary changes to the LIEPacket,
   NodeTIEElement, and NodeCapabilities Thrift schemas.

3.3.2.3.  Flood Reflection Cluster ID

   This section describes extensions to both the RIFT LIE and Node-TIE
   packet schemas in the form of a 32-bit value that identifies the
   Auto-FR Cluster ID.  Auto-FR capable nodes MUST support this
   extension, but MAY choose not to advertise it in LIEs and Node-TIEs
   when Auto-FR is not being utilized.

   Deployments using more than one Auto-FR cluster MUST use different
   Cluster IDs.  Failure to do so may cause sub-optimal routing as L1/L2
   nodes from different clusters would belong to the same subnet.

   A Cluster ID with a value of 0 is considered invalid and MUST NOT be
   used for any purpose.

   The appendix (Appendix B) details necessary changes to the LIEPacket
   and NodeTIEElement Thrift schemas.

3.3.2.4.  Flood Reflection Preference

   This section describes extensions to the Node-TIE packet schema in
   the form of a 32-bit value that indicates a Flood Reflection
   Preference value to be used during Flood Reflector election
   procedures with the higher value being preferred.  Auto-FR capable
   nodes MUST support this extension.

   The appendix (Appendix B) details necessary changes to the
   NodeTIEElement Thrift schemas.

3.3.2.5.  IS-IS System ID

   Auto-FR nodes MUST derive a unique 6-byte IS-IS System ID for use in
   deriving the IS-IS NET Address.  Calculation is done using the 8-byte
   RIFT System ID and 4-byte Cluster ID.

Head, et al.              Expires 14 April 2025                 [Page 9]
Internet-Draft               RIFT Auto IS-IS                October 2024

   In order for nodes to derive an IS-IS System ID, the following
   algorithms are required - auto_fr_cidsid2isissid (Figure 11) and
   auto_fr_v6hash (Figure 16).

3.3.2.6.  IS-IS NET Address

   Auto-FR nodes MUST derive a unique 10-byte IS-IS NET (Network Entity
   Title) Address to uniquely identify itself within the Flood
   Reflection topology.  The 1st byte (which indicates the AFI) MUST
   have a value of "49".  The last byte (i.e. the NSEL) MUST have a
   value of 0.  Remaining calculation is done using the 8-byte RIFT
   System ID and 4-byte Cluster ID.

   In order for nodes to derive an IS-IS NET Address, the following
   algorithms are required - auto_fr_cidsid2isisnet (Figure 10) and
   auto_fr_cidsid2isissid (Figure 11).

3.3.2.7.  Loopback Address

   Auto-FR nodes MUST derive a ULA-scoped IPv6 loopback address to be
   used in IS-IS.  Calculation is done using the 6-bytes of reserved ULA
   space, the 4-byte Cluster ID, and the node's 8-byte RIFT System ID.
   Derivation of the IS-IS System ID varies slightly depending upon the
   node's location/role in the fabric and will be described in
   subsequent sections.

3.3.2.7.1.  Leaf Nodes as Flood Reflector Clients

   Leaf Nodes acting as Flood Reflector Clients MUST derive their
   loopback address according to the specific section describing the
   algorithm.  Calculation is done using the 6-bytes of reserved ULA
   space, the 4-byte Cluster ID, and the 8-byte RIFT System ID.

   In order for leaf nodes to derive IPv6 loopbacks, the following
   algorithms are required - auto_fr_cidsidv6loopback (Figure 13) and
   auto_fr_v6prefixcidsid2loopback (Figure 17).

   IPv4 addresses MAY be supported, but it should be noted that they
   have a higher likelihood of collision.  The appendix contains the
   required auto_fr_cidsid2v4loopback (Figure 12) algorithm to support
   IPv4 loopback derivation.

3.3.2.7.2.  ToF Nodes as Flood Reflectors

   ToF nodes acting as Flood Reflectors MUST derive their loopback
   address according to the specific section describing the algorithm.
   Calculation is done using the 6-bytes of reserved ULA space, the
   4-byte Cluster ID, and the 8-byte RIFT System ID.

Head, et al.              Expires 14 April 2025                [Page 10]
Internet-Draft               RIFT Auto IS-IS                October 2024

   In order for ToF nodes to derive IPv6 loopbacks, the following
   algorithms are required - auto_fr_cidsidv6loopback (Figure 13),
   auto_fr_v6prefixcidsid2loopback (Figure 17), and
   auto_fr_cidfrpref2frv6loopback (Figure 9).

   IPv4 addresses MAY be supported, but it should be noted that they
   have a higher likelihood of collision.  The appendix contains the
   required auto_fr_cidfrpref2frv4loopback (Figure 8) algorithm to
   support IPv4 loopback derivation.

3.3.2.7.2.1.  Flood Reflector Election Procedures

   Each ToF performs the election independently based on the RIFT System
   IDs and a Flood Reflection preference value of other ToF nodes in the
   fabric obtained via southbound reflection.  The Flood Reflector
   election procedures are defined as follows:

   1.  Highest System ID with the highest preference.

   2.  Lowest System ID with the highest preference.

   3.  2nd highest System ID with the 2nd highest preference.

   4.  etc.

   This ordering is necessary to prevent a single node with either the
   highest or lowest System ID from triggering changes to flood
   reflector loopback addresses as it would result in all IS-IS
   adjacencies flapping.

   For example, if ToF01 (System ID: 002c6af5a281c000 / FR Preference:
   100) and ToF02 (System ID: 002c6bf5788fc000 / FR Preference: 1) went
   through the election process, ToF02 would be elected due to it having
   the highest System ID.  If a ToF determines that it is elected as a
   Flood Reflector, it uses the knowledge of its position in the list to
   derive Flood Reflector IPv6 loopback address.

   A topology MUST elect at least 1 ToF node as an IS-IS Flood
   Reflector, but SHOULD elect 3.  The election process varies depending
   upon whether or not the topology is comprised of a single plane or
   multiple planes.  The multiplane election procedure will be described
   in a future version of this document.

   The algorithm shown in "auto_fr_sids2frs" (Figure 14) is required to
   perform the Flood Reflector election procedures.

4.  RIFT Requirements

Head, et al.              Expires 14 April 2025                [Page 11]
Internet-Draft               RIFT Auto IS-IS                October 2024

4.1.  RIFT FSM / LIE Validation Requirements

   RIFT FSM adjacency rules MUST consider Auto-FR Version
   (Section 3.3.2.2) and Auto-FR Cluster ID (Section 3.3.2.3) values so
   that nodes that do not support Auto-FR can interoperate with nodes
   that do.  The LIE validation is extended with the following clause
   and if it is not met, miscabling should be declared:

   (if auto_flood_reflection_version is not advertised by either node OR
    if auto_flood_reflection_version is identical on both nodes)
       AND
   (auto_flood_reflection_cluster_id is not advertised by either node OR
    auto_flood_reflection_cluster_id is identical on both nodes)

4.2.  RIFT Node-TIE Advertisements

   All nodes utilizing Auto-FR MUST advertise their Auto-FR Version
   (Section 3.3.2.2), Flood Reflection Cluster ID (Section 3.3.2.3), and
   Flood Reflection Preference (Section 3.3.2.4) values in at least one
   Node-TIE in each direction (i.e.  North and South).

5.  Operational Considerations

   To fully realize the benefits of Auto-IS-IS, it may help to describe
   the high-level method.  Simply put, RIFT automatically provisions the
   underlay and Auto-IS-IS or Auto-FR provisions the specific topology.
   The goal of this section is to draw simple lines between general
   fabric concepts, RIFT, and Auto-IS-IS and how they fit into current
   network designs and practices.

   This section also describes a set of optional Key-Value TIEs
   [RIFT-KV] that leverages the variables that have already been derived
   to provide further operational enhancement to the operator.

5.1.  RIFT Underlay with an IS-IS Flood Reflection Topology

Head, et al.              Expires 14 April 2025                [Page 12]
Internet-Draft               RIFT Auto IS-IS                October 2024

                      +-----------------+   +-----------------+
                      | ToF-01          |   | ToF-02          |
                      | L1 / L2         |   | L1 / L2         |  ]----------------------+
                      | Flood Reflector |   | Flood Reflector |                         |
                      +-+--+------+--+--+   +-+--+------+--+--+                         |
                        |  |      |  |        |  |      |  |                            |
  +---------------------+  |      |  |        |  |      |  |                            |
  |                        |      |  |        |  |      |  +---------------------+      |
  |            +-----------)------)--)--------+  |      |                        |      |
  |            |           |      |  |   +-------+      |                        |      |
  |            |           |      |  |   |              |                        |      |
  |            |           |      |  +---)--------------)-----------+            |      |
  |            |           |      |      |              |           |            |      |
  |            |        +--+      +------)----+         +--+        |            |      |
  |            |        |                |    |            |        |            |      |
  |            |        |            +---+    |            |        |            |      | Level 2 Mesh of
  |            |        |            |        |            |        |            |      | Flood Reflection
+-+------------+-+    +-+------------+-+    +-+------------+-+    +-+------------+-+    | Adjacencies
| Spine-1-1      |    | Spine-1-2      |    | Spine-2-1      |    | Spine-2-2      |    | Between ToFs/Leafs
| L1             |    | L1             |    | L1             |    | L1             |    |
| N/A            |    | N/A            |    | N/A            |    | N/A            |    |
+--+----------+--+    +--+----------+--+    +--+----------+--+    +--+----------+--+    |
   |          |          |          |          |          |          |          |       |
   |          +----------)---+      |          |          +----------)---+      |       |
   |                     |   |      |          |                     |   |      |       |
   |          +----------+   |      |          |          +----------+   |      |       |
   |          |              |      |          |          |              |      |       |
+--+----------+--+    +------+------+--+    +--+----------+--+    +------+------+--+    |
| Leaf-1-1       |    | Leaf-1-2       |    | Leaf-2-1       |    | Leaf-2-2       |    |
| L1 / L2        |    | L1 / L2        |    | L1 / L2        |    | L1 / L2        |  ]-+
| FR Client      |    | FR Client      |    | FR Client      |    | FR Client      |
+--+-------------+    +--------------+-+    +--+-------------+    +----------------+
   |                                           |
   |                                           |
   |                                           |
   |                                           |
+--+-------------+                          +--+-----------+-+
| Node A         |                          | Node Z         |
| L2             |                          | L2             |
+----------------+                          +----------------+

                  Figure 1: Auto-FR Example Topology

   Figure 1 illustrates a typical 5-stage Clos IP fabric.  Each node is
   named and labelled in such a way that conveys:

   1.  The node's generic placement within the context of the RIFT
       underlay

Head, et al.              Expires 14 April 2025                [Page 13]
Internet-Draft               RIFT Auto IS-IS                October 2024

   2.  The node's level(s) within the IS-IS area.

   3.  The node's role within the IS-IS Flood Reflection topology.

   Table 1 should help further align these concepts.

         +================+=============+========================+
         | RIFT Placement | IS-IS Level | IS-IS FR Role          |
         +================+=============+========================+
         | ToF Nodes      | L1/L2       | Flood Reflector        |
         +----------------+-------------+------------------------+
         | Spine Nodes    | L1          | N/A                    |
         +----------------+-------------+------------------------+
         | Leaf Nodes     | L1/L2       | Flood Reflector Client |
         +----------------+-------------+------------------------+

                         Table 1: Role Associations

   Connections between various nodes can be understood in two different
   ways:

   1.  Lines between ToF and leaf nodes are Level 2 IS-IS Flood
       Reflection adjacencies.

   2.  Lines between spine and leaf are part of the physically connected
       underlay.

   3.  Lines between ToF and spine are part of the physically connected
       underlay.

   It is important to remember that Auto-FR is not altering the way in
   which IS-IS Flood Reflection operates in any way, it simply takes
   existing deployment scenarios and simplifies the provisioning
   process.

5.2.  Auto-FR Analytics

   Leaf nodes MAY optionally advertise analytics information about the
   Auto-FR fabric to ToF nodes using RIFT Key-Value TIEs [RIFT-KV].
   This may be helpful in that validation and troubleshooting activities
   can be performed on the ToF nodes rather than manually verifying the
   state separately on multiple leaf nodes.

Head, et al.              Expires 14 April 2025                [Page 14]
Internet-Draft               RIFT Auto IS-IS                October 2024

5.2.1.  Auto-FR Analytics (Global) Key/Value Pair

   This Key/Value pair describes node level information within the
   context of the Flood Reflection topology.  The RIFT System ID of the
   advertising leaf node MUST be used to differentiate the node among
   other nodes in the fabric.

   The Auto-FR Analytics (Global) Key/Value pair MUST be advertised with
   the Key Identifier consisting of all 0s.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Well-Known   |  Auto-FR Glb  |          All Zeros            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     (Auto-FR Role,                                            |
     |      Flood Reflection Cluster ID,                             |
     |      Established IS-IS FR L2 Adjacencies,                     |
     |      Total IS-IS FR L2 Adjacencies,                           |
     |      Established IS-IS FR L1 Shortcut Adjacencies,            |
     |      Total IS-IS FR L1 Shortcut Adjacencies,                  |
     |      Established IS-IS L1 Adjacencies,                        |
     |      Total IS-IS L1 Adjacencies,)                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Auto-FR Global Key/Value Pair

   *where:*

      *Auto-FR Role:*
         A REQUIRED value indicating the node's Auto-FR role within the
         fabric.

         *0:*  Illegal value, MUST NOT be used.

         *1:*  Auto-FR Flood Reflector Client

         *2:*  Auto-FR Flood Reflector

         *3:*  Auto-FR Spine (i.e. a non-ToF / non-Leaf node)

      *Auto-FR Cluster ID*
         A REQUIRED 32-bit integer indicating the Auto-FR Cluster ID of
         the local node.

Head, et al.              Expires 14 April 2025                [Page 15]
Internet-Draft               RIFT Auto IS-IS                October 2024

      *Established IS-IS Flood Reflector Adjacency Count*
         A RECOMMENDED 16-bit integer indicating the number of IS-IS
         Level 2 Flood Reflector adjacencies in the "Up" state on the
         local node.

      *Total IS-IS Flood Reflector Adjacency Count*
         A RECOMMENDED 16-bit integer indicating the total number of IS-
         IS Level 2 Flood Reflector adjacencies on the local node
         regardless of state.

      *Established IS-IS Level 1 Shortcut Count*
         A RECOMMENDED 16-bit integer indicating the number of
         functional IS-IS Level 1 "shortcuts" on the local node.

      *Total IS-IS Level 1 Shortcut Count*
         A RECOMMENDED 16-bit integer indicating the total number of IS-
         IS Level 1 "shortcuts" the local node regardless of state.

      *Established IS-IS Level 1 Adjacency Count*
         A RECOMMENDED 16-bit integer indicating the number of IS-IS
         Level 1 adjacencies in the "Up" state on the local node.

      *Total IS-IS Level 1 Adjacency Count*
         A RECOMMENDED 16-bit integer indicating the total number of IS-
         IS Level 1 adjacencies on the local node regardless of state.

   Implementations leveraging Thrift for Key-Value functionality SHOULD
   refer to the auto_flood_reflection_kv.thrift (Appendix C) schema in
   the appendix.

6.  IANA Considerations

   This section requests the following suggested values from the RIFT
   Well-Known Key-Type Registry.

     +=======+===========+==============================+===========+
     | Value | Key Sub-  | Description                  | Status/   |
     |       | Type      |                              | Reference |
     +=======+===========+==============================+===========+
     | 5     | Auto-FR   | Key/Value pair containing    | This      |
     |       | Analytics | operational state of a Flood | document. |
     |       | (Global)  | Reflector Client node.       |           |
     +-------+-----------+------------------------------+-----------+

       Table 2: Auto-FR Suggested Value(s) for RIFT Well-Known Key-
                              Type Registry

Head, et al.              Expires 14 April 2025                [Page 16]
Internet-Draft               RIFT Auto IS-IS                October 2024

7.  Security Considerations

   This document introduces no new security concerns to RIFT or other
   specifications referenced in this document as RIFT natively secures
   LIE and TIE packets as described in [RIFT].

8.  Acknowledgements

   This section will be used to acknowledge major contributors.

9.  References

9.1.  Normative References

   [ISO10589] ISO, "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>.

   [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>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", June
              2017, <https://www.rfc-editor.org/info/rfc8126>.

   [RFC9377]  Przygienda, T., Ed., Bowers, C., Lee, Y., Sharma, A., and
              R. White, "IS-IS Flood Reflection", RFC 9377,
              DOI 10.17487/RFC9377, April 2023,
              <https://www.rfc-editor.org/info/rfc9377>.

   [RIFT]     Przygienda, T., Head, J., Sharma, A., Thubert, P.,
              Rijsman, B., and D. Afanasiev, "RIFT: Routing in Fat
              Trees", Work in Progress draft-ietf-rift-rift-24, June
              2024, <https://www.ietf.org/archive/id/draft-ietf-rift-
              rift-18.html>.

   [RIFT-KV]  Head, J. and T. Przygienda, "RIFT Key/Value TIE Structure
              and Processing", Work in Progress, draft-ietf-rift-kv-tie-
              structure-and-processing-01, July 2024.

Appendix A.  YANG Model

   This section serves as a placeholder for a YANG model supporting RIFT
   Auto-IS-IS and Auto-FR.

Head, et al.              Expires 14 April 2025                [Page 17]
Internet-Draft               RIFT Auto IS-IS                October 2024

Appendix B.  Thrift Models

   This section contains the normative Thrift models required to support
   Auto-FR.  Per the main RIFT [RIFT] specification, all signed values
   MUST be interpreted as unsigned values.

B.1.  common.thrift

   This section specifies extensions to RIFT common.thrift model.

   These extensions are REQUIRED in order to support Auto-FR.

  ...
  enum AutoFRModel {
      TunnelMode      = 0,
      NoTunnelMode    = 1,
  }

  const AutoFRModel default_autofr_model = AutoFRModel.TunnelMode

  typedef i32          FloodReflectionClusterIDType

  const FloodReflectionClusterIDType  IllegalClusterID = 0
  const FloodReflectionClusterIDType  DefaultClusterID  = 1

  /// preference to become FR, higher is better
  typedef i32          FloodReflectionPreferenceType

  const   FloodReflectionPreferenceType MinFloodReflectionPreference = 0

  ...

                  Figure 3: RIFT Auto-FR: common.thrift

B.2.  encoding.thrift

   This section specifies extensions to RIFT encoding.thrift model.

   These extensions are REQUIRED in order to support Auto-FR.

Head, et al.              Expires 14 April 2025                [Page 18]
Internet-Draft               RIFT Auto IS-IS                October 2024

struct NodeCapabilities {
...
   /** indicates whether auto-flood-reflection feature is implemented on this node (but not necessarily enabled). */
   20: optional bool                           auto_flood_reflection_support = false;
...
}

struct LIEPacket {
...
   /** It provides optional version of FR ZTP as 256 * MAJOR + MINOR, indicates support for auto FR  */
   40: optional i16                                      auto_flood_reflection_version;

   41: optional common.FloodReflectionClusterIDType      auto_flood_reflection_cluster_id;
...
}

struct NodeTIEElement {
...
   /** All Auto FR elements MUST be present in at least one TIE in each direction if auto FR is running.  */
   /** It provides optional version of FR ZTP as 256 * MAJOR + MINOR, indicates support for auto FR  */
   30: optional i16                                     auto_flood_reflection_version;
   /** cluster ID of Auto FR */
   31: optional common.FloodReflectionClusterIDType     auto_flood_reflection_cluster_id;
   /** preference to become FR */
   32: optional common.FloodReflectionPreferenceType    auto_flood_reflection_preference;
...
}

               Figure 4: RIFT Auto-FR: encoding.thrift

B.3.  common_flood_reflection.thrift

   This section specifies common_flood_reflection.thrift as a normative
   THrift model to support core functionality for Auto-FR.

   These extensions are REQUIRED in order to support Auto-FR.

namespace py common_flood_reflection
namespace rs models

include "common.thrift"
include "encoding.thrift"

typedef     binary      ISISSystemIDType
typedef     binary      ISISL1NetType

struct AutoFRAnyRole {
    /** common loopback for all nodes */

Head, et al.              Expires 14 April 2025                [Page 19]
Internet-Draft               RIFT Auto IS-IS                October 2024

    1: required   common.IPv6Address                    v6_loopback,
    /** ISIS L1! loopback in 10.* range, may NOT be collision free due to limited # of bytes */
    2: required   common.IPv4Address                    v4_loopback,
    4: required   ISISSystemIDType                      isis_sysid,
    5: required   ISISL1NetType                         isis_net,

   10: required   common.FloodReflectionClusterIDType   fr_cluster_id,

    /** v6 loopback prefix range, used e.g. to clean up config  */
   20: required   common.IPv6PrefixType                 v6_loopback_range,
    /** v6 loopback prefix range of FR reflector loopbacks, used e.g. to clean up config  */
   21: required   common.IPv6PrefixType                 fr_loopback_range,
    /** v6 addresses of all possible FR reflector loopbacks in this config. Can be used for e.g. cleanup */
   24: required   set<common.IPv6PrefixType>            possible_elected_frs,

   25: required   common.IPv4PrefixType                 v4_loopback_range,
}

struct AutoFRReflectorRole {
    1: required   common.IPv6Address                    v6_fr_addr_loopback,
}

struct AutoFRLeafRole {
    1: optional   i8                                    empty_placeholder,
}

struct AutoFRRoles {
    1: required  AutoFRAnyRole                          generic,
    2: optional  AutoFRReflectorRole                    flood_reflector,
    3: optional  AutoFRLeafRole                         leaf,
}

/// default delay before FR FSM starts to compute anything
const common.TimeIntervalInSecType          default_autofr_startup_delay = 10

/// default preference to become FR
const common.FloodReflectionPreferenceType  default_autofr_preference = 0

        Figure 5: RIFT Auto-FR: common_flood_reflection.thrift

Appendix C.  auto_flood_reflection_kv.thrift

   This section defines auto_flood_reflection_kv.thrift as a method of
   supporting Auto-FR analytics functionality.

Head, et al.              Expires 14 April 2025                [Page 20]
Internet-Draft               RIFT Auto IS-IS                October 2024

include "common.thrift"

namespace py auto_flood_reflection_kv
namespace rs models

const i8            AutoFRWellKnownKeyType  = 1
typedef i32         AutoFRKeyIdentifier
typedef i16         AutoFRCounterType
typedef i32         AutoFRLongCounterType

const i8            GlobalAutoFRTelemetryKV  = 5

/** We don't need the full role structure, only an indication of the node's basic role */
enum AutoFRRole {
    ILLEGAL            = 0,
    auto_fr_leaf       = 1,
    auto_fr_reflector  = 2,
    auto_fr_spine      = 3, // i.e. non-(ToF|Leaf)
}

/** Auto-FR Global (Node) Telemetry

    1st     byte  MUST be = "Well-Known"
    2nd     byte  MUST be = "GlobalAutoFRTelemetryKV"
    3rd/4th bytes MUST be = all 0s

    Flooding Scope: Leaves only
*/
struct AutoFRTelemetryGlobalKV {
    1: required   set<AutoFRRole>                           auto_fr_roles,
    2: required   common.FloodReflectionClusterIDType       cluster_id,

    3: optional   AutoFRCounterType                         established_isis_fr_adjacencies_count,

    4: optional   AutoFRCounterType                         total_isis_fr_adjacencies_count,

    5: optional   AutoFRCounterType                         established_isis_l1_shortcut_adjacencies_count,

    6: optional   AutoFRCounterType                         total_isis_l1_shortcut_adjacencies_count,

    7: optional   AutoFRCounterType                         established_isis_l1_adjacencies_count,

    8: optional   AutoFRCounterType                         total_isis_l1_adjacencies_count,
}

       Figure 6: RIFT Auto-FR: auto_flood_reflection_kv.thrift

Head, et al.              Expires 14 April 2025                [Page 21]
Internet-Draft               RIFT Auto IS-IS                October 2024

Appendix D.  Auto-FR Variable Derivation

   This section contains the normative variable derivation algorithms
   that are REQUIRED to support Auto-FR.

/// indicates how many FRs we're computing in AUTO FR
pub const MAX_AUTO_FR_FRS: usize = 3;

/// indicates the cluster has no ID, used in computations to omit effects of cluster ID
pub const NO_CLUSTER_ID: UnsignedFloodReflectionClusterIDType = 0;

/// unique v6 prefix for all nodes starts with this
pub fn auto_fr_v6pref(cid: UnsignedFloodReflectionClusterIDType) -> String {
    format!("FD00:{:04X}:B1", cid)
}

/// how many bytes in a v6pref for different purposes
pub const AUTO_FR_V6PREFLEN: usize = 8 * 5;

/// unique v6 prefix for flood reflector purposes starts like this
pub fn auto_fr_v6frpref(cid: UnsignedFloodReflectionClusterIDType) -> String {
    format!("FD00:{:04X}:B2", cid)
}

/// unique v4 prefix for IRB purposes
pub const AUTO_FR_V4LOOPBACKNET: u8 = 10;
pub const AUTO_FR_V4LOOPBACKMASK : usize = 8;

         Figure 7: RIFT Auto-FR: auto_fr_const_structs_types

/// auto FR V4 loopback for FRs
pub fn auto_fr_cidfrpref2frv4loopback(_cid: UnsignedFloodReflectionClusterIDType,
                                    preference: u8) -> Result<IPv4Address, ServiceErrorType> {
    if preference > MAX_AUTO_FR_FRS as _ {
        Err(ServiceErrorType::INTERNALRIFTERROR)
    } else {
        let m = ((AUTO_FR_V4LOOPBACKNET as IPv4Address) << (32 - AUTO_FR_V4LOOPBACKMASK)) | (preference as IPv4Address);
        Ok(m)
    }
}

        Figure 8: RIFT Auto-FR: auto_fr_cidfrpref2frv4loopback

/// auto FR V6 loopback for FRs
pub fn auto_fr_cidfrpref2frv6loopback(cid: UnsignedFloodReflectionClusterIDType,
                                      preference: u8) -> Result<Ipv6Addr, ServiceErrorType> {
    auto_fr_v6prefixcidsid2loopback(&auto_fr_v6frpref(cid), cid, (1 + preference) as _)
}

Head, et al.              Expires 14 April 2025                [Page 22]
Internet-Draft               RIFT Auto IS-IS                October 2024

        Figure 9: RIFT Auto-FR: auto_fr_cidfrpref2frv6loopback

pub fn auto_fr_cidsid2isisnet(cid: UnsignedFloodReflectionClusterIDType, sid: UnsignedSystemID) -> Vec<u8> {
    let mut r = vec![0x49]; // magic AFI

    // area ID derived from cluster ID
    r.extend(&cid.to_ne_bytes().iter().fold(0x77u16,
                                            |prev, val| (prev ^ (val.rotate_right(4) as u16))).to_ne_bytes());
    // ISIS ID derived from system ID + cid/sid
    r.extend(auto_fr_cidsid2isissid(cid, sid).into_iter());
    // selector non v-node
    r.push(0);

    r
}

           Figure 10: RIFT Auto-FR: auto_fr_cidsid2isisnet

   /// ISIS system ID derivation
   pub fn auto_fr_cidsid2isissid(
       cid: UnsignedFloodReflectionClusterIDType,
       sid: UnsignedSystemID) -> Vec<u8> {

       let sb = auto_fr_v6hash(cid, sid);

       vec![sb[0],
            sb[1],
            sb[2],
            sb[3],
            sb[4] ^ sb[5].rotate_right(4),
            sb[6] ^ sb[7].rotate_right(4),
       ]
   }

              Figure 11: RIFT Auto-FR: auto_fr_cidsid2isissid

Head, et al.              Expires 14 April 2025                [Page 23]
Internet-Draft               RIFT Auto IS-IS                October 2024

/// v4 loopback address derivation for every node in auto-flood-reflection, returns address
pub fn auto_fr_cidsid2v4loopback(cid: UnsignedFloodReflectionClusterIDType, sid: UnsignedSystemID) -> IPv4Address {
    let mut derived = sid.to_ne_bytes().iter()
        .fold(0 as IPv4Address, |p, e| (p << 4) ^ (*e as IPv4Address));
    derived ^= cid as IPv4Address;
    // use the byte we loose for entropy
    derived ^= derived >> (32 - AUTO_FR_V4LOOPBACKMASK);
    // and sanitize for loopback range, we nuke 8 bits out
    derived &= (!U32MASKS[AUTO_FR_V4LOOPBACKMASK]) as IPv4Address;

    let (frpr, frm) = auto_fr_v4frpref(cid);
    let v4m = U32MASKS[frm as usize];

    let mut m = ((AUTO_FR_V4LOOPBACKNET as IPv4Address) << (32 - AUTO_FR_V4LOOPBACKMASK)) | derived;

    // collision with elected FR v4 prefixes, rederive
    if (m & v4m as IPv4Address) == frpr {
        derived ^= IPv4Address::MAX;
        derived &= (!U32MASKS[AUTO_FR_V4LOOPBACKMASK]) as IPv4Address;
        m = ((AUTO_FR_V4LOOPBACKNET as IPv4Address) << (32 - AUTO_FR_V4LOOPBACKMASK)) | derived;
    }

    m as _
}

          Figure 12: RIFT Auto-FR: auto_fr_cidsid2v4loopback

/// V6 loopback derivation for every node in auto fr
pub fn auto_fr_cidsidv6loopback(cid: UnsignedFloodReflectionClusterIDType,
                                  sid: UnsignedSystemID) -> Result<Ipv6Addr, ServiceErrorType> {
    auto_fr_v6prefixcidsid2loopback(&auto_fr_v6pref(cid), cid, sid)
}

          Figure 13: RIFT Auto-FR: auto_fr_cidsidv6loopback

Head, et al.              Expires 14 April 2025                [Page 24]
Internet-Draft               RIFT Auto IS-IS                October 2024

/// Function sorts vector of systemIDs first,
/// Followed by a shuffle taking largest/smallest/2nd largest/2nd smallest.
/// Preference is used to take the according subsets to run this algorithm
/// sequentially.
pub(crate) fn auto_fr_sids2frs(mut v: Vec<(FloodReflectionPreferenceType,
                                           UnsignedSystemID)>)
                                 -> Vec<UnsignedSystemID> {
    v.par_sort_by(|(p1, s1),
                   (p2, s2)|
        match p2.cmp(p1) {
            Ordering::Equal => s2.cmp(s1),
            e @ _ => e
        });

    let mut elected = vec![];

    while elected.len() < MAX_AUTO_FR_FRS && !v.is_empty() {
        let pref = (&v[0]).0;

        let mut splitat = 0;
        while splitat < v.len() && (&v[splitat]).0 == pref {
            splitat += 1;
        }

        let mut so = v.split_off(splitat);
        std::mem::swap(&mut v, &mut so);

        let mut mixed = if so.len() > 2 {
            let mut s = so.split_off(so.len() / 2);
            s.reverse();
            interleave(so.into_iter(), s.into_iter())
                .collect::<Vec<_>>()
        } else {
            so
        };

        elected.extend(mixed.drain(..))
    }

    elected.drain(..).map(|(_, sid)| sid).collect()
}

              Figure 14: RIFT Auto-FR: auto_fr_sids2frs

   pub(crate) fn auto_fr_v62octets(a: Ipv6Addr) -> Vec<u8> {
       a.octets().iter().cloned().collect()
   }

Head, et al.              Expires 14 April 2025                [Page 25]
Internet-Draft               RIFT Auto IS-IS                October 2024

                 Figure 15: RIFT Auto-FR: auto_fr_v62octets

/// generic bytes derivation used for different purposes
pub fn auto_fr_v6hash(cid: UnsignedFloodReflectionClusterIDType, sid: UnsignedSystemID)
                        -> [u8; 8] {
    let sub = (cid as UnsignedSystemID) ^ sid.rotate_right(8);

    sub.to_ne_bytes()
}

               Figure 16: RIFT Auto-FR: auto_fr_v6hash

/// local address with encoded cluster ID and system ID for collision free identifiers. Basis
/// for several different prefixes.
pub fn auto_fr_v6prefixcidsid2loopback(v6pref: &str, cid: UnsignedFloodReflectionClusterIDType,
                                       sid: UnsignedSystemID) -> Result<Ipv6Addr, ServiceErrorType> {
    assert!(cid != ILLEGAL_CLUSTER_I_D as _);
    let a = format!("{}00::{}",
                    v6pref,
                    sid.to_ne_bytes()
                        .iter()
                        .chunks(2)
                        .into_iter()
                        .map(|chunk|
                            chunk.fold(0u16, |v, n| (v << 8) | *n as u16))
                        .map(|v| format!("{:04X}", v))
                        .collect::<Vec<_>>()
                        .into_iter()
                        .join(":")
    );

    Ipv6Addr::from_str(&a)
        .map_err(|_| ServiceErrorType::INTERNALRIFTERROR)
}

       Figure 17: RIFT Auto-FR: auto_fr_v6prefixcidsid2loopback

Head, et al.              Expires 14 April 2025                [Page 26]
Internet-Draft               RIFT Auto IS-IS                October 2024

/// cluster prefixes derived instead of advertising default on the cluster to allow
/// for default route on ToF or leaves
pub fn auto_fr_cid2cluster_prefixes(cid: UnsignedFloodReflectionClusterIDType) -> Result<Vec<IPPrefixType>, ServiceErrorType> {
    vec![
        (auto_fr_cidsidv6loopback(cid, ILLEGAL_SYSTEM_I_D as _), AUTO_FR_V6PREFLEN),
        (auto_fr_cidfrpref2frv6loopback(cid, 0 as _), AUTO_FR_V6PREFLEN),
    ]
        .into_iter()
        .map(|(p, _)|
            match p {
                Ok(_) => Ok(
                    IPPrefixType::Ipv6prefix(
                        IPv6PrefixType {
                            address: auto_fr_v62octets(p?),
                            prefixlen: AUTO_FR_V6PREFLEN as _,
                        })),
                Err(e) => Err(e),
            }
        )
        .collect::<Result<Vec<_>, _>>()
}

        Figure 18: RIFT Auto-FR: auto_fr_cid2cluster_prefixes

Appendix E.  Auto-IS-IS Variable Derivation

   This section serves as a placeholder for what will be the REQUIRED
   normative algorithms for deriving the necessary variables in an Auto-
   IS-IS topology.

Authors' Addresses

   Jordan Head (editor)
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA
   United States of America
   Email: jhead@juniper.net

   Tony Przygienda
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA
   United States of America
   Email: prz@juniper.net

Head, et al.              Expires 14 April 2025                [Page 27]
Internet-Draft               RIFT Auto IS-IS                October 2024

   Colby Barth
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA
   United States of America
   Email: cbarth@juniper.net

   Luis Tomotaki
   Verizon
   400 International Parkway
   Richardson, TX
   United States of America
   Email: luis.tomotaki@verizon.com

   Brant Brockdorff
   Verizon
   899 Heathrow Park Lane
   Lake Mary, FL
   United States of America
   Email: brant.brockdorff@verizon.com

Head, et al.              Expires 14 April 2025                [Page 28]