draft-ietf-rift-rift-11.txt   draft-ietf-rift-rift-12.txt 
RIFT Working Group A. Przygienda, Ed. RIFT Working Group A. Przygienda, Ed.
Internet-Draft Juniper Internet-Draft Juniper
Intended status: Standards Track A. Sharma Intended status: Standards Track A. Sharma
Expires: September 11, 2020 Comcast Expires: November 27, 2020 Comcast
P. Thubert P. Thubert
Cisco Cisco
Bruno. Rijsman Bruno. Rijsman
Individual Individual
Dmitry. Afanasiev Dmitry. Afanasiev
Yandex Yandex
March 10, 2020 May 26, 2020
RIFT: Routing in Fat Trees RIFT: Routing in Fat Trees
draft-ietf-rift-rift-11 draft-ietf-rift-rift-12
Abstract Abstract
This document defines a specialized, dynamic routing protocol for This document defines a specialized, dynamic routing protocol for
Clos and fat-tree network topologies optimized towards minimization Clos and fat-tree network topologies optimized towards minimization
of configuration and operational complexity. The protocol of configuration and operational complexity. The protocol
o deals with no configuration, fully automated construction of fat- o deals with no configuration, fully automated construction of fat-
tree topologies based on detection of links, tree topologies based on detection of links,
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2020. This Internet-Draft will expire on November 27, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 40 skipping to change at page 4, line 40
7. Security Considerations . . . . . . . . . . . . . . . . . . . 122 7. Security Considerations . . . . . . . . . . . . . . . . . . . 122
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 122 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.2. ZTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 7.2. ZTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.3. Lifetime . . . . . . . . . . . . . . . . . . . . . . . . 123 7.3. Lifetime . . . . . . . . . . . . . . . . . . . . . . . . 123
7.4. Packet Number . . . . . . . . . . . . . . . . . . . . . . 123 7.4. Packet Number . . . . . . . . . . . . . . . . . . . . . . 123
7.5. Outer Fingerprint Attacks . . . . . . . . . . . . . . . . 123 7.5. Outer Fingerprint Attacks . . . . . . . . . . . . . . . . 123
7.6. TIE Origin Fingerprint DoS Attacks . . . . . . . . . . . 123 7.6. TIE Origin Fingerprint DoS Attacks . . . . . . . . . . . 123
7.7. Host Implementations . . . . . . . . . . . . . . . . . . 124 7.7. Host Implementations . . . . . . . . . . . . . . . . . . 124
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124
8.1. Requested Multicast and Port Numbers . . . . . . . . . . 124 8.1. Requested Multicast and Port Numbers . . . . . . . . . . 124
8.2. Requested Registries with Suggested Values . . . . . . . 124 8.2. Requested Registries with Suggested Values . . . . . . . 125
8.2.1. Registry RIFT_v4/common/AddressFamilyType . . . . . . 125 8.2.1. Registry RIFT_v4/common/AddressFamilyType . . . . . . 125
8.2.1.1. Requested Entries . . . . . . . . . . . . . . . . 125 8.2.1.1. Requested Entries . . . . . . . . . . . . . . . . 125
8.2.2. Registry RIFT_v4/common/HierarchyIndications . . . . 125 8.2.2. Registry RIFT_v4/common/HierarchyIndications . . . . 125
8.2.2.1. Requested Entries . . . . . . . . . . . . . . . . 125 8.2.2.1. Requested Entries . . . . . . . . . . . . . . . . 125
8.2.3. Registry RIFT_v4/common/IEEE802_1ASTimeStampType . . 125 8.2.3. Registry RIFT_v4/common/IEEE802_1ASTimeStampType . . 125
8.2.3.1. Requested Entries . . . . . . . . . . . . . . . . 125 8.2.3.1. Requested Entries . . . . . . . . . . . . . . . . 126
8.2.4. Registry RIFT_v4/common/IPAddressType . . . . . . . . 125 8.2.4. Registry RIFT_v4/common/IPAddressType . . . . . . . . 126
8.2.4.1. Requested Entries . . . . . . . . . . . . . . . . 126 8.2.4.1. Requested Entries . . . . . . . . . . . . . . . . 126
8.2.5. Registry RIFT_v4/common/IPPrefixType . . . . . . . . 126 8.2.5. Registry RIFT_v4/common/IPPrefixType . . . . . . . . 126
8.2.5.1. Requested Entries . . . . . . . . . . . . . . . . 126 8.2.5.1. Requested Entries . . . . . . . . . . . . . . . . 126
8.2.6. Registry RIFT_v4/common/IPv4PrefixType . . . . . . . 126 8.2.6. Registry RIFT_v4/common/IPv4PrefixType . . . . . . . 126
8.2.6.1. Requested Entries . . . . . . . . . . . . . . . . 126 8.2.6.1. Requested Entries . . . . . . . . . . . . . . . . 126
8.2.7. Registry RIFT_v4/common/IPv6PrefixType . . . . . . . 126 8.2.7. Registry RIFT_v4/common/IPv6PrefixType . . . . . . . 126
8.2.7.1. Requested Entries . . . . . . . . . . . . . . . . 126 8.2.7.1. Requested Entries . . . . . . . . . . . . . . . . 127
8.2.8. Registry RIFT_v4/common/PrefixSequenceType . . . . . 126 8.2.8. Registry RIFT_v4/common/PrefixSequenceType . . . . . 127
8.2.8.1. Requested Entries . . . . . . . . . . . . . . . . 127 8.2.8.1. Requested Entries . . . . . . . . . . . . . . . . 127
8.2.9. Registry RIFT_v4/common/RouteType . . . . . . . . . . 127 8.2.9. Registry RIFT_v4/common/RouteType . . . . . . . . . . 127
8.2.9.1. Requested Entries . . . . . . . . . . . . . . . . 127 8.2.9.1. Requested Entries . . . . . . . . . . . . . . . . 127
8.2.10. Registry RIFT_v4/common/TIETypeType . . . . . . . . . 127 8.2.10. Registry RIFT_v4/common/TIETypeType . . . . . . . . . 128
8.2.10.1. Requested Entries . . . . . . . . . . . . . . . 128 8.2.10.1. Requested Entries . . . . . . . . . . . . . . . 128
8.2.11. Registry RIFT_v4/common/TieDirectionType . . . . . . 128 8.2.11. Registry RIFT_v4/common/TieDirectionType . . . . . . 128
8.2.11.1. Requested Entries . . . . . . . . . . . . . . . 128 8.2.11.1. Requested Entries . . . . . . . . . . . . . . . 128
8.2.12. Registry RIFT_v4/encoding/Community . . . . . . . . . 128 8.2.12. Registry RIFT_v4/encoding/Community . . . . . . . . . 128
8.2.12.1. Requested Entries . . . . . . . . . . . . . . . 128 8.2.12.1. Requested Entries . . . . . . . . . . . . . . . 128
8.2.13. Registry RIFT_v4/encoding/KeyValueTIEElement . . . . 128 8.2.13. Registry RIFT_v4/encoding/KeyValueTIEElement . . . . 129
8.2.13.1. Requested Entries . . . . . . . . . . . . . . . 128 8.2.13.1. Requested Entries . . . . . . . . . . . . . . . 129
8.2.14. Registry RIFT_v4/encoding/LIEPacket . . . . . . . . . 129 8.2.14. Registry RIFT_v4/encoding/LIEPacket . . . . . . . . . 129
8.2.14.1. Requested Entries . . . . . . . . . . . . . . . 129 8.2.14.1. Requested Entries . . . . . . . . . . . . . . . 129
8.2.15. Registry RIFT_v4/encoding/LinkCapabilities . . . . . 130 8.2.15. Registry RIFT_v4/encoding/LinkCapabilities . . . . . 130
8.2.15.1. Requested Entries . . . . . . . . . . . . . . . 130 8.2.15.1. Requested Entries . . . . . . . . . . . . . . . 130
8.2.16. Registry RIFT_v4/encoding/LinkIDPair . . . . . . . . 130 8.2.16. Registry RIFT_v4/encoding/LinkIDPair . . . . . . . . 130
8.2.16.1. Requested Entries . . . . . . . . . . . . . . . 130 8.2.16.1. Requested Entries . . . . . . . . . . . . . . . 131
8.2.17. Registry RIFT_v4/encoding/Neighbor . . . . . . . . . 131 8.2.17. Registry RIFT_v4/encoding/Neighbor . . . . . . . . . 131
8.2.17.1. Requested Entries . . . . . . . . . . . . . . . 131 8.2.17.1. Requested Entries . . . . . . . . . . . . . . . 131
8.2.18. Registry RIFT_v4/encoding/NodeCapabilities . . . . . 131 8.2.18. Registry RIFT_v4/encoding/NodeCapabilities . . . . . 131
8.2.18.1. Requested Entries . . . . . . . . . . . . . . . 131 8.2.18.1. Requested Entries . . . . . . . . . . . . . . . 132
8.2.19. Registry RIFT_v4/encoding/NodeFlags . . . . . . . . . 132 8.2.19. Registry RIFT_v4/encoding/NodeFlags . . . . . . . . . 132
8.2.19.1. Requested Entries . . . . . . . . . . . . . . . 132 8.2.19.1. Requested Entries . . . . . . . . . . . . . . . 132
8.2.20. Registry RIFT_v4/encoding/NodeNeighborsTIEElement . . 132 8.2.20. Registry RIFT_v4/encoding/NodeNeighborsTIEElement . . 132
8.2.20.1. Requested Entries . . . . . . . . . . . . . . . 132 8.2.20.1. Requested Entries . . . . . . . . . . . . . . . 132
8.2.21. Registry RIFT_v4/encoding/NodeTIEElement . . . . . . 132 8.2.21. Registry RIFT_v4/encoding/NodeTIEElement . . . . . . 132
8.2.21.1. Requested Entries . . . . . . . . . . . . . . . 133 8.2.21.1. Requested Entries . . . . . . . . . . . . . . . 133
8.2.22. Registry RIFT_v4/encoding/PacketContent . . . . . . . 133 8.2.22. Registry RIFT_v4/encoding/PacketContent . . . . . . . 133
8.2.22.1. Requested Entries . . . . . . . . . . . . . . . 133 8.2.22.1. Requested Entries . . . . . . . . . . . . . . . 133
8.2.23. Registry RIFT_v4/encoding/PacketHeader . . . . . . . 133 8.2.23. Registry RIFT_v4/encoding/PacketHeader . . . . . . . 133
8.2.23.1. Requested Entries . . . . . . . . . . . . . . . 133 8.2.23.1. Requested Entries . . . . . . . . . . . . . . . 134
8.2.24. Registry RIFT_v4/encoding/PrefixAttributes . . . . . 134 8.2.24. Registry RIFT_v4/encoding/PrefixAttributes . . . . . 134
8.2.24.1. Requested Entries . . . . . . . . . . . . . . . 134 8.2.24.1. Requested Entries . . . . . . . . . . . . . . . 134
8.2.25. Registry RIFT_v4/encoding/PrefixTIEElement . . . . . 134 8.2.25. Registry RIFT_v4/encoding/PrefixTIEElement . . . . . 134
8.2.25.1. Requested Entries . . . . . . . . . . . . . . . 134 8.2.25.1. Requested Entries . . . . . . . . . . . . . . . 135
8.2.26. Registry RIFT_v4/encoding/ProtocolPacket . . . . . . 135 8.2.26. Registry RIFT_v4/encoding/ProtocolPacket . . . . . . 135
8.2.26.1. Requested Entries . . . . . . . . . . . . . . . 135 8.2.26.1. Requested Entries . . . . . . . . . . . . . . . 135
8.2.27. Registry RIFT_v4/encoding/TIDEPacket . . . . . . . . 135 8.2.27. Registry RIFT_v4/encoding/TIDEPacket . . . . . . . . 135
8.2.27.1. Requested Entries . . . . . . . . . . . . . . . 135 8.2.27.1. Requested Entries . . . . . . . . . . . . . . . 135
8.2.28. Registry RIFT_v4/encoding/TIEElement . . . . . . . . 135 8.2.28. Registry RIFT_v4/encoding/TIEElement . . . . . . . . 135
8.2.28.1. Requested Entries . . . . . . . . . . . . . . . 136 8.2.28.1. Requested Entries . . . . . . . . . . . . . . . 136
8.2.29. Registry RIFT_v4/encoding/TIEHeader . . . . . . . . . 136 8.2.29. Registry RIFT_v4/encoding/TIEHeader . . . . . . . . . 136
8.2.29.1. Requested Entries . . . . . . . . . . . . . . . 137 8.2.29.1. Requested Entries . . . . . . . . . . . . . . . 137
8.2.30. Registry RIFT_v4/encoding/TIEHeaderWithLifeTime . . . 137 8.2.30. Registry RIFT_v4/encoding/TIEHeaderWithLifeTime . . . 137
8.2.30.1. Requested Entries . . . . . . . . . . . . . . . 137 8.2.30.1. Requested Entries . . . . . . . . . . . . . . . 137
skipping to change at page 6, line 19 skipping to change at page 6, line 19
8.2.33. Registry RIFT_v4/encoding/TIREPacket . . . . . . . . 138 8.2.33. Registry RIFT_v4/encoding/TIREPacket . . . . . . . . 138
8.2.33.1. Requested Entries . . . . . . . . . . . . . . . 138 8.2.33.1. Requested Entries . . . . . . . . . . . . . . . 138
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 138 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 138
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 139 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 139
10.1. Normative References . . . . . . . . . . . . . . . . . . 139 10.1. Normative References . . . . . . . . . . . . . . . . . . 139
10.2. Informative References . . . . . . . . . . . . . . . . . 141 10.2. Informative References . . . . . . . . . . . . . . . . . 141
Appendix A. Sequence Number Binary Arithmetic . . . . . . . . . 143 Appendix A. Sequence Number Binary Arithmetic . . . . . . . . . 143
Appendix B. Information Elements Schema . . . . . . . . . . . . 144 Appendix B. Information Elements Schema . . . . . . . . . . . . 144
B.1. common.thrift . . . . . . . . . . . . . . . . . . . . . . 146 B.1. common.thrift . . . . . . . . . . . . . . . . . . . . . . 146
B.2. encoding.thrift . . . . . . . . . . . . . . . . . . . . . 152 B.2. encoding.thrift . . . . . . . . . . . . . . . . . . . . . 152
Appendix C. Constants . . . . . . . . . . . . . . . . . . . . . 160 Appendix C. Constants . . . . . . . . . . . . . . . . . . . . . 161
C.1. Configurable Protocol Constants . . . . . . . . . . . . . 160 C.1. Configurable Protocol Constants . . . . . . . . . . . . . 161
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 163
1. Authors 1. Authors
This work is a product of a list of individuals which are all to be This work is a product of a list of individuals which are all to be
considered major contributors independent of the fact whether their considered major contributors independent of the fact whether their
name made it to the limited boilerplate author's list or not. name made it to the limited boilerplate author's list or not.
Tony Przygienda, Ed. | Alankar Sharma | Pascal Thubert Tony Przygienda, Ed. | Alankar Sharma | Pascal Thubert
Juniper Networks | Comcast | Cisco Juniper Networks | Comcast | Cisco
skipping to change at page 16, line 32 skipping to change at page 16, line 32
direction for the moment. direction for the moment.
Those information flow constraints create not only an anisotropic Those information flow constraints create not only an anisotropic
protocol (i.e. the information is not distributed "evenly" or protocol (i.e. the information is not distributed "evenly" or
"clumped" but summarized along the N-S gradient) but also a "smooth" "clumped" but summarized along the N-S gradient) but also a "smooth"
information propagation where nodes do not receive the same information propagation where nodes do not receive the same
information from multiple directions at the same time. Normally, information from multiple directions at the same time. Normally,
accepting the same reachability on any link, without understanding accepting the same reachability on any link, without understanding
its topological significance, forces tie-breaking on some kind of its topological significance, forces tie-breaking on some kind of
distance metric. And such tie-breaking leads ultimately in hop-by- distance metric. And such tie-breaking leads ultimately in hop-by-
hop forwarding to shortest paths only. In constrast to that, RIFT, hop forwarding to shortest paths only. In contrast to that, RIFT,
under normal conditions, does not need to tie-break same reachability under normal conditions, does not need to tie-break same reachability
information from multiple directions. Its computation principles information from multiple directions. Its computation principles
(south forwarding direction is always preferred) leads to valley-free (south forwarding direction is always preferred) leads to valley-free
forwarding behavior. And since valley free routing is loop-free, it forwarding behavior. And since valley free routing is loop-free, it
can use all feasible paths which is another highly desirable property can use all feasible paths which is another highly desirable property
if available bandwidth should be utilized to the maximum extent if available bandwidth should be utilized to the maximum extent
possible. possible.
To account for the "northern" and the "southern" information split To account for the "northern" and the "southern" information split
the link state database is partitioned accordingly into "north the link state database is partitioned accordingly into "north
skipping to change at page 19, line 31 skipping to change at page 19, line 31
|| || || || || || || || || || || || || ||
+----+ +------------------------------------------------+ +----+ +------------------------------------------------+
| | | | | | | |
+----+ +------------------------------------------------+ +----+ +------------------------------------------------+
|| || || || || || || || || || || || || ||
Side views Side views
Figure 4: A Leaf Node, K_LEAF=6 Figure 4: A Leaf Node, K_LEAF=6
The Radix of a PoD's topnode may be different than that of the leaf The Radix of a PoD's top node may be different than that of the leaf
node. Though, more often than not, a same type of node is used for node. Though, more often than not, a same type of node is used for
both, effectively forming a square (K*K). In general case, we could both, effectively forming a square (K*K). In general case, we could
have switches with K_TOP southern ports on nodes at the top of the have switches with K_TOP southern ports on nodes at the top of the
PoD which are not necessarily the same as K_LEAF. For instance, in PoD which are not necessarily the same as K_LEAF. For instance, in
the representations below, we pick a 6 port K_LEAF and a 8 port the representations below, we pick a 6 port K_LEAF and a 8 port
K_TOP. In order to form a crossbar, we need K_TOP Leaf Nodes as K_TOP. In order to form a crossbar, we need K_TOP Leaf Nodes as
illustrated in Figure 5. illustrated in Figure 5.
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
skipping to change at page 28, line 7 skipping to change at page 28, line 7
Plane 6 ^ | Plane 6 ^ |
| | | |
| ---------------- ------------- | | ---------------- ------------- |
+----- ToF Node Class of PoDs ---+ +----- ToF Node Class of PoDs ---+
---------------- ------------- ---------------- -------------
Figure 12: Northern View of a Maximally Partitioned ToF Level, R=1 Figure 12: Northern View of a Maximally Partitioned ToF Level, R=1
4.1.3. Fallen Leaf Problem 4.1.3. Fallen Leaf Problem
As mentioned earlier, RIFT exhibits an anisotropic behaviour tailored As mentioned earlier, RIFT exhibits an anisotropic behavior tailored
for fabrics with a North / South orientation and a high level of for fabrics with a North / South orientation and a high level of
interleaving paths. A non-partitioned fabric makes a total loss of interleaving paths. A non-partitioned fabric makes a total loss of
connectivity between a Top-of-Fabric node at the north and a leaf connectivity between a Top-of-Fabric node at the north and a leaf
node at the south a very rare but yet possible occasion that is fully node at the south a very rare but yet possible occasion that is fully
healed by positive disaggregation as described in Section 4.2.5.1. healed by positive disaggregation as described in Section 4.2.5.1.
In large fabrics or fabrics built from switches with low radix, the In large fabrics or fabrics built from switches with low radix, the
ToF ends often being partitioned in planes which makes the occurrence ToF ends often being partitioned in planes which makes the occurrence
of having a given leaf being only reachable from a subset of the ToF of having a given leaf being only reachable from a subset of the ToF
nodes more likely to happen. This makes some further considerations nodes more likely to happen. This makes some further considerations
necessary. necessary.
skipping to change at page 28, line 29 skipping to change at page 28, line 29
We define a "Fallen Leaf" as a leaf that can be reached by only a We define a "Fallen Leaf" as a leaf that can be reached by only a
subset, but not all, of Top-of-Fabric nodes due to missing subset, but not all, of Top-of-Fabric nodes due to missing
connectivity. If R is the redundancy factor, then it takes at least connectivity. If R is the redundancy factor, then it takes at least
R breakages to reach a "Fallen Leaf" situation. R breakages to reach a "Fallen Leaf" situation.
In a maximally partitioned fabric, the redundancy factor is R= 1, so In a maximally partitioned fabric, the redundancy factor is R= 1, so
any breakage in the fabric may cause one or more fallen leaves. any breakage in the fabric may cause one or more fallen leaves.
However, not all cases require disaggregation. The following cases However, not all cases require disaggregation. The following cases
do not require particular action in such scenario: do not require particular action in such scenario:
If a southern link on a leaf node goes down, then connectivity to If a southern link on a node goes down, then connectivity through
any node attached to the leaf is lost. There is no need to that node is lost for all nodes south of it. There is no need to
disaggregate since the connectivity is lost from all spine nodes disaggregate since the connectivity to this node is lost for all
to the leaf nodes in the same fashion.
If a southern link on a leaf node goes down, then connectivity
through that leaf is lost for all nodes. There is no need to
disaggregate since the connectivity to this leaf is lost for all
spine nodes in a same fashion. spine nodes in a same fashion.
If a ToF Node goes down, then northern traffic towards it is If a ToF Node goes down, then northern traffic towards it is
routed via alternate ToF nodes in the same plane and there is no routed via alternate ToF nodes in the same plane and there is no
need to disaggregate routes. need to disaggregate routes.
In a general manner, the mechanism of non-transitive positive In a general manner, the mechanism of non-transitive positive
disaggregation is sufficient when the disaggregating ToF nodes disaggregation is sufficient when the disaggregating ToF nodes
collectively connect to all the ToP nodes in the broken plane. This collectively connect to all the ToP nodes in the broken plane. This
happens in the following case: happens in the following case:
skipping to change at page 44, line 50 skipping to change at page 44, line 50
2. CLEANUP: neighbor MUST be reset to unknown 2. CLEANUP: neighbor MUST be reset to unknown
3. SEND_LIE: create a new LIE packet 3. SEND_LIE: create a new LIE packet
1. reflecting the neighbor if known and valid and 1. reflecting the neighbor if known and valid and
2. setting the necessary `not_a_ztp_offer` variable if level was 2. setting the necessary `not_a_ztp_offer` variable if level was
derived from last known neighbor on this interface and derived from last known neighbor on this interface and
3. setting `you_are_not_flood_repeater` to computed value 3. setting `you_are_flood_repeater` to computed value
4. PROCESS_LIE: 4. PROCESS_LIE:
1. if lie has wrong major version OR our own system ID or 1. if lie has wrong major version OR our own system ID or
invalid system ID then CLEANUP else invalid system ID then CLEANUP else
2. if lie has non matching MTUs then CLEANUP, PUSH 2. if lie has non matching MTUs then CLEANUP, PUSH
UpdateZTPOffer, PUSH MTUMismatch else UpdateZTPOffer, PUSH MTUMismatch else
3. if PoD rules do not allow adjacency forming then CLEANUP, 3. if PoD rules do not allow adjacency forming then CLEANUP,
skipping to change at page 50, line 20 skipping to change at page 50, line 20
A node SHOULD NOT send out any topology information elements if the A node SHOULD NOT send out any topology information elements if the
adjacency is not in a "three-way" state. No further tightening of adjacency is not in a "three-way" state. No further tightening of
this rule is possible due to possible link buffering and re-ordering this rule is possible due to possible link buffering and re-ordering
of LIEs and TIEs/TIDEs/TIREs. of LIEs and TIEs/TIDEs/TIREs.
A node MUST drop any received TIEs/TIDEs/TIREs unless it is in three- A node MUST drop any received TIEs/TIDEs/TIREs unless it is in three-
way state. way state.
TIDEs and TIREs MUST NOT be re-flooded the way TIEs of other nodes TIDEs and TIREs MUST NOT be re-flooded the way TIEs of other nodes
are are MUST be always generated by the node itself and cross only to MUST be always generated by the node itself and cross only to the
the neighboring node. neighboring node.
4.2.3.3.1.1. FloodState Structure per Adjacency 4.2.3.3.1.1. FloodState Structure per Adjacency
The structure contains conceptually the following elements. The word The structure contains conceptually the following elements. The word
collection or queue indicates a set of elements that can be iterated: collection or queue indicates a set of elements that can be iterated:
TIES_TX: Collection containing all the TIEs to transmit on the TIES_TX: Collection containing all the TIEs to transmit on the
adjacency. adjacency.
TIES_ACK: Collection containing all the TIEs that have to be TIES_ACK: Collection containing all the TIEs that have to be
skipping to change at page 54, line 31 skipping to change at page 54, line 31
d. for all TIEs in TXKEYS try_to_transmit_tie(TIE) d. for all TIEs in TXKEYS try_to_transmit_tie(TIE)
e. for all TIEs in REQKEYS request_tie(TIE) e. for all TIEs in REQKEYS request_tie(TIE)
f. for all TIEs in CLEARKEYS remove_from_all_queues(TIE) f. for all TIEs in CLEARKEYS remove_from_all_queues(TIE)
4.2.3.3.1.3. TIREs 4.2.3.3.1.3. TIREs
4.2.3.3.1.3.1. TIRE Generation 4.2.3.3.1.3.1. TIRE Generation
There is not much to say here. Elements from both TIES_REQ and Elements from both TIES_REQ and TIES_ACK MUST be collected and sent
TIES_ACK MUST be collected and sent out as fast as feasible as TIREs. out as fast as feasible as TIREs. When sending TIREs with elements
When sending TIREs with elements from TIES_REQ the `lifetime` field from TIES_REQ the `lifetime` field MUST be set to 0 to force
MUST be set to 0 to force reflooding from the neighbor even if the reflooding from the neighbor even if the TIEs seem to be same.
TIEs seem to be same.
4.2.3.3.1.3.2. TIRE Processing 4.2.3.3.1.3.2. TIRE Processing
On reception of TIREs the following processing is performed: On reception of TIREs the following processing is performed:
TXKEYS: Collection of TIE Headers to be send after processing of TXKEYS: Collection of TIE Headers to be send after processing of
the packet the packet
REQKEYS: Collection of TIEIDs to be requested after processing of REQKEYS: Collection of TIEIDs to be requested after processing of
the packet the packet
skipping to change at page 59, line 46 skipping to change at page 59, line 46
| | 121 | | | | 121 | |
| ToF 21 | Spine | ToF 21 South TIEs | | ToF 21 | Spine | ToF 21 South TIEs |
| | 122 | | | | 122 | |
| ... | ... | ... | | ... | ... | ... |
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
Table 4: Flooding some TIEs from example topology Table 4: Flooding some TIEs from example topology
4.2.3.5. 'Flood Only Node TIEs' Bit 4.2.3.5. 'Flood Only Node TIEs' Bit
RIFT includes an optional ECN mechanism to prevent "flooding inrush" RIFT includes an optional ECN (Explicit Congestion Notification)
on restart or bring-up with many southbound neighbors. A node MAY mechanism to prevent "flooding inrush" on restart or bring-up with
set on its LIEs the according bit to indicate to the neighbor that it many southbound neighbors. A node MAY set on its LIEs the according
should temporarily flood node TIEs only to it. It SHOULD only set it bit to indicate to the neighbor that it should temporarily flood node
in the southbound direction. The receiving node SHOULD accommodate TIEs only to it. It SHOULD only set it in the southbound direction.
the request to lessen the flooding load on the affected node if south The receiving node SHOULD accommodate the request to lessen the
of the sender and SHOULD ignore the bit if northbound. flooding load on the affected node if south of the sender and SHOULD
ignore the bit if northbound.
Obviously this mechanism is most useful in southbound direction. The Obviously this mechanism is most useful in southbound direction. The
distribution of node TIEs guarantees correct behavior of algorithms distribution of node TIEs guarantees correct behavior of algorithms
like disaggregation or default route origination. Furthermore like disaggregation or default route origination. Furthermore
though, the use of this bit presents an inherent trade-off between though, the use of this bit presents an inherent trade-off between
processing load and convergence speed since suppressing flooding of processing load and convergence speed since suppressing flooding of
northbound prefixes from neighbors will lead to blackholes. northbound prefixes from neighbors will lead to blackholes.
4.2.3.6. Initial and Periodic Database Synchronization 4.2.3.6. Initial and Periodic Database Synchronization
skipping to change at page 61, line 19 skipping to change at page 61, line 22
interval [0, 2^30-1] which will prevent otherwise identical TIE interval [0, 2^30-1] which will prevent otherwise identical TIE
headers to remain "stuck" in the network with content different from headers to remain "stuck" in the network with content different from
TIE originated after reboot. In traditional link-state protocols TIE originated after reboot. In traditional link-state protocols
this is delegated to a 16-bit checksum on packet content. RIFT this is delegated to a 16-bit checksum on packet content. RIFT
avoids this design due to the CPU burden presented by computation of avoids this design due to the CPU burden presented by computation of
such checksums and additional complications tied to the fact that the such checksums and additional complications tied to the fact that the
checksum must be "patched" into the packet after the computation, a checksum must be "patched" into the packet after the computation, a
difficult proposition in binary hand-crafted formats already and difficult proposition in binary hand-crafted formats already and
highly incompatible with model-based, serialized formats. The highly incompatible with model-based, serialized formats. The
sequence number space is hence consciously chosen to be 64-bits wide sequence number space is hence consciously chosen to be 64-bits wide
to make the occurence of a TIE with same sequence number but to make the occurrence of a TIE with same sequence number but
different content as much or even more unlikely than the checksum different content as much or even more unlikely than the checksum
method. To emulate the "checksum behavior" an implementation could method. To emulate the "checksum behavior" an implementation could
e.g. choose to compute 64-bit checksum over the packet content and e.g. choose to compute 64-bit checksum over the packet content and
use that as first sequence number after reboot. use that as first sequence number after reboot.
4.2.3.8. Southbound Default Route Origination 4.2.3.8. Southbound Default Route Origination
Under certain conditions nodes issue a default route in their South Under certain conditions nodes issue a default route in their South
Prefix TIEs with costs as computed in Section 4.3.6.1. Prefix TIEs with costs as computed in Section 4.3.6.1.
skipping to change at page 64, line 5 skipping to change at page 64, line 8
that |G(Node) = |P(|P(Node)); that |G(Node) = |P(|P(Node));
o let N be the child node at level L computing a set of FR; o let N be the child node at level L computing a set of FR;
o let P be a node at level L+1 and a parent node of N, i.e. bi- o let P be a node at level L+1 and a parent node of N, i.e. bi-
directionally reachable over adjacency A(N, P); directionally reachable over adjacency A(N, P);
o let G be a grandparent node of N, reachable transitively via a o let G be a grandparent node of N, reachable transitively via a
parent P over adjacencies ADJ(N, P) and ADJ(P, G). Observe that N parent P over adjacencies ADJ(N, P) and ADJ(P, G). Observe that N
does not have enough information to check bidirectional does not have enough information to check bidirectional
reachability of A(P, G); reachability of ADJ(P, G);
o let R be a redundancy constant integer; a value of 2 or higher for o let R be a redundancy constant integer; a value of 2 or higher for
R is RECOMMENDED; R is RECOMMENDED;
o let S be a similarity constant integer; a value in range 0 .. 2 o let S be a similarity constant integer; a value in range 0 .. 2
for S is RECOMMENDED, the value of 1 SHOULD be used. Two for S is RECOMMENDED, the value of 1 SHOULD be used. Two
cardinalities are considered as equivalent if their absolute cardinalities are considered as equivalent if their absolute
difference is less than or equal to S, i.e. |a-b|<=S. difference is less than or equal to S, i.e. |a-b|<=S.
o let RND be a 64-bit random number generated by the system once on o let RND be a 64-bit random number generated by the system once on
skipping to change at page 84, line 34 skipping to change at page 84, line 34
| | | | | |
| +--------+ | +--------+ | +--------+ | +--------+ | +--------+ | +--------+
+---> | Via S4 | +---> | Via S4 | +---> | Via S4 | +---> | Via S4 | +---> | Via S4 | +---> | Via S4 |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 25: Abstract FIB after Negative 2001:db8:2::/48 from S4 Figure 25: Abstract FIB after Negative 2001:db8:2::/48 from S4
4.2.7. Optional Zero Touch Provisioning (ZTP) 4.2.7. Optional Zero Touch Provisioning (ZTP)
Each RIFT node can operate in zero touch provisioning (ZTP) mode, Each RIFT node can operate in zero touch provisioning (ZTP) mode,
i.e. it has no configuration (unless it is a Top-of-Fabric at the top i.e. it has no configuration (unless it is a ToF or it is configured
of the topology or the must operate in the topology as leaf and/or to operate in the overall topology as leaf and/or support leaf-2-leaf
support leaf-2-leaf procedures) and it will fully configure itself procedures) and it will fully configure itself after being attached
after being attached to the topology. Configured nodes and nodes to the topology. Configured nodes and nodes operating in ZTP can be
operating in ZTP can be mixed and will form a valid topology if mixed and will form a valid topology if achievable.
achievable.
The derivation of the level of each node happens based on offers The derivation of the level of each node happens based on offers
received from its neighbors whereas each node (with possibly received from its neighbors whereas each node (with possibly
exceptions of configured leaves) tries to attach at the highest exceptions of configured leaves) tries to attach at the highest
possible point in the fabric. This guarantees that even if the possible point in the fabric. This guarantees that even if the
diffusion front reaches a node from "below" faster than from "above", diffusion front reaches a node from "below" faster than from "above",
it will greedily abandon already negotiated level derived from nodes it will greedily abandon already negotiated level derived from nodes
topologically below it and properly peers with nodes above. topologically below it and properly peers with nodes above.
The fabric is very consciously numbered from the top to allow for The fabric is very consciously numbered from the top to allow for
skipping to change at page 95, line 30 skipping to change at page 95, line 30
Following words are used for well known procedures: Following words are used for well known procedures:
1. PUSH Event: pushes an event to be executed by the FSM upon exit 1. PUSH Event: pushes an event to be executed by the FSM upon exit
of this action of this action
2. COMPARE_OFFERS: checks whether based on current offers and held 2. COMPARE_OFFERS: checks whether based on current offers and held
last results the events BetterHAL/LostHAL/BetterHAT/LostHAT are last results the events BetterHAL/LostHAL/BetterHAT/LostHAT are
necessary and returns them necessary and returns them
3. UPDATE_OFFER: store current offer with adjancency holdtime as 3. UPDATE_OFFER: store current offer with adjacency holdtime as
lifetime and COMPARE_OFFERS, then PUSH according events lifetime and COMPARE_OFFERS, then PUSH according events
4. LEVEL_COMPUTE: compute best offered or configured level and HAL/ 4. LEVEL_COMPUTE: compute best offered or configured level and HAL/
HAT, if anything changed PUSH ComputationDone HAT, if anything changed PUSH ComputationDone
5. REMOVE_OFFER: remove the according offer and COMPARE_OFFERS, PUSH 5. REMOVE_OFFER: remove the according offer and COMPARE_OFFERS, PUSH
according events according events
6. PURGE_OFFERS: REMOVE_OFFER for all held offers, COMPARE OFFERS, 6. PURGE_OFFERS: REMOVE_OFFER for all held offers, COMPARE OFFERS,
PUSH according events PUSH according events
skipping to change at page 100, line 42 skipping to change at page 100, line 42
4. An undefined TID is always older than any other TID AND 4. An undefined TID is always older than any other TID AND
5. TIDs are compared using rules of [RFC8505]. 5. TIDs are compared using rules of [RFC8505].
4.3.3.2. Interaction between Time Stamps and Sequence Counters 4.3.3.2. Interaction between Time Stamps and Sequence Counters
For attachment changes that occur less frequently (e.g. once per For attachment changes that occur less frequently (e.g. once per
second), the timestamp that the RIFT infrastructure captures should second), the timestamp that the RIFT infrastructure captures should
be enough to determine the most current discovery. If the point of be enough to determine the most current discovery. If the point of
attachment changes faster than the maximum drift of the timestamping attachment changes faster than the maximum drift of the time stamping
mechanism (i.e. MAXIMUM_CLOCK_DELTA), then a sequence number SHOULD mechanism (i.e. MAXIMUM_CLOCK_DELTA), then a sequence number SHOULD
be used to enable necessary precision to determine currency. be used to enable necessary precision to determine currency.
The sequence counter in [RFC8505] is encoded as one octet and wraps The sequence counter in [RFC8505] is encoded as one octet and wraps
around using Appendix A. around using Appendix A.
Within the resolution of MAXIMUM_CLOCK_DELTA, sequence counter values Within the resolution of MAXIMUM_CLOCK_DELTA, sequence counter values
captured during 2 sequential iterations of the same timestamp SHOULD captured during 2 sequential iterations of the same timestamp SHOULD
be comparable. This means that with default values, a node may move be comparable. This means that with default values, a node may move
up to 127 times in a 200 millisecond period and the clocks will up to 127 times in a 200 millisecond period and the clocks will
skipping to change at page 101, line 35 skipping to change at page 101, line 35
RIFT is agnostic to any overlay technologies and their associated RIFT is agnostic to any overlay technologies and their associated
control and transports that run on top of it (e.g. VXLAN). It is control and transports that run on top of it (e.g. VXLAN). It is
expected that leaf nodes and possibly Top-of-Fabric nodes can perform expected that leaf nodes and possibly Top-of-Fabric nodes can perform
necessary data plane encapsulation. necessary data plane encapsulation.
In the context of mobility, overlays provide another possible In the context of mobility, overlays provide another possible
solution to avoid injecting mobile prefixes into the fabric as well solution to avoid injecting mobile prefixes into the fabric as well
as improving scalability of the deployment. It makes sense to as improving scalability of the deployment. It makes sense to
consider overlays for mobility solutions in IP fabrics. As an consider overlays for mobility solutions in IP fabrics. As an
example, a mobility protocol such as LISP may inform the ingress leaf example, a mobility protocol such as LISP [RFC6830] may inform the
of the location of the egress leaf in real time. ingress leaf of the location of the egress leaf in real time.
Another possibility is to consider that mobility as an underlay Another possibility is to consider that mobility as an underlay
service and support it in RIFT to an extent. The load on the fabric service and support it in RIFT to an extent. The load on the fabric
augments with the amount of mobility obviously since a move forces augments with the amount of mobility obviously since a move forces
flooding and computation on all nodes in the scope of the move so flooding and computation on all nodes in the scope of the move so
tunneling from leaf to the Top-of-Fabric may be desired to speed up tunneling from leaf to the Top-of-Fabric may be desired to speed up
convergence times. convergence times.
4.3.4. Key/Value Store 4.3.4. Key/Value Store
skipping to change at page 118, line 47 skipping to change at page 118, line 47
1.1/16 1.1/16
Figure 34: Fabric Partition Figure 34: Fabric Partition
Figure 34 shows one of more catastrophic scenarios where ToF 21 is Figure 34 shows one of more catastrophic scenarios where ToF 21 is
completely severed from access to Prefix 121 due to a double link completely severed from access to Prefix 121 due to a double link
failure. If only default routes existed, this would result in 50% of failure. If only default routes existed, this would result in 50% of
traffic from Leaf 111 and Leaf 112 toward Prefix 121 being black- traffic from Leaf 111 and Leaf 112 toward Prefix 121 being black-
holed. holed.
The mechanism to resolve this scenario hinges on ToF 21's Sout TIEs The mechanism to resolve this scenario hinges on ToF 21's South TIEs
being reflected from Spine 111 and Spine 112 to ToF 22. Once ToF 22 being reflected from Spine 111 and Spine 112 to ToF 22. Once ToF 22
sees that Prefix 121 cannot be reached from ToF 21, it will begin to sees that Prefix 121 cannot be reached from ToF 21, it will begin to
disaggregate Prefix 121 by advertising a more specific route (1.1/16) disaggregate Prefix 121 by advertising a more specific route (1.1/16)
along with the default IP prefix route to all spines (ToF 21 still along with the default IP prefix route to all spines (ToF 21 still
only sends a default route). The result is Spine 111 and Spine112 only sends a default route). The result is Spine 111 and Spine112
using the more specific route to Prefix 121 via ToF 22. All other using the more specific route to Prefix 121 via ToF 22. All other
prefixes continue to use the default IP prefix route toward both ToF prefixes continue to use the default IP prefix route toward both ToF
21 and ToF 22. 21 and ToF 22.
The more specific route for Prefix 121 being advertised by ToF 22 The more specific route for Prefix 121 being advertised by ToF 22
skipping to change at page 124, line 8 skipping to change at page 124, line 8
A compromised node can attempt to generate "fake TIEs" using other A compromised node can attempt to generate "fake TIEs" using other
nodes' TIE origin key identifiers. Albeit the ultimate validation of nodes' TIE origin key identifiers. Albeit the ultimate validation of
the origin fingerprint will fail in such scenarios and not progress the origin fingerprint will fail in such scenarios and not progress
further than immediately peering nodes, the resulting denial of further than immediately peering nodes, the resulting denial of
service attack seems unavoidable since the TIE origin key id is only service attack seems unavoidable since the TIE origin key id is only
protected by the, here assumed to be compromised, node. protected by the, here assumed to be compromised, node.
7.7. Host Implementations 7.7. Host Implementations
It can be reasonably expected that with the proliferation of RotH It can be reasonably expected that with the proliferation of RotH
servers, rather than dedicated networking devices, servers will servers, rather than dedicated networking devices, will represent a
represent a significant amount of RIFT devices. Given their normally significant amount of RIFT devices. Given their normally far wider
far wider software envelope and access granted to them, such servers software envelope and access granted to them, such servers are also
are also far more likely to be compromised and present an attack far more likely to be compromised and present an attack vector on the
vector on the protocol. Hijacking of prefixes to attract traffic is protocol. Hijacking of prefixes to attract traffic is a trust
a trust problem and cannot be addressed within the protocol if the problem and cannot be easily addressed within the protocol if the
trust model is breached, i.e. the server presents valid credentials trust model is breached, i.e. the server presents valid credentials
to form an adjacency and issue TIEs. However, in a more devious way, to form an adjacency and issue TIEs. In an even more devious way,
the servers can present DoS (or even DDos) vectors of issuing too the servers can present DoS (or even DDos) vectors of issuing too
many LIE packets, flood large amounts of North TIEs and attempt many LIE packets, flood large amounts of North TIEs and attempt
similar resource overrun attacks. A prudent implementation forming similar resource overrun attacks. A prudent implementation forming
adjacencies to leaves should implement according thresholds adjacencies to leaves should implement according thresholds
mechanisms and raise warnings when e.g. a leaf is advertising an mechanisms and raise warnings when e.g. a leaf is advertising an
excess number of TIEs. excess number of TIEs or prefixes. Additionally, such implementation
could refuse any topology information except the node's own TIEs and
authenticated, reflected South Node TIEs at own level.
To isolate possible attack vectors on the leaf to the largest
possible extent a dedicated leaf-only implementation could run
without any configuration by hard-coding a well-known adjacency key
(which can be always rolled-over by the means of e.g. well-known key-
value distributed from top of the fabric), leaf level value and
always setting overload bit. All other values can be derived by
automatic means as described earlier in the protocol specification.
8. IANA Considerations 8. IANA Considerations
This specification requests multicast address assignments and This specification requests multicast address assignments and
standard port numbers. Additionally registries for the schema are standard port numbers. Additionally registries for the schema are
requested and suggested values provided that reflect the numbers requested and suggested values provided that reflect the numbers
allocated in the given schema. allocated in the given schema.
8.1. Requested Multicast and Port Numbers 8.1. Requested Multicast and Port Numbers
skipping to change at page 125, line 18 skipping to change at page 125, line 30
of every registry is a 16-bit integer. Allocation of new values is of every registry is a 16-bit integer. Allocation of new values is
always performed via `Expert Review` action. always performed via `Expert Review` action.
8.2.1. Registry RIFT_v4/common/AddressFamilyType 8.2.1. Registry RIFT_v4/common/AddressFamilyType
Address family type. Address family type.
8.2.1.1. Requested Entries 8.2.1.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
Illegal 0 4.0 Illegal 0 4.1
AddressFamilyMinValue 1 4.0 AddressFamilyMinValue 1 4.1
IPv4 2 4.0 IPv4 2 4.1
IPv6 3 4.0 IPv6 3 4.1
AddressFamilyMaxValue 4 4.0 AddressFamilyMaxValue 4 4.1
8.2.2. Registry RIFT_v4/common/HierarchyIndications 8.2.2. Registry RIFT_v4/common/HierarchyIndications
Flags indicating node configuration in case of ZTP. Flags indicating node configuration in case of ZTP.
8.2.2.1. Requested Entries 8.2.2.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
leaf_only 0 4.0 leaf_only 0 4.1
leaf_only_and_leaf_2_leaf_procedures 1 4.0 leaf_only_and_leaf_2_leaf_procedures 1 4.1
top_of_fabric 2 4.0 top_of_fabric 2 4.1
8.2.3. Registry RIFT_v4/common/IEEE802_1ASTimeStampType 8.2.3. Registry RIFT_v4/common/IEEE802_1ASTimeStampType
Timestamp per IEEE 802.1AS, all values MUST be interpreted in Timestamp per IEEE 802.1AS, all values MUST be interpreted in
implementation as unsigned. implementation as unsigned.
8.2.3.1. Requested Entries 8.2.3.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
AS_sec 1 4.0 AS_sec 1 4.1
AS_nsec 2 4.0 AS_nsec 2 4.1
8.2.4. Registry RIFT_v4/common/IPAddressType 8.2.4. Registry RIFT_v4/common/IPAddressType
IP address type. IP address type.
8.2.4.1. Requested Entries 8.2.4.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
ipv4address 1 4.0 Content is IPv4 ipv4address 1 4.1 Content is IPv4
ipv6address 2 4.0 Content is IPv6 ipv6address 2 4.1 Content is IPv6
8.2.5. Registry RIFT_v4/common/IPPrefixType 8.2.5. Registry RIFT_v4/common/IPPrefixType
Prefix advertisement. Prefix advertisement.
@note: for interface addresses the protocol can propagate the address @note: for interface addresses the protocol can propagate the address
part beyond the subnet mask and on reachability computation that has part beyond the subnet mask and on reachability computation that has
to be normalized. The non-significant bits can be used for to be normalized. The non-significant bits can be used for
operational purposes. operational purposes.
8.2.5.1. Requested Entries 8.2.5.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
ipv4prefix 1 4.0 ipv4prefix 1 4.1
ipv6prefix 2 4.0 ipv6prefix 2 4.1
8.2.6. Registry RIFT_v4/common/IPv4PrefixType 8.2.6. Registry RIFT_v4/common/IPv4PrefixType
IPv4 prefix type. IPv4 prefix type.
8.2.6.1. Requested Entries 8.2.6.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
address 1 4.0 address 1 4.1
prefixlen 2 4.0 prefixlen 2 4.1
8.2.7. Registry RIFT_v4/common/IPv6PrefixType 8.2.7. Registry RIFT_v4/common/IPv6PrefixType
IPv6 prefix type. IPv6 prefix type.
8.2.7.1. Requested Entries 8.2.7.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
address 1 4.0 address 1 4.1
prefixlen 2 4.0 prefixlen 2 4.1
8.2.8. Registry RIFT_v4/common/PrefixSequenceType 8.2.8. Registry RIFT_v4/common/PrefixSequenceType
Sequence of a prefix in case of move. Sequence of a prefix in case of move.
8.2.8.1. Requested Entries 8.2.8.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
timestamp 1 4.0 timestamp 1 4.1
transactionid 2 4.0 Transaction ID set by client in e.g. transactionid 2 4.1 Transaction ID set by client in e.g.
in 6LoWPAN. in 6LoWPAN.
8.2.9. Registry RIFT_v4/common/RouteType 8.2.9. Registry RIFT_v4/common/RouteType
RIFT route types. RIFT route types.
@note: route types which MUST be ordered on their preference PGP @note: route types which MUST be ordered on their preference PGP
prefixes are most preferred attracting traffic north (towards spine) prefixes are most preferred attracting traffic north (towards spine)
and then south normal prefixes are attracting traffic south (towards and then south normal prefixes are attracting traffic south (towards
leafs), i.e. prefix in NORTH PREFIX TIE is preferred over SOUTH leafs), i.e. prefix in NORTH PREFIX TIE is preferred over SOUTH
PREFIX TIE. PREFIX TIE.
@note: The only purpose of those values is to introduce an ordering @note: The only purpose of those values is to introduce an ordering
whereas an implementation can choose internally any other values as whereas an implementation can choose internally any other values as
long the ordering is preserved long the ordering is preserved
8.2.9.1. Requested Entries 8.2.9.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
Illegal 0 4.0 Illegal 0 4.1
RouteTypeMinValue 1 4.0 RouteTypeMinValue 1 4.1
Discard 2 4.0 Discard 2 4.1
LocalPrefix 3 4.0 LocalPrefix 3 4.1
SouthPGPPrefix 4 4.0 SouthPGPPrefix 4 4.1
NorthPGPPrefix 5 4.0 NorthPGPPrefix 5 4.1
NorthPrefix 6 4.0 NorthPrefix 6 4.1
NorthExternalPrefix 7 4.0 NorthExternalPrefix 7 4.1
SouthPrefix 8 4.0 SouthPrefix 8 4.1
SouthExternalPrefix 9 4.0 SouthExternalPrefix 9 4.1
NegativeSouthPrefix 10 4.0 NegativeSouthPrefix 10 4.1
RouteTypeMaxValue 11 4.0 RouteTypeMaxValue 11 4.1
8.2.10. Registry RIFT_v4/common/TIETypeType 8.2.10. Registry RIFT_v4/common/TIETypeType
Type of TIE. Type of TIE.
This enum indicates what TIE type the TIE is carrying. In case the This enum indicates what TIE type the TIE is carrying. In case the
value is not known to the receiver, the TIE MUST be re-flooded. This value is not known to the receiver, the TIE MUST be re-flooded. This
allows for future extensions of the protocol within the same major allows for future extensions of the protocol within the same major
schema with types opaque to some nodes UNLESS the flooding scope is schema with types opaque to some nodes UNLESS the flooding scope is
not the same as prefix TIE, then a major version revision MUST be not the same as prefix TIE, then a major version revision MUST be
performed. performed.
8.2.10.1. Requested Entries 8.2.10.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
Illegal 0 4.0 Illegal 0 4.1
TIETypeMinValue 1 4.0 TIETypeMinValue 1 4.1
NodeTIEType 2 4.0 NodeTIEType 2 4.1
PrefixTIEType 3 4.0 PrefixTIEType 3 4.1
PositiveDisaggregationPrefixTIEType 4 4.0 PositiveDisaggregationPrefixTIEType 4 4.1
NegativeDisaggregationPrefixTIEType 5 4.0 NegativeDisaggregationPrefixTIEType 5 4.1
PGPrefixTIEType 6 4.0 PGPrefixTIEType 6 4.1
KeyValueTIEType 7 4.0 KeyValueTIEType 7 4.1
ExternalPrefixTIEType 8 4.0 ExternalPrefixTIEType 8 4.1
PositiveExternalDisaggregationPrefixTIEType 9 4.0 PositiveExternalDisaggregationPrefixTIEType 9 4.1
TIETypeMaxValue 10 4.0 TIETypeMaxValue 10 4.1
8.2.11. Registry RIFT_v4/common/TieDirectionType 8.2.11. Registry RIFT_v4/common/TieDirectionType
Direction of TIEs. Direction of TIEs.
8.2.11.1. Requested Entries 8.2.11.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
Illegal 0 4.0 Illegal 0 4.1
South 1 4.0 South 1 4.1
North 2 4.0 North 2 4.1
DirectionMaxValue 3 4.0 DirectionMaxValue 3 4.1
8.2.12. Registry RIFT_v4/encoding/Community 8.2.12. Registry RIFT_v4/encoding/Community
Prefix community. Prefix community.
8.2.12.1. Requested Entries 8.2.12.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
top 1 4.0 Higher order bits top 1 4.1 Higher order bits
bottom 2 4.0 Lower order bits bottom 2 4.1 Lower order bits
8.2.13. Registry RIFT_v4/encoding/KeyValueTIEElement 8.2.13. Registry RIFT_v4/encoding/KeyValueTIEElement
Generic key value pairs. Generic key value pairs.
8.2.13.1. Requested Entries 8.2.13.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
keyvalues 1 4.0 keyvalues 1 4.1
8.2.14. Registry RIFT_v4/encoding/LIEPacket 8.2.14. Registry RIFT_v4/encoding/LIEPacket
RIFT LIE Packet. RIFT LIE Packet.
@note: this node's level is already included on the packet header @note: this node's level is already included on the packet header
8.2.14.1. Requested Entries 8.2.14.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
name 1 4.0 Node or adjacency name. name 1 4.1 Node or adjacency name.
local_id 2 4.0 Local link ID. local_id 2 4.1 Local link ID.
flood_port 3 4.0 UDP port to which we can flood_port 3 4.1 UDP port to which we can
receive flooded TIEs. receive flooded TIEs.
link_mtu_size 4 4.0 Layer 3 MTU, used to link_mtu_size 4 4.1 Layer 3 MTU, used to
discover to mismatch. discover to mismatch.
link_bandwidth 5 4.0 Local link bandwidth on link_bandwidth 5 4.1 Local link bandwidth on
the interface. the interface.
neighbor 6 4.0 Reflects the neighbor once neighbor 6 4.1 Reflects the neighbor once
received to provide received to provide
3-way connectivity. 3-way connectivity.
pod 7 4.0 Node's PoD. pod 7 4.1 Node's PoD.
node_capabilities 10 4.0 Node capabilities shown in node_capabilities 10 4.1 Node capabilities shown in
LIE. The capabilities LIE. The capabilities
MUST match the capabilities MUST match the capabilities
shown in the Node TIEs, shown in the Node TIEs,
otherwise the behavior otherwise the behavior
is unspecified. A node is unspecified. A node
detecting the mismatch detecting the mismatch
SHOULD generate according SHOULD generate according
error. error.
link_capabilities 11 4.0 Capabilities of this link. link_capabilities 11 4.1 Capabilities of this link.
holdtime 12 4.0 Required holdtime of the holdtime 12 4.1 Required holdtime of the
adjacency, i.e. how much adjacency, i.e. how much
time MUST expire time MUST expire
without LIE for the without LIE for the
adjacency to drop. adjacency to drop.
label 13 4.0 Unsolicited, downstream label 13 4.1 Unsolicited, downstream
assigned locally assigned locally
significant label value significant label value
for the adjacency. for the adjacency.
not_a_ztp_offer 21 4.0 Indicates that the level not_a_ztp_offer 21 4.1 Indicates that the level
on the LIE MUST NOT be used on the LIE MUST NOT be used
to derive a ZTP level by to derive a ZTP level by
the receiving node. the receiving node.
you_are_flood_repeater 22 4.0 Indicates to northbound you_are_flood_repeater 22 4.1 Indicates to northbound
neighbor that it should neighbor that it should
be reflooding this node's be reflooding this node's
North TIEs to achieve flood N-TIEs to achieve flood
reduction and balancing reduction and balancing
for northbound flooding. To for northbound flooding. To
be ignored if received be ignored if received
from a northbound from a northbound
adjacency. adjacency.
you_are_sending_too_quickly 23 4.0 Can be optionally set to you_are_sending_too_quickly 23 4.1 Can be optionally set to
indicate to neighbor that indicate to neighbor that
packet losses are seen packet losses are seen
on reception based on on reception based on
packet numbers or the rate packet numbers or the rate
is too high. The is too high. The
receiver SHOULD temporarily receiver SHOULD temporarily
slow down flooding slow down flooding
rates. rates.
instance_name 24 4.0 Instance name in case instance_name 24 4.1 Instance name in case
multiple RIFT instances multiple RIFT instances
running on same running on same
interface. interface.
8.2.15. Registry RIFT_v4/encoding/LinkCapabilities 8.2.15. Registry RIFT_v4/encoding/LinkCapabilities
Link capabilities. Link capabilities.
8.2.15.1. Requested Entries 8.2.15.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
bfd 1 4.0 Indicates that the link is bfd 1 4.1 Indicates that the link is
supporting BFD. supporting BFD.
v4_forwarding_capable 2 4.0 Indicates whether the interface v4_forwarding_capable 2 4.1 Indicates whether the interface
will support v4 forwarding. will support v4 forwarding.
8.2.16. Registry RIFT_v4/encoding/LinkIDPair 8.2.16. Registry RIFT_v4/encoding/LinkIDPair
LinkID pair describes one of parallel links between two nodes. LinkID pair describes one of parallel links between two nodes.
8.2.16.1. Requested Entries 8.2.16.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
local_id 1 4.0 Node-wide unique value for local_id 1 4.1 Node-wide unique value for
the local link. the local link.
remote_id 2 4.0 Received remote link ID for remote_id 2 4.1 Received remote link ID for
this link. this link.
platform_interface_index 10 4.0 Describes the local platform_interface_index 10 4.1 Describes the local
interface index of the link. interface index of the link.
platform_interface_name 11 4.0 Describes the local platform_interface_name 11 4.1 Describes the local
interface name. interface name.
trusted_outer_security_key 12 4.0 Indication whether the link trusted_outer_security_key 12 4.1 Indication whether the link
is secured, i.e. protected is secured, i.e. protected
by outer key, absence of by outer key, absence of
this element means no this element means no
indication, undefined indication, undefined
outer key means not secured. outer key means not secured.
bfd_up 13 4.0 Indication whether the link bfd_up 13 4.1 Indication whether the link
is protected by established is protected by established
BFD session. BFD session.
address_families 14 4.1 Optional indication which
address families are up on
the interface
8.2.17. Registry RIFT_v4/encoding/Neighbor 8.2.17. Registry RIFT_v4/encoding/Neighbor
Neighbor structure. Neighbor structure.
8.2.17.1. Requested Entries 8.2.17.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
originator 1 4.0 System ID of the originator. originator 1 4.1 System ID of the originator.
remote_id 2 4.0 ID of remote side of the link. remote_id 2 4.1 ID of remote side of the link.
8.2.18. Registry RIFT_v4/encoding/NodeCapabilities 8.2.18. Registry RIFT_v4/encoding/NodeCapabilities
Capabilities the node supports. Capabilities the node supports.
@note: The schema may add to this field future capabilities to @note: The schema may add to this field future capabilities to
indicate whether it will support interpretation of future schema indicate whether it will support interpretation of future schema
extensions on the same major revision. Such fields MUST be optional extensions on the same major revision. Such fields MUST be optional
and have an implicit or explicit false default value. If a future and have an implicit or explicit false default value. If a future
capability changes route selection or generates blackholes if some capability changes route selection or generates blackholes if some
skipping to change at page 132, line 4 skipping to change at page 132, line 6
@note: The schema may add to this field future capabilities to @note: The schema may add to this field future capabilities to
indicate whether it will support interpretation of future schema indicate whether it will support interpretation of future schema
extensions on the same major revision. Such fields MUST be optional extensions on the same major revision. Such fields MUST be optional
and have an implicit or explicit false default value. If a future and have an implicit or explicit false default value. If a future
capability changes route selection or generates blackholes if some capability changes route selection or generates blackholes if some
nodes are not supporting it then a major version increment is nodes are not supporting it then a major version increment is
unavoidable. unavoidable.
8.2.18.1. Requested Entries 8.2.18.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
protocol_minor_version 1 4.0 Must advertise supported minor protocol_minor_version 1 4.1 Must advertise supported minor
version dialect that way. version dialect that way.
flood_reduction 2 4.0 Can this node participate in flood_reduction 2 4.1 Can this node participate in
flood reduction. flood reduction.
hierarchy_indications 3 4.0 Does this node restrict itself hierarchy_indications 3 4.1 Does this node restrict itself
to be top-of-fabric or leaf to be top-of-fabric or leaf
only (in ZTP) and does it only (in ZTP) and does it
support leaf-2-leaf support leaf-2-leaf
procedures. procedures.
8.2.19. Registry RIFT_v4/encoding/NodeFlags 8.2.19. Registry RIFT_v4/encoding/NodeFlags
Indication flags of the node. Indication flags of the node.
8.2.19.1. Requested Entries 8.2.19.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
overload 1 4.0 Indicates that node is in overload, do not overload 1 4.1 Indicates that node is in overload, do not
transit traffic through it. transit traffic through it.
8.2.20. Registry RIFT_v4/encoding/NodeNeighborsTIEElement 8.2.20. Registry RIFT_v4/encoding/NodeNeighborsTIEElement
neighbor of a node neighbor of a node
8.2.20.1. Requested Entries 8.2.20.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
level 1 4.0 level of neighbor level 1 4.1 level of neighbor
cost 3 4.0 Cost to neighbor. cost 3 4.1 Cost to neighbor.
link_ids 4 4.0 can carry description of multiple parallel link_ids 4 4.1 can carry description of multiple parallel
links in a TIE links in a TIE
bandwidth 5 4.0 total bandwith to neighbor, this will be bandwidth 5 4.1 total bandwith to neighbor, this will be
normally sum of the bandwidths of all the normally sum of the bandwidths of all the
parallel links. parallel links.
8.2.21. Registry RIFT_v4/encoding/NodeTIEElement 8.2.21. Registry RIFT_v4/encoding/NodeTIEElement
Description of a node. Description of a node.
It may occur multiple times in different TIEs but if either It may occur multiple times in different TIEs but if either
capabilities values do not match or capabilities values do not match or
skipping to change at page 133, line 17 skipping to change at page 133, line 19
Neighbors can be distributed across multiple TIEs however if the sets Neighbors can be distributed across multiple TIEs however if the sets
are disjoint. Miscablings SHOULD be repeated in every node TIE, are disjoint. Miscablings SHOULD be repeated in every node TIE,
otherwise the behavior is undefined. otherwise the behavior is undefined.
@note: Observe that absence of fields implies defined defaults. @note: Observe that absence of fields implies defined defaults.
8.2.21.1. Requested Entries 8.2.21.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
level 1 4.0 Level of the node. level 1 4.1 Level of the node.
neighbors 2 4.0 Node's neighbors. If neighbor systemID neighbors 2 4.1 Node's neighbors. If neighbor systemID
repeats in other node TIEs of same repeats in other node TIEs of same
node the behavior is undefined. node the behavior is undefined.
capabilities 3 4.0 Capabilities of the node. capabilities 3 4.1 Capabilities of the node.
flags 4 4.0 Flags of the node. flags 4 4.1 Flags of the node.
name 5 4.0 Optional node name for easier name 5 4.1 Optional node name for easier
operations. operations.
pod 6 4.0 PoD to which the node belongs. pod 6 4.1 PoD to which the node belongs.
miscabled_links 10 4.0 If any local links are miscabled, the startup_time 7 4.1 optional startup time of the node
miscabled_links 10 4.1 If any local links are miscabled, the
indication is flooded. indication is flooded.
8.2.22. Registry RIFT_v4/encoding/PacketContent 8.2.22. Registry RIFT_v4/encoding/PacketContent
Content of a RIFT packet. Content of a RIFT packet.
8.2.22.1. Requested Entries 8.2.22.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
lie 1 4.0 lie 1 4.1
tide 2 4.0 tide 2 4.1
tire 3 4.0 tire 3 4.1
tie 4 4.0 tie 4 4.1
8.2.23. Registry RIFT_v4/encoding/PacketHeader 8.2.23. Registry RIFT_v4/encoding/PacketHeader
Common RIFT packet header. Common RIFT packet header.
8.2.23.1. Requested Entries 8.2.23.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
major_version 1 4.0 Major version of protocol. major_version 1 4.1 Major version of protocol.
minor_version 2 4.0 Minor version of protocol. minor_version 2 4.1 Minor version of protocol.
sender 3 4.0 Node sending the packet, in case of sender 3 4.1 Node sending the packet, in case of
LIE/TIRE/TIDE also the originator of LIE/TIRE/TIDE also the originator of
it. it.
level 4 4.0 Level of the node sending the packet, level 4 4.1 Level of the node sending the packet,
required on everything except LIEs. required on everything except LIEs.
Lack of presence on LIEs indicates Lack of presence on LIEs indicates
UNDEFINED_LEVEL and is used in ZTP UNDEFINED_LEVEL and is used in ZTP
procedures. procedures.
8.2.24. Registry RIFT_v4/encoding/PrefixAttributes 8.2.24. Registry RIFT_v4/encoding/PrefixAttributes
Attributes of a prefix. Attributes of a prefix.
8.2.24.1. Requested Entries 8.2.24.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
metric 2 4.0 Distance of the prefix. metric 2 4.1 Distance of the prefix.
tags 3 4.0 Generic unordered set of route tags, tags 3 4.1 Generic unordered set of route tags,
can be redistributed to other can be redistributed to other
protocols or use within the context protocols or use within the context
of real time analytics. of real time analytics.
monotonic_clock 4 4.0 Monotonic clock for mobile monotonic_clock 4 4.1 Monotonic clock for mobile
addresses. addresses.
loopback 6 4.0 Indicates if the interface is a node loopback 6 4.1 Indicates if the interface is a node
loopback. loopback.
directly_attached 7 4.0 Indicates that the prefix is directly_attached 7 4.1 Indicates that the prefix is
directly attached, i.e. should be directly attached, i.e. should be
routed to even if the node is in routed to even if the node is in
overload. overload.
from_link 10 4.0 In case of locally originated from_link 10 4.1 In case of locally originated
prefixes, i.e. interface prefixes, i.e. interface
addresses this can describe which addresses this can describe which
link the address belongs to. link the address belongs to.
8.2.25. Registry RIFT_v4/encoding/PrefixTIEElement 8.2.25. Registry RIFT_v4/encoding/PrefixTIEElement
TIE carrying prefixes TIE carrying prefixes
8.2.25.1. Requested Entries 8.2.25.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
prefixes 1 4.0 Prefixes with the associated attributes. prefixes 1 4.1 Prefixes with the associated attributes.
If the same prefix repeats in multiple TIEs of If the same prefix repeats in multiple TIEs of
same node behavior is unspecified. same node behavior is unspecified.
8.2.26. Registry RIFT_v4/encoding/ProtocolPacket 8.2.26. Registry RIFT_v4/encoding/ProtocolPacket
RIFT packet structure. RIFT packet structure.
8.2.26.1. Requested Entries 8.2.26.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
header 1 4.0 header 1 4.1
content 2 4.0 content 2 4.1
8.2.27. Registry RIFT_v4/encoding/TIDEPacket 8.2.27. Registry RIFT_v4/encoding/TIDEPacket
TIDE with sorted TIE headers, if headers are unsorted, behavior is TIDE with sorted TIE headers, if headers are unsorted, behavior is
undefined. undefined.
8.2.27.1. Requested Entries 8.2.27.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
start_range 1 4.0 First TIE header in the tide start_range 1 4.1 First TIE header in the tide
packet. packet.
end_range 2 4.0 Last TIE header in the tide packet. end_range 2 4.1 Last TIE header in the tide packet.
headers 3 4.0 _Sorted_ list of headers. headers 3 4.1 _Sorted_ list of headers.
8.2.28. Registry RIFT_v4/encoding/TIEElement 8.2.28. Registry RIFT_v4/encoding/TIEElement
Single element in a TIE. Single element in a TIE.
Schema enum `common.TIETypeType` in TIEID indicates which elements Schema enum `common.TIETypeType` in TIEID indicates which elements
MUST be present in the TIEElement. In case of mismatch the MUST be present in the TIEElement. In case of mismatch the
unexpected elements MUST be ignored. In case of lack of expected unexpected elements MUST be ignored. In case of lack of expected
element the TIE an error MUST be reported and the TIE MUST be element the TIE an error MUST be reported and the TIE MUST be
ignored. ignored.
skipping to change at page 136, line 10 skipping to change at page 136, line 10
This type can be extended with new optional elements for new This type can be extended with new optional elements for new
`common.TIETypeType` values without breaking the major but if it is `common.TIETypeType` values without breaking the major but if it is
necessary to understand whether all nodes support the new type a node necessary to understand whether all nodes support the new type a node
capability must be added as well. capability must be added as well.
8.2.28.1. Requested Entries 8.2.28.1. Requested Entries
Name Valu Schem Description Name Valu Schem Description
e a Ver e a Ver
sion sion
node 1 4.0 Used in case of enum comm node 1 4.1 Used in case of enum comm
on.TIETypeType.NodeTIEType on.TIETypeType.NodeTIEType
. .
prefixes 2 4.0 Used in case of enum comm prefixes 2 4.1 Used in case of enum comm
on.TIETypeType.PrefixTIETy on.TIETypeType.PrefixTIETy
pe. pe.
positive_disaggregation_prefixe 3 4.0 Positive prefixes (always positive_disaggregation_prefixe 3 4.1 Positive prefixes (always
s southbound). It MUST s southbound). It MUST
NOT be advertised within a NOT be advertised within a
North TIE and ignored North TIE and ignored
otherwise. otherwise.
negative_disaggregation_prefixe 5 4.0 Transitive, negative negative_disaggregation_prefixe 5 4.1 Transitive, negative
s prefixes (always s prefixes (always
southbound) which MUST southbound) which MUST
be aggregated and be aggregated and
propagated according propagated according
to the specification to the specification
southwards towards lower southwards towards lower
levels to heal levels to heal
pathological upper level pathological upper level
partitioning, otherwise partitioning, otherwise
blackholes may occur in blackholes may occur in
multiplane fabrics. It multiplane fabrics. It
MUST NOT be advertised MUST NOT be advertised
within a North TIE. within a North TIE.
external_prefixes 6 4.0 Externally reimported external_prefixes 6 4.1 Externally reimported
prefixes. prefixes.
positive_external_disaggregatio 7 4.0 Positive external positive_external_disaggregatio 7 4.1 Positive external
n_prefixes disaggregated prefixes n_prefixes disaggregated prefixes
(always southbound). (always southbound).
It MUST NOT be advertised It MUST NOT be advertised
within a North TIE and within a North TIE and
ignored otherwise. ignored otherwise.
keyvalues 9 4.0 Key-Value store elements. keyvalues 9 4.1 Key-Value store elements.
8.2.29. Registry RIFT_v4/encoding/TIEHeader 8.2.29. Registry RIFT_v4/encoding/TIEHeader
Header of a TIE. Header of a TIE.
@note: TIEID space is a total order achieved by comparing the @note: TIEID space is a total order achieved by comparing the
elements in sequence defined and comparing each value as an unsigned elements in sequence defined and comparing each value as an unsigned
integer of according length. integer of according length.
@note: After sequence number the lifetime received on the envelope @note: After sequence number the lifetime received on the envelope
must be used for comparison before further fields. must be used for comparison before further fields.
@note: `origination_time` and `origination_lifetime` are disregarded @note: `origination_time` and `origination_lifetime` are normally
for comparison purposes and carried purely for debugging/security disregarded for comparison purposes and carried purely for debugging/
purposes if present. security purposes if present. They may be used for comparison of
last resort to differentiate otherwise equal ties
8.2.29.1. Requested Entries 8.2.29.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
tieid 2 4.0 ID of the tie. tieid 2 4.1 ID of the tie.
seq_nr 3 4.0 Sequence number of the tie. seq_nr 3 4.1 Sequence number of the tie.
origination_time 10 4.0 Absolute timestamp when the TIE origination_time 10 4.1 Absolute timestamp when the TIE
was generated. This can be used on was generated. This can be used on
fabrics with synchronized fabrics with synchronized
clock to prevent lifetime clock to prevent lifetime
modification attacks. modification attacks.
origination_lifetime 12 4.0 Original lifetime when the TIE origination_lifetime 12 4.1 Original lifetime when the TIE
was generated. This can be used on was generated. This can be used on
fabrics with synchronized fabrics with synchronized
clock to prevent lifetime clock to prevent lifetime
modification attacks. modification attacks.
8.2.30. Registry RIFT_v4/encoding/TIEHeaderWithLifeTime 8.2.30. Registry RIFT_v4/encoding/TIEHeaderWithLifeTime
Header of a TIE as described in TIRE/TIDE. Header of a TIE as described in TIRE/TIDE.
8.2.30.1. Requested Entries 8.2.30.1. Requested Entries
Name Value Schema Description Name Value Schema Description
Version Version
header 1 4.0 header 1 4.1
remaining_lifetime 2 4.0 Remaining lifetime that expires remaining_lifetime 2 4.1 Remaining lifetime that expires
down to 0 just like in ISIS. down to 0 just like in ISIS.
TIEs with lifetimes differing by TIEs with lifetimes differing by
less than `lifetime_diff2ignore` less than `lifetime_diff2ignore`
MUST be considered EQUAL. MUST be considered EQUAL.
8.2.31. Registry RIFT_v4/encoding/TIEID 8.2.31. Registry RIFT_v4/encoding/TIEID
ID of a TIE. ID of a TIE.
@note: TIEID space is a total order achieved by comparing the @note: TIEID space is a total order achieved by comparing the
elements in sequence defined and comparing each value as an unsigned elements in sequence defined and comparing each value as an unsigned
integer of according length. integer of according length.
8.2.31.1. Requested Entries 8.2.31.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
direction 1 4.0 direction of TIE direction 1 4.1 direction of TIE
originator 2 4.0 indicates originator of the TIE originator 2 4.1 indicates originator of the TIE
tietype 3 4.0 type of the tie tietype 3 4.1 type of the tie
tie_nr 4 4.0 number of the tie tie_nr 4 4.1 number of the tie
8.2.32. Registry RIFT_v4/encoding/TIEPacket 8.2.32. Registry RIFT_v4/encoding/TIEPacket
TIE packet TIE packet
8.2.32.1. Requested Entries 8.2.32.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
header 1 4.0 header 1 4.1
element 2 4.0 element 2 4.1
8.2.33. Registry RIFT_v4/encoding/TIREPacket 8.2.33. Registry RIFT_v4/encoding/TIREPacket
TIRE packet TIRE packet
8.2.33.1. Requested Entries 8.2.33.1. Requested Entries
Name Value Schema Version Description Name Value Schema Version Description
headers 1 4.0 headers 1 4.1
9. Acknowledgments 9. Acknowledgments
A new routing protocol in its complexity is not a product of a parent A new routing protocol in its complexity is not a product of a parent
but of a village as the author list shows already. However, many but of a village as the author list shows already. However, many
more people provided input, fine-combed the specification based on more people provided input, fine-combed the specification based on
their experience in design, implementation or application of their experience in design, implementation or application of
protocols in IP fabrics. This section will make an inadequate protocols in IP fabrics. This section will make an inadequate
attempt in recording their contribution. attempt in recording their contribution.
Many thanks to Naiming Shen for some of the early discussions around Many thanks to Naiming Shen for some of the early discussions around
the topic of using IGPs for routing in topologies related to Clos. the topic of using IGPs for routing in topologies related to Clos.
Russ White to be especially acknowledged for the key conversation on Russ White to be especially acknowledged for the key conversation on
epistemology that allowed to tie current asynchronous distributed epistemology that allowed to tie current asynchronous distributed
systems theory results to a modern protocol design presented in this systems theory results to a modern protocol design presented in this
scope. Adrian Farrel, Joel Halpern, Jeffrey Zhang, Krzysztof scope. Adrian Farrel, Joel Halpern, Jeffrey Zhang, Krzysztof
Szarkowicz, Nagendra Kumar, Melchior Aelmans, Kaushal Tank, Will Szarkowicz, Nagendra Kumar, Melchior Aelmans, Kaushal Tank, Will
Jones, Moin Ahmed and Jordan Head provided thoughtful comments that Jones, Moin Ahmed, Sandy Zhang and Jordan Head (in no particular
improved the readability of the document and found good amount of order) provided thoughtful comments that improved the readability of
corners where the light failed to shine. Kris Price was first to the document and found good amount of corners where the light failed
mention single router, single arm default considerations. Jeff to shine. Kris Price was first to mention single router, single arm
Tantsura helped out with some initial thoughts on BFD interactions default considerations. Jeff Tantsura helped out with some initial
while Jeff Haas corrected several misconceptions about BFD's finer thoughts on BFD interactions while Jeff Haas corrected several
points. Artur Makutunowicz pointed out many possible improvements misconceptions about BFD's finer points and helped to improve the
and acted as sounding board in regard to modern protocol security section around leaf considerations. Artur Makutunowicz
implementation techniques RIFT is exploring. Barak Gafni formalized pointed out many possible improvements and acted as sounding board in
first time clearly the problem of partitioned spine and fallen leaves regard to modern protocol implementation techniques RIFT is
on a (clean) napkin in Singapore that led to the very important part exploring. Barak Gafni formalized first time clearly the problem of
of the specification centered around multiple Top-of-Fabric planes partitioned spine and fallen leaves on a (clean) napkin in Singapore
and negative disaggregation. Igor Gashinsky and others shared many that led to the very important part of the specification centered
thoughts on problems encountered in design and operation of large- around multiple Top-of-Fabric planes and negative disaggregation.
scale data center fabrics. Xu Benchong found a delicate error in the Igor Gashinsky and others shared many thoughts on problems
flooding procedures and a schema datatype size mismatch. encountered in design and operation of large-scale data center
fabrics. Xu Benchong found a delicate error in the flooding
procedures and a schema datatype size mismatch.
Last but not least, Alvaro Retana guided the undertaking by asking Last but not least, Alvaro Retana guided the undertaking by asking
many necessary procedural and technical questions which did not only many necessary procedural and technical questions which did not only
improve the content but did also lay out the track towards improve the content but did also lay out the track towards
publication. publication.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 141, line 5 skipping to change at page 141, line 5
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010, DOI 10.17487/RFC5881, June 2010,
<https://www.rfc-editor.org/info/rfc5881>. <https://www.rfc-editor.org/info/rfc5881>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC7987] Ginsberg, L., Wells, P., Decraene, B., Przygienda, T., and [RFC7987] Ginsberg, L., Wells, P., Decraene, B., Przygienda, T., and
H. Gredler, "IS-IS Minimum Remaining Lifetime", RFC 7987, H. Gredler, "IS-IS Minimum Remaining Lifetime", RFC 7987,
DOI 10.17487/RFC7987, October 2016, DOI 10.17487/RFC7987, October 2016,
<https://www.rfc-editor.org/info/rfc7987>. <https://www.rfc-editor.org/info/rfc7987>.
skipping to change at page 152, line 21 skipping to change at page 152, line 21
} }
B.2. encoding.thrift B.2. encoding.thrift
/** /**
Thrift file for packet encodings for RIFT Thrift file for packet encodings for RIFT
*/ */
include "common.thrift" include "common.thrift"
namespace rs models
namespace py encoding
/** Represents protocol encoding schema major version */ /** Represents protocol encoding schema major version */
const common.VersionType protocol_major_version = 4 const common.VersionType protocol_major_version = 4
/** Represents protocol encoding schema minor version */ /** Represents protocol encoding schema minor version */
const common.MinorVersionType protocol_minor_version = 0 const common.MinorVersionType protocol_minor_version = 1
/** Common RIFT packet header. */ /** Common RIFT packet header. */
struct PacketHeader { struct PacketHeader {
/** Major version of protocol. */ /** Major version of protocol. */
1: required common.VersionType major_version = 1: required common.VersionType major_version =
protocol_major_version; protocol_major_version;
/** Minor version of protocol. */ /** Minor version of protocol. */
2: required common.MinorVersionType minor_version = 2: required common.MinorVersionType minor_version =
protocol_minor_version; protocol_minor_version;
/** Node sending the packet, in case of LIE/TIRE/TIDE /** Node sending the packet, in case of LIE/TIRE/TIDE
skipping to change at page 155, line 36 skipping to change at page 155, line 39
/** Describes the local interface name. */ /** Describes the local interface name. */
11: optional string platform_interface_name; 11: optional string platform_interface_name;
/** Indication whether the link is secured, i.e. protected by /** Indication whether the link is secured, i.e. protected by
outer key, absence of this element means no indication, outer key, absence of this element means no indication,
undefined outer key means not secured. */ undefined outer key means not secured. */
12: optional common.OuterSecurityKeyID 12: optional common.OuterSecurityKeyID
trusted_outer_security_key; trusted_outer_security_key;
/** Indication whether the link is protected by established /** Indication whether the link is protected by established
BFD session. */ BFD session. */
13: optional bool bfd_up; 13: optional bool bfd_up;
/** Optional indication which address families are up on the
interface */
14: optional set<common.AddressFamilyType> address_families;
} }
/** ID of a TIE. /** ID of a TIE.
@note: TIEID space is a total order achieved by comparing @note: TIEID space is a total order achieved by comparing
the elements in sequence defined and comparing each the elements in sequence defined and comparing each
value as an unsigned integer of according length. value as an unsigned integer of according length.
*/ */
struct TIEID { struct TIEID {
/** direction of TIE */ /** direction of TIE */
skipping to change at page 156, line 16 skipping to change at page 156, line 22
/** Header of a TIE. /** Header of a TIE.
@note: TIEID space is a total order achieved by comparing @note: TIEID space is a total order achieved by comparing
the elements in sequence defined and comparing each the elements in sequence defined and comparing each
value as an unsigned integer of according length. value as an unsigned integer of according length.
@note: After sequence number the lifetime received on the envelope @note: After sequence number the lifetime received on the envelope
must be used for comparison before further fields. must be used for comparison before further fields.
@note: `origination_time` and `origination_lifetime` are disregarded @note: `origination_time` and `origination_lifetime` are
for comparison purposes and carried purely for normally disregarded for comparison purposes and carried
debugging/security purposes if present. purely for debugging/security purposes if present.
They may be used for comparison of last resort to
differentiate otherwise equal ties
*/ */
struct TIEHeader { struct TIEHeader {
/** ID of the tie. */ /** ID of the tie. */
2: required TIEID tieid; 2: required TIEID tieid;
/** Sequence number of the tie. */ /** Sequence number of the tie. */
3: required common.SeqNrType seq_nr; 3: required common.SeqNrType seq_nr;
/** Absolute timestamp when the TIE /** Absolute timestamp when the TIE
was generated. This can be used on fabrics with was generated. This can be used on fabrics with
synchronized clock to prevent lifetime modification attacks. */ synchronized clock to prevent lifetime modification attacks. */
 End of changes. 112 change blocks. 
220 lines changed or deleted 248 lines changed or added

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