rfc9719v1.txt   rfc9719.txt 
Internet Engineering Task Force (IETF) Z. Zhang Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 9719 Y. Wei Request for Comments: 9719 Y. Wei
Category: Standards Track ZTE Corporation Category: Standards Track ZTE Corporation
ISSN: 2070-1721 S. Ma ISSN: 2070-1721 S. Ma
Google Google
X. Liu X. Liu
Alef Edge
B. Rijsman B. Rijsman
Individual Individual
January 2025 March 2025
YANG Data Model for Routing in Fat Trees (RIFT) YANG Data Model for Routing in Fat Trees (RIFT)
Abstract Abstract
This document defines a YANG data model for the configuration and This document defines a YANG data model for the configuration and
management of the Routing in Fat Trees (RIFT) Protocol. The model is management of the Routing in Fat Trees (RIFT) Protocol. The model is
based on YANG 1.1, which is defined in RFC 7950 and conforms to the based on YANG 1.1, which is defined in RFC 7950 and conforms to the
Network Management Datastore Architecture (NMDA) as described in RFC Network Management Datastore Architecture (NMDA) as described in RFC
8342. 8342.
skipping to change at line 90 skipping to change at line 89
augments the ietf-routing YANG data model defined in [RFC8349]. augments the ietf-routing YANG data model defined in [RFC8349].
1.1. Terminology 1.1. Terminology
The following terminology and abbreviations are used in this document The following terminology and abbreviations are used in this document
and the defined model. and the defined model.
The content is copied from [RFC9692] for reading convenience. The content is copied from [RFC9692] for reading convenience.
Clos / Fat Tree: Clos / Fat Tree:
It refers to a folded spine-and-leaf topology with possibly This document uses the terms "Clos" and "Fat Tree" interchangeably
multiple Points of Delivery (PoDs) and one or multiple Top of where it always refers to a folded spine-and-leaf topology with
Fabric (ToF) planes. possibly multiple Points of Delivery (PoDs) and one or multiple
Top of Fabric (ToF) planes.
RIFT: RIFT:
Routing in Fat Trees [RFC9692]. Routing in Fat Trees [RFC9692].
LIEs: LIE:
"Link Information Elements" are exchanged on all the system's This is an acronym for a "Link Information Element" exchanged on
links running RIFT to form ThreeWay adjacencies and carry all the system's links running RIFT to form _ThreeWay_ adjacencies
information used to perform Zero Touch Provisioning (ZTP) of and carry information used to perform RIFT Zero Touch Provisioning
levels. (ZTP) of levels.
PoD: Point of Delivery (PoD):
"Point of Delivery" means a self-contained vertical slice or A self-contained vertical slice or subset of a Clos or Fat Tree
subset of a Clos or Fat Tree network normally containing only network normally containing only level 0 and level 1 nodes. A
level 0 and level 1 nodes. A node in a PoD communicates with node in a PoD communicates with nodes in other PoDs via the ToF
nodes in other PoDs via the ToF nodes. PoDs are numbered to nodes. PoDs are numbered to distinguish them, and PoD value 0 is
distinguish them, and PoD value 0 is used to denote "undefined" or used to denote "undefined" or "any" PoD.
"any" PoD.
ThreeWay Adjacency: ThreeWay Adjacency:
A unique adjacency between two nodes over a point-to-point RIFT tries to form a unique adjacency between two nodes over a
interface and exchange local configuration and necessary RIFT ZTP point-to-point interface and exchange local configuration and
information. An adjacency is only advertised in Node TIEs and necessary RIFT ZTP information. An adjacency is only advertised
used for computations after it achieved ThreeWay state, i.e., both in Node TIEs and used for computations after it achieved
routers reflected each other in LIEs, including relevant security _ThreeWay_ state, i.e., both routers reflected each other in LIEs,
information. Nevertheless, LIEs before ThreeWay state is reached including relevant security information. Nevertheless, LIEs
may carry RIFT ZTP related information already. before _ThreeWay_ state is reached may carry RIFT ZTP related
information already.
TIEs: TIEs:
"Topology Information Elements" are exchanged between RIFT nodes This is an acronym for a "Topology Information Element". TIEs are
to describe parts of a network such as links and address prefixes. exchanged between RIFT nodes to describe parts of a network such
A TIE has always a direction and a type. North TIEs (sometimes as links and address prefixes. A TIE has always a direction and a
abbreviated as N-TIEs) are used when dealing with TIEs in the type. North TIEs (sometimes abbreviated as N-TIEs) are used when
northbound representation, and South TIEs (sometimes abbreviated dealing with TIEs in the northbound representation, and South TIEs
as S-TIEs) for the southbound equivalent. TIEs have different (sometimes abbreviated as S-TIEs) for the southbound equivalent.
types, such as node and prefix TIEs. TIEs have different types, such as node and prefix TIEs.
ToF: Top of Fabric (ToF):
"Top of Fabric" is the set of nodes that provide inter-PoD The set of nodes that provide inter-PoD communication and have no
communication and have no northbound adjacencies, i.e., are at the northbound adjacencies, i.e., are at the "very top" of the fabric.
"very top" of the fabric. ToF nodes do not belong to any PoD and ToF nodes do not belong to any PoD and are assigned the default
are assigned the default PoD value to indicate the equivalent of PoD value to indicate the equivalent of "any" PoD.
"any" PoD.
1.2. Conventions Used in This Document 1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.3. Tree Diagrams 1.3. Tree Diagrams
skipping to change at line 219 skipping to change at line 218
The YANG data model defined in this document conforms to the Network The YANG data model defined in this document conforms to the Network
Management Datastore Architecture (NMDA) [RFC8342]. The operational Management Datastore Architecture (NMDA) [RFC8342]. The operational
state data is combined with the associated configuration data in the state data is combined with the associated configuration data in the
same hierarchy [RFC8407]. same hierarchy [RFC8407].
2.3. Overview 2.3. Overview
The RIFT YANG module defined in this document has all the common The RIFT YANG module defined in this document has all the common
building blocks for the RIFT protocol. building blocks for the RIFT protocol.
The RIFT YANG module augments the /routing/control-plane-protocols/
control-plane-protocol path defined in the ietf-routing module. This
model augments the routing module to add RIFT as a control-plane
protocol. It then offers the ability to create a list of instances,
which it does by declaring 'list rift'. Multiple instances of the
protocol are supported by the module by giving each instance a unique
name.
At a high level, the RIFT YANG model is organized into five elements: At a high level, the RIFT YANG model is organized into five elements:
base protocol configuration -- Configuration affecting RIFT base protocol configuration -- Configuration affecting RIFT
protocol-related operations. protocol-related operations.
interface configuration -- Configuration affecting the interface interface configuration -- Configuration affecting the interface
operations. operations.
neighbor status -- Information of neighbors. neighbor status -- Information of neighbors.
skipping to change at line 643 skipping to change at line 634
+--ro link-id? uint32 +--ro link-id? uint32
+--ro name if:interface-ref +--ro name if:interface-ref
+--ro neighbors* [system-id] +--ro neighbors* [system-id]
+--ro system-id system-id +--ro system-id system-id
+--ro node-level? level +--ro node-level? level
2.4. RIFT Configuration 2.4. RIFT Configuration
The RIFT configuration includes node global configuration and The RIFT configuration includes node global configuration and
interface configuration. Some features can be used to enhance interface configuration. Some features can be used to enhance
protocol, such as BFD [RFC5881], flooding-reducing (Section 6.3.9 of protocols, such as BFD [RFC5881] with flooding reduction
[RFC9692]). (Section 6.3.9 of [RFC9692]).
2.5. RIFT States 2.5. RIFT States
The state data nodes include node, interface, neighbor, and database The state data nodes include node, interface, neighbor, and database
information. information.
YANG actions are defined to clear the connection of one specific YANG actions are defined to clear the connection of one specific
neighbor on an interface, clear the connections of all neighbors on neighbor on an interface, clear the connections of all neighbors on
an interface, or clear some or all statistics. an interface, or clear some or all statistics.
2.6. Notifications 2.6. Notifications
Unexpected TIE and neighbor's layer error should be notified. Unexpected TIE and neighbor layer errors should be notified.
3. RIFT YANG Module 3. RIFT YANG Module
This module references [RFC9692], [RFC5881], [RFC6991], [RFC8177], This module references [RFC9692], [RFC5881], [RFC6991], [RFC8177],
[RFC8294], [RFC8343], [RFC8349], [RFC8505], and [IEEE8021AS]. [RFC8294], [RFC8343], [RFC8349], [RFC8505], and [IEEE8021AS].
<CODE BEGINS> file "ietf-rift@2025-01-15.yang" <CODE BEGINS> file "ietf-rift@2025-01-15.yang"
module ietf-rift { module ietf-rift {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-rift"; namespace "urn:ietf:params:xml:ns:yang:ietf-rift";
skipping to change at line 806 skipping to change at line 797
"RFC 9692: RIFT: Routing in Fat Trees. "RFC 9692: RIFT: Routing in Fat Trees.
Section 6.9."; Section 6.9.";
} }
typedef system-id { typedef system-id {
type string { type string {
pattern pattern
'[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}'; '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}';
} }
description description
"This type defines RIFT system id using pattern, "This type defines the pattern for RIFT System IDs.
the system id looks like: 0021.2FFF.FEB5.6E10."; An example of a System ID is 0021.2FFF.FEB5.6E10.";
} }
typedef level { typedef level {
type uint8 { type uint8 {
range "0 .. 24"; range "0 .. 24";
} }
default "0"; default "0";
description description
"The value of node level. "The value of node level.
Clos and Fat Tree networks are topologically partially Clos and Fat Tree networks are topologically partially
skipping to change at line 2577 skipping to change at line 2568
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
* /rift * /rift
Modifying the configuration may cause all the RIFT neighborships to Modifying the configuration may cause all the RIFT neighborships to
be rebuilt. For example, changing the configuration of configured- be rebuilt. For example, changing the configuration of configured-
level or system-id will lead to all the neighbor connections of this level or system-id will lead to all the neighbor connections of this
node being rebuilt. The incorrect modification of authentication, node being rebuilt. The incorrect modification of authentication,
except for the neighbor connection broken, will lead to the permanent except for the broken neighbor connection, will break the connection
connection broken. The modification of interface will cause the permanently. The modification of interface will cause the neighbor
neighbor state to change. In general, unauthorized modification of state to change. In general, unauthorized modification of most RIFT
most RIFT configurations will pose their own set of security risks configurations will pose their own set of security risks and the
and the "Security Considerations" in the respective RFCs referenced "Security Considerations" in the respective RFCs referenced should be
should be consulted. consulted.
Some of the readable data nodes in this YANG module may be considered Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
* /rift * /rift
* /rift/global/tie-security * /rift/global/tie-security
skipping to change at line 2794 skipping to change at line 2785
Yuehua Wei Yuehua Wei
ZTE Corporation ZTE Corporation
Email: wei.yuehua@zte.com.cn Email: wei.yuehua@zte.com.cn
Shaowen Ma Shaowen Ma
Google Google
Email: mashaowen@gmail.com Email: mashaowen@gmail.com
Xufeng Liu Xufeng Liu
Alef Edge Individual
Email: xufeng.liu.ietf@gmail.com Email: xufeng.liu.ietf@gmail.com
Bruno Rijsman Bruno Rijsman
Individual Individual
Email: brunorijsman@gmail.com Email: brunorijsman@gmail.com
 End of changes. 14 change blocks. 
57 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.48.