< draft-ietf-rift-rift-05.txt   draft-ietf-rift-rift-06.txt >
RIFT Working Group The RIFT Authors RIFT Working Group The RIFT Authors
Internet-Draft April 23, 2019 Internet-Draft June 23, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: October 25, 2019 Expires: December 25, 2019
RIFT: Routing in Fat Trees RIFT: Routing in Fat Trees
draft-ietf-rift-rift-05 draft-ietf-rift-rift-06
Abstract Abstract
This document outlines a specialized, dynamic routing protocol for This document outlines a specialized, dynamic routing protocol for
Clos and fat-tree network topologies. The protocol (1) deals with Clos and fat-tree network topologies. The protocol (1) deals with
fully automated construction of fat-tree topologies based on fully automated construction of fat-tree topologies based on
detection of links, (2) minimizes the amount of routing state held at detection of links, (2) minimizes the amount of routing state held at
each level, (3) automatically prunes and load balances topology each level, (3) automatically prunes and load balances topology
flooding exchanges over a sufficient subset of links, (4) supports flooding exchanges over a sufficient subset of links, (4) supports
automatic disaggregation of prefixes on link and node failures to automatic disaggregation of prefixes on link and node failures to
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 October 25, 2019. This Internet-Draft will expire on December 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 3, line 41 skipping to change at page 3, line 41
5.3.8.1. Global Segment Identifiers Assignment . . . . . . 78 5.3.8.1. Global Segment Identifiers Assignment . . . . . . 78
5.3.8.2. Distribution of Topology Information . . . . . . 78 5.3.8.2. Distribution of Topology Information . . . . . . 78
5.3.9. Leaf to Leaf Procedures . . . . . . . . . . . . . . . 79 5.3.9. Leaf to Leaf Procedures . . . . . . . . . . . . . . . 79
5.3.10. Address Family and Multi Topology Considerations . . 79 5.3.10. Address Family and Multi Topology Considerations . . 79
5.3.11. Reachability of Internal Nodes in the Fabric . . . . 79 5.3.11. Reachability of Internal Nodes in the Fabric . . . . 79
5.3.12. One-Hop Healing of Levels with East-West Links . . . 80 5.3.12. One-Hop Healing of Levels with East-West Links . . . 80
5.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 80 5.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 80
5.4.1. Security Model . . . . . . . . . . . . . . . . . . . 80 5.4.1. Security Model . . . . . . . . . . . . . . . . . . . 80
5.4.2. Security Mechanisms . . . . . . . . . . . . . . . . . 82 5.4.2. Security Mechanisms . . . . . . . . . . . . . . . . . 82
5.4.3. Security Envelope . . . . . . . . . . . . . . . . . . 82 5.4.3. Security Envelope . . . . . . . . . . . . . . . . . . 82
5.4.4. Nonces . . . . . . . . . . . . . . . . . . . . . . . 85 5.4.4. Weak Nonces . . . . . . . . . . . . . . . . . . . . . 85
5.4.5. Lifetime . . . . . . . . . . . . . . . . . . . . . . 86 5.4.5. Lifetime . . . . . . . . . . . . . . . . . . . . . . 86
5.4.6. Key Management . . . . . . . . . . . . . . . . . . . 86 5.4.6. Key Management . . . . . . . . . . . . . . . . . . . 86
5.4.7. Security Association Changes . . . . . . . . . . . . 86 5.4.7. Security Association Changes . . . . . . . . . . . . 86
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.1. Normal Operation . . . . . . . . . . . . . . . . . . . . 87 6.1. Normal Operation . . . . . . . . . . . . . . . . . . . . 87
6.2. Leaf Link Failure . . . . . . . . . . . . . . . . . . . . 88 6.2. Leaf Link Failure . . . . . . . . . . . . . . . . . . . . 88
6.3. Partitioned Fabric . . . . . . . . . . . . . . . . . . . 89 6.3. Partitioned Fabric . . . . . . . . . . . . . . . . . . . 89
6.4. Northbound Partitioned Router and Optional East-West 6.4. Northbound Partitioned Router and Optional East-West
Links . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Links . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.5. Multi-Plane Fabric and Negative Disaggregation . . . . . 91 6.5. Multi-Plane Fabric and Negative Disaggregation . . . . . 92
7. Implementation and Operation: Further Details . . . . . . . . 91 7. Implementation and Operation: Further Details . . . . . . . . 92
7.1. Considerations for Leaf-Only Implementation . . . . . . . 91 7.1. Considerations for Leaf-Only Implementation . . . . . . . 92
7.2. Considerations for Spine Implementation . . . . . . . . . 92 7.2. Considerations for Spine Implementation . . . . . . . . . 93
7.3. Adaptations to Other Proposed Data Center Topologies . . 92 7.3. Adaptations to Other Proposed Data Center Topologies . . 93
7.4. Originating Non-Default Route Southbound . . . . . . . . 93 7.4. Originating Non-Default Route Southbound . . . . . . . . 94
8. Security Considerations . . . . . . . . . . . . . . . . . . . 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 95
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.2. ZTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.2. ZTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.3. Lifetime . . . . . . . . . . . . . . . . . . . . . . . . 94 8.3. Lifetime . . . . . . . . . . . . . . . . . . . . . . . . 95
8.4. Packet Number . . . . . . . . . . . . . . . . . . . . . . 94 8.4. Packet Number . . . . . . . . . . . . . . . . . . . . . . 95
8.5. Outer Fingerprint Attacks . . . . . . . . . . . . . . . . 95 8.5. Outer Fingerprint Attacks . . . . . . . . . . . . . . . . 96
8.6. Inner Fingerprint DoS Attacks . . . . . . . . . . . . . . 95 8.6. TIE Origin Fingerprint DoS Attacks . . . . . . . . . . . 96
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 97
11.1. Normative References . . . . . . . . . . . . . . . . . . 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 97
11.2. Informative References . . . . . . . . . . . . . . . . . 98 11.2. Informative References . . . . . . . . . . . . . . . . . 99
Appendix A. Sequence Number Binary Arithmetic . . . . . . . . . 100 Appendix A. Sequence Number Binary Arithmetic . . . . . . . . . 102
Appendix B. Information Elements Schema . . . . . . . . . . . . 101 Appendix B. Information Elements Schema . . . . . . . . . . . . 103
B.1. common.thrift . . . . . . . . . . . . . . . . . . . . . . 102 B.1. common.thrift . . . . . . . . . . . . . . . . . . . . . . 103
B.2. encoding.thrift . . . . . . . . . . . . . . . . . . . . . 108 B.2. encoding.thrift . . . . . . . . . . . . . . . . . . . . . 109
Appendix C. Finite State Machines and Precise Operational Appendix C. Finite State Machines and Precise Operational
Specifications . . . . . . . . . . . . . . . . . . . 115 Specifications . . . . . . . . . . . . . . . . . . . 117
C.1. LIE FSM . . . . . . . . . . . . . . . . . . . . . . . . . 116 C.1. LIE FSM . . . . . . . . . . . . . . . . . . . . . . . . . 117
C.2. ZTP FSM . . . . . . . . . . . . . . . . . . . . . . . . . 122 C.2. ZTP FSM . . . . . . . . . . . . . . . . . . . . . . . . . 123
C.3. Flooding Procedures . . . . . . . . . . . . . . . . . . . 130 C.3. Flooding Procedures . . . . . . . . . . . . . . . . . . . 131
C.3.1. FloodState Structure per Adjacency . . . . . . . . . 130 C.3.1. FloodState Structure per Adjacency . . . . . . . . . 132
C.3.2. TIDEs . . . . . . . . . . . . . . . . . . . . . . . . 132 C.3.2. TIDEs . . . . . . . . . . . . . . . . . . . . . . . . 134
C.3.2.1. TIDE Generation . . . . . . . . . . . . . . . . . 132 C.3.2.1. TIDE Generation . . . . . . . . . . . . . . . . . 134
C.3.2.2. TIDE Processing . . . . . . . . . . . . . . . . . 133 C.3.2.2. TIDE Processing . . . . . . . . . . . . . . . . . 135
C.3.3. TIREs . . . . . . . . . . . . . . . . . . . . . . . . 134 C.3.3. TIREs . . . . . . . . . . . . . . . . . . . . . . . . 136
C.3.3.1. TIRE Generation . . . . . . . . . . . . . . . . . 134 C.3.3.1. TIRE Generation . . . . . . . . . . . . . . . . . 136
C.3.3.2. TIRE Processing . . . . . . . . . . . . . . . . . 134 C.3.3.2. TIRE Processing . . . . . . . . . . . . . . . . . 136
C.3.4. TIEs Processing on Flood State Adjacency . . . . . . 135 C.3.4. TIEs Processing on Flood State Adjacency . . . . . . 137
C.3.5. TIEs Processing When LSDB Received Newer Version on C.3.5. TIEs Processing When LSDB Received Newer Version on
Other Adjacencies . . . . . . . . . . . . . . . . . . 136 Other Adjacencies . . . . . . . . . . . . . . . . . . 138
C.3.6. Sending TIEs . . . . . . . . . . . . . . . . . . . . 136 C.3.6. Sending TIEs . . . . . . . . . . . . . . . . . . . . 138
Appendix D. Constants . . . . . . . . . . . . . . . . . . . . . 136 Appendix D. Constants . . . . . . . . . . . . . . . . . . . . . 138
D.1. Configurable Protocol Constants . . . . . . . . . . . . . 136 D.1. Configurable Protocol Constants . . . . . . . . . . . . . 138
Appendix E. TODO . . . . . . . . . . . . . . . . . . . . . . . . 138 Appendix E. TODO . . . . . . . . . . . . . . . . . . . . . . . . 140
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 138 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 140
1. Authors 1. Authors
This work is a product of a growing list of individuals. This work is a product of a growing list of individuals.
Tony Przygienda, Ed | Alankar Sharma | Pascal Thubert Tony Przygienda, Ed | Alankar Sharma | Pascal Thubert
Juniper Networks | Comcast | Cisco Juniper Networks | Comcast | Cisco
Bruno Rijsman | Ilya Vershkov | Dmitry Afanasiev Bruno Rijsman | Ilya Vershkov | Dmitry Afanasiev
Individual | Mellanox | Yandex Individual | Mellanox | Yandex
skipping to change at page 82, line 38 skipping to change at page 82, line 38
The model in the previous section allows a range of security key The model in the previous section allows a range of security key
types that are analogous to the various security association models. types that are analogous to the various security association models.
PAM and NAM allow security associations at the port or node level PAM and NAM allow security associations at the port or node level
using symmetric or asymmetric keys that are pre-installed. FAM using symmetric or asymmetric keys that are pre-installed. FAM
argues for security associations to be applied only at a group level argues for security associations to be applied only at a group level
or to be refined once the topology has been established. RIFT does or to be refined once the topology has been established. RIFT does
not specify how security keys are installed or updated it specifies not specify how security keys are installed or updated it specifies
how the key can be used to achieve goals. how the key can be used to achieve goals.
The protocol has provisions for nonces to prevent replay attacks and The protocol has provisions for "weak" nonces to prevent replay
includes authentication mechanisms comparable to [RFC5709] and attacks and includes authentication mechanisms comparable to
[RFC7987]. [RFC5709] and [RFC7987].
5.4.3. Security Envelope 5.4.3. Security Envelope
RIFT MUST be carried in a mandatory secure envelope illustrated in RIFT MUST be carried in a mandatory secure envelope illustrated in
Figure 31. Local configuration can allow to skip the checking of the Figure 31. Any value in the packet following a security fingerprint
envelope's integrity. MUST be used only after the according fingerprint has been validated.
Local configuration MAY allow to skip the checking of the envelope's
integrity.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
UDP Header: UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | RIFT destination port | | Source Port | RIFT destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum | | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 83, line 26 skipping to change at page 83, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIFT MAGIC | Packet Number | | RIFT MAGIC | Packet Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | RIFT Major | Outer Key ID | Fingerprint | | Reserved | RIFT Major | Outer Key ID | Fingerprint |
| | Version | | Length | | | Version | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Security Fingerprint covers all following content ~ ~ Security Fingerprint covers all following content ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce Local | Nonce Remote | | Weak Nonce Local | Weak Nonce Remote |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remaining TIE Lifetime (all 1s in case of LIE) | | Remaining TIE Lifetime (all 1s in case of LIE) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TIE Origin Security Envelope Header: TIE Origin Security Envelope Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Key ID | Fingerprint | | TIE Origin Key ID | Fingerprint |
| | Length | | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Security Fingerprint covers all following content ~ ~ Security Fingerprint covers all following content ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Serialized RIFT Model Object Serialized RIFT Model Object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 84, line 25 skipping to change at page 84, line 25
flooding behavior to current link or buffer quality. This number flooding behavior to current link or buffer quality. This number
MUST NOT be used to discard or validate the correctness of MUST NOT be used to discard or validate the correctness of
packets. packets.
RIFT Major Version: 8 bits. It allows to check whether protocol RIFT Major Version: 8 bits. It allows to check whether protocol
versions are compatible, i.e. the serialized object can be decoded versions are compatible, i.e. the serialized object can be decoded
at all. An implementation MUST drop packets with unexpected value at all. An implementation MUST drop packets with unexpected value
and MAY report a problem. Must be same as in encoded model and MAY report a problem. Must be same as in encoded model
object, otherwise packet is dropped. object, otherwise packet is dropped.
Inner Key ID: 8 bits to allow key rollovers. This implies key type Outer Key ID: 8 bits to allow key rollovers. This implies key type
and used algorithm. Value 0 means that no valid fingerprint was and used algorithm. Value 0 means that no valid fingerprint was
computed. This key ID scope is local to the nodes on both ends of computed. This key ID scope is local to the nodes on both ends of
the adjacency. the adjacency.
Outer Key ID: 24 bits. This implies key type and used algorithm. TIE Origin Key ID: 24 bits. This implies key type and used
Value 0 means that no valid fingerprint was computed. This key ID algorithm. Value 0 means that no valid fingerprint was computed.
scope is global to the RIFT instance since it implies the This key ID scope is global to the RIFT instance since it implies
originator of the TIE so the contained object does not have to be the originator of the TIE so the contained object does not have to
de-serialized to obtain it. be de-serialized to obtain it.
Length of Fingerprint: 8 bits. Length in 32-bit multiples of the Length of Fingerprint: 8 bits. Length in 32-bit multiples of the
following fingerprint not including lifetime or nonces. It allows following fingerprint not including lifetime or weak nonces. It
to navigate the structure when an unknown key type is present. To allows to navigate the structure when an unknown key type is
clarify a common cornercase when this value is set to 0 it present. To clarify a common cornercase when this value is set to
signifies an empty (0 bytes long) security fingerprint. 0 it signifies an empty (0 bytes long) security fingerprint.
Security Fingerprint: 32 bits * Length of Fingerprint. This is a Security Fingerprint: 32 bits * Length of Fingerprint. This is a
signature that is computed over all data following after it. If signature that is computed over all data following after it. If
the signficant bits of fingerprint are fewer than the 32 bits the signficant bits of fingerprint are fewer than the 32 bits
padded length than the signficant bits MUST be left aligned and padded length than the signficant bits MUST be left aligned and
remaining bits on the right padded with 0s. When using PKI the remaining bits on the right padded with 0s. When using PKI the
Security fingerprint originating node uses its private key to Security fingerprint originating node uses its private key to
create the signature. The original packet can then be verified create the signature. The original packet can then be verified
provided the public key is shared and current. provided the public key is shared and current.
Remaining TIE Lifetime: 32 bits. In case of anything but TIEs this Remaining TIE Lifetime: 32 bits. In case of anything but TIEs this
field MUST be set to all ones and Origin Security Envelope Header field MUST be set to all ones and Origin Security Envelope Header
MUST NOT be present in the packet. For TIEs this field represents MUST NOT be present in the packet. For TIEs this field represents
the remaining lifetime of the TIE and Origin Security Envelope the remaining lifetime of the TIE and Origin Security Envelope
Header MUST be present in the packet. The value in the serialized Header MUST be present in the packet. The value in the serialized
model object MUST be ignored. model object MUST be ignored.
Nonce Local: 16 bits. Local Nonce of the adjacency as advertised Weak Nonce Local: 16 bits. Local Weak Nonce of the adjacency as
in LIEs. In case of LIE packet this MUST correspond to the value advertised in LIEs.
in the serialized object otherwise the packet MUST be discarded.
Nonce Remote: 16 bits. Remote Nonce of the adjacency as received Weak Nonce Remote: 16 bits. Remote Weak Nonce of the adjacency as
in LIEs. In case of LIE packet this MUST correspond to the value received in LIEs.
in the serialized object otherwise the packet MUST be discarded.
TIE Origin Security Envelope Header: It MUST be present if Remaining TIE Origin Security Envelope Header: It MUST be present if and only
TIE Lifetime field is NOT all ones. It carries through the if the Remaining TIE Lifetime field is NOT all ones. It carries
originators key ID and according fingerprint of the object to through the originators key ID and according fingerprint of the
protect TIE from modification during flooding. This ensures object to protect TIE from modification during flooding. This
origin validation and integrity (but does not provide validation ensures origin validation and integrity (but does not provide
of a chain of trust). validation of a chain of trust).
Observe that due to the schema migration rules per Appendix B the Observe that due to the schema migration rules per Appendix B the
contained model can be always decoded if the major version matches contained model can be always decoded if the major version matches
and the envelope integrity has been validated. Consequently, and the envelope integrity has been validated. Consequently,
description of the TIE is available to flood it properly including description of the TIE is available to flood it properly including
unknown TIE types. unknown TIE types.
5.4.4. Nonces 5.4.4. Weak Nonces
The protocol uses two 16 bit nonces to salt generated signatures. We The protocol uses two 16 bit nonces to salt generated signatures. We
use the term "nonce" a bit loosely since RIFT nonces are not being use the term "nonce" a bit loosely since RIFT nonces are not being
changed on every packet as common in cryptography. For efficiency changed on every packet as common in cryptography. For efficiency
purposes they are changed at a frequency high enough to dwarf replay purposes they are changed at a frequency high enough to dwarf replay
attacks attempts for all practical purposes. attacks attempts for all practical purposes. Therefore, we call them
"weak" nonces.
Any implementation including RIFT security MUST generate and wrap Any implementation including RIFT security MUST generate and wrap
around local nonces properly. All implementation MUST reflect the around local nonces properly. When a nonce increment leads to
neighbor's nonces. An implementation SHOULD increment a chosen nonce `undefined_nonce` value the value SHOULD be incremented again
on every LIE FSM transition that ends up in a different state from immediately. All implementation MUST reflect the neighbor's nonces.
the previous and MUST increment its nonce at least every 5 minutes An implementation SHOULD increment a chosen nonce on every LIE FSM
(such considerations allow for efficient implementations without transition that ends up in a different state from the previous and
opening a significant security risk). When flooding TIEs, the MUST increment its nonce at least every 5 minutes (such
implementation MUST use recent (i.e. within allowed difference) considerations allow for efficient implementations without opening a
nonces reflected in the LIE exchange. The schema specifies maximum significant security risk). When flooding TIEs, the implementation
allowable nonce value difference on a packet compared to reflected MUST use recent (i.e. within allowed difference) nonces reflected in
nonces in the LIEs. Any packet received with nonces deviating more the LIE exchange. The schema specifies maximum allowable nonce value
than the allowed delta MUST be discarded without further computation difference on a packet compared to reflected nonces in the LIEs. Any
of signatures to prevent computation load attacks. packet received with nonces deviating more than the allowed delta
MUST be discarded without further computation of signatures to
prevent computation load attacks.
In case where a secure implementation does not receive signatures or In case where a secure implementation does not receive signatures or
receives undefined nonces from neighbor indicating that it does not receives undefined nonces from neighbor indicating that it does not
support or verify signatures, it is a matter of local policy how such support or verify signatures, it is a matter of local policy how such
packets are treated. Any secure implementation MUST discard packets packets are treated. Any secure implementation MUST discard packets
where its local nonce is not correctly mirrored but it may choose to where its local nonce is not correctly mirrored but it may choose to
either refuse forming an adjacency with an implementation not either refuse forming an adjacency with an implementation not
advertising signatures or valid nonces or simply keep on signing advertising signatures or valid nonces or simply keep on signing
local packets while accepting neighbor's packets without further local packets while accepting neighbor's packets without further
verification beside checking for proper nonce reflection. verification beside checking for proper nonce reflection.
As a necessary exception, an implementation MUST advertise
`undefined_nonce` for remote nonce value when the FSM is not in 2-way
or 3-way state and accept an `undefined_nonce` for its local nonce
value on packets in any other state than 3-way.
As optional optimization, an implemenation MAY send one LIE with
previously negotiated neighbor's nonce to try to speed up a
neighbor's transition from 3-way to 1-way and MUST revert to sending
`undefined_nonce` after that.
5.4.5. Lifetime 5.4.5. Lifetime
Protecting lifetime on flooding can lead to excessive number of Protecting lifetime on flooding may lead to excessive number of
security fingerprint computation and hence an application generating security fingerprint computation and hence an application generating
such fingerprints on TIEs SHOULD round the value down to the next such fingerprints on TIEs MAY round the value down to the next
`rounddown_lifetime_interval` defined in the schema when sending `rounddown_lifetime_interval` defined in the schema when sending TIEs
TIEs. albeit such optimization in presence of security hashes over
advancing weak nonces may not be feasible.
5.4.6. Key Management 5.4.6. Key Management
As outlined in the Security Model a private shared key or a public/ As outlined in the Security Model a private shared key or a public/
private key pair is used to Authenticate the adjacency. The actual private key pair is used to Authenticate the adjacency. The actual
method of key distribution and key synchronization is assumed to be method of key distribution and key synchronization is assumed to be
out of band from RIFT's perspective. Both nodes in the adjacency out of band from RIFT's perspective. Both nodes in the adjacency
must share the same keys and configuration of key type and algorithm must share the same keys and configuration of key type and algorithm
for a key ID. Mismatched keys will obviously not inter-operate due for a key ID. Mismatched keys will obviously not inter-operate due
to unverifiable security envelope. to unverifiable security envelope.
skipping to change at page 95, line 23 skipping to change at page 96, line 23
attack is DoS due to excessive LIE validation. attack is DoS due to excessive LIE validation.
A node can try to replay previous LIEs with changed state that it A node can try to replay previous LIEs with changed state that it
recorded but the attack is hard to replicate since the nonce recorded but the attack is hard to replicate since the nonce
combination must match the ongoing exchange and is then limited to a combination must match the ongoing exchange and is then limited to a
single flap only since both nodes will advance their nonces in case single flap only since both nodes will advance their nonces in case
the adjacency state changed. Even in the most unlikely case the the adjacency state changed. Even in the most unlikely case the
attack length is limited due to both sides periodically increasing attack length is limited due to both sides periodically increasing
their nonces. their nonces.
8.6. Inner Fingerprint DoS Attacks 8.6. TIE Origin Fingerprint DoS Attacks
A compromised node can attempt to generate "fake TIEs" using other A compromised node can attempt to generate "fake TIEs" using other
nodes' outer key identifiers. Albeit the ultimate validation of the nodes' TIE origin key identifiers. Albeit the ultimate validation of
inner 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 outer 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.
9. IANA Considerations 9. IANA Considerations
This specification will request at an opportune time multiple This specification will request at an opportune time multiple
registry points to exchange protocol packets in a standardized way, registry points to exchange protocol packets in a standardized way,
amongst them multicast address assignments and standard port numbers. amongst them multicast address assignments and standard port numbers.
The schema itself defines many values and codepoints which can be The schema itself defines many values and codepoints which can be
considered registries themselves. considered registries themselves.
10. Acknowledgments 10. Acknowledgments
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
more people provided input, fine-combed the specification based on
their experience in design or implementation. This section will make
an inadequate 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
epistomology that allowed to tie current asynchronous distributed epistomology that allowed to tie current asynchronous distributed
systems theory results to a modern protocol design presented here. systems theory results to a modern protocol design presented here.
Adrian Farrel, Joel Halpern, Jeffrey Zhang, Krzysztof Szarkowicz, Adrian Farrel, Joel Halpern, Jeffrey Zhang, Krzysztof Szarkowicz,
Nagendra Kumar provided thoughtful comments that improved the Nagendra Kumar provided thoughtful comments that improved the
readability of the document and found good amount of corners where readability of the document and found good amount of corners where
the light failed to shine. Kris Price was first to mention single the light failed to shine. Kris Price was first to mention single
router, single arm default considerations. Jeff Tantsura helped out router, single arm default considerations. Jeff Tantsura helped out
with some initial thoughts on BFD interactions while Jeff Haas with some initial thoughts on BFD interactions while Jeff Haas
corrected several misconceptions about BFD's finer points. Artur corrected several misconceptions about BFD's finer points. Artur
Makutunowicz pointed out many possible improvements and acted as Makutunowicz pointed out many possible improvements and acted as
sounding board in regard to modern protocol implementation techniques sounding board in regard to modern protocol implementation techniques
RIFT is exploring. Barak Gafni formalized first time clearly the RIFT is exploring. Barak Gafni formalized first time clearly the
problem of partitioned spine and fallen leafs on a (clean) napkin in problem of partitioned spine and fallen leafs on a (clean) napkin in
Singapore that led to the very important part of the specification Singapore that led to the very important part of the specification
centered around multiple Top-of-Fabric planes and negative centered around multiple Top-of-Fabric planes and negative
disaggregation. Igor Gashinsky and others shared many thoughts on disaggregation. Igor Gashinsky and others shared many thoughts on
problems encountered in design and operation of large-scale data problems encountered in design and operation of large-scale data
center fabrics. center fabrics. Xu Benchong found a delicate error in the flooding
procedures while implementing.
11. References 11. References
11.1. Normative References 11.1. Normative References
[ISO10589] [ISO10589]
ISO "International Organization for Standardization", ISO "International Organization for Standardization",
"Intermediate system to Intermediate system intra-domain "Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in routeing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
skipping to change at page 103, line 33 skipping to change at page 104, line 43
/** @note MUST be interpreted in implementation as unsigned */ /** @note MUST be interpreted in implementation as unsigned */
typedef i16 MinorVersionType typedef i16 MinorVersionType
/** @note MUST be interpreted in implementation as unsigned */ /** @note MUST be interpreted in implementation as unsigned */
typedef i32 MetricType typedef i32 MetricType
/** @note MUST be interpreted in implementation as unsigned and unstructured */ /** @note MUST be interpreted in implementation as unsigned and unstructured */
typedef i64 RouteTagType typedef i64 RouteTagType
/** @note MUST be interpreted in implementation as unstructured label value */ /** @note MUST be interpreted in implementation as unstructured label value */
typedef i32 LabelType typedef i32 LabelType
/** @note MUST be interpreted in implementation as unsigned */ /** @note MUST be interpreted in implementation as unsigned */
typedef i32 BandwithInMegaBitsType typedef i32 BandwithInMegaBitsType
/** @note Key Value key ID type */
typedef string KeyIDType typedef string KeyIDType
/** node local, unique identification for a link (interface/tunnel /** node local, unique identification for a link (interface/tunnel
* etc. Basically anything RIFT runs on). This is kept * etc. Basically anything RIFT runs on). This is kept
* at 32 bits so it aligns with BFD [RFC5880] discriminator size. * at 32 bits so it aligns with BFD [RFC5880] discriminator size.
*/ */
typedef i32 LinkIDType typedef i32 LinkIDType
typedef string KeyNameType typedef string KeyNameType
typedef i8 PrefixLenType typedef i8 PrefixLenType
/** timestamp in seconds since the epoch */ /** timestamp in seconds since the epoch */
typedef i64 TimestampInSecsType typedef i64 TimestampInSecsType
skipping to change at page 104, line 10 skipping to change at page 105, line 21
/** Transaction ID type for prefix mobility as specified by RFC6550, value /** Transaction ID type for prefix mobility as specified by RFC6550, value
MUST be interpreted in implementation as unsigned */ MUST be interpreted in implementation as unsigned */
typedef i8 PrefixTransactionIDType typedef i8 PrefixTransactionIDType
/** timestamp per IEEE 802.1AS, values MUST be interpreted in implementation as unsigned */ /** timestamp per IEEE 802.1AS, values MUST be interpreted in implementation as unsigned */
struct IEEE802_1ASTimeStampType { struct IEEE802_1ASTimeStampType {
1: required i64 AS_sec; 1: required i64 AS_sec;
2: optional i32 AS_nsec; 2: optional i32 AS_nsec;
} }
/** generic counter type */ /** generic counter type */
typedef i64 CounterType typedef i64 CounterType
/** Platform Interface Index type, i.e. index of interface on hardware */ /** Platform Interface Index type, i.e. index of interface on hardware, can be used e.g. with
RFC5837 */
typedef i32 PlatformInterfaceIndex typedef i32 PlatformInterfaceIndex
/** Flags indicating nodes behavior in case of ZTP and support /** Flags indicating nodes behavior in case of ZTP and support
for special optimization procedures. It will force level to `leaf_level` or for special optimization procedures. It will force level to `leaf_level` or
`top-of-fabric` level accordingly and enable according procedures `top-of-fabric` level accordingly and enable according procedures
*/ */
enum HierarchyIndications { enum HierarchyIndications {
leaf_only = 0, leaf_only = 0,
leaf_only_and_leaf_2_leaf_procedures = 1, leaf_only_and_leaf_2_leaf_procedures = 1,
top_of_fabric = 2, top_of_fabric = 2,
skipping to change at page 105, line 33 skipping to change at page 106, line 45
/** default UDP port to receive TIEs on, that can be peer specific */ /** default UDP port to receive TIEs on, that can be peer specific */
const UDPPortType default_tie_udp_flood_port = 912 const UDPPortType default_tie_udp_flood_port = 912
/** default MTU link size to use */ /** default MTU link size to use */
const MTUSizeType default_mtu_size = 1400 const MTUSizeType default_mtu_size = 1400
/** default link being BFD capable */ /** default link being BFD capable */
const bool bfd_default = true const bool bfd_default = true
/** undefined nonce, equivalent to missing nonce */ /** undefined nonce, equivalent to missing nonce */
const NonceType undefined_nonce = 0; const NonceType undefined_nonce = 0;
/** outer security key id */
typedef i8 OuterSecurityKeyID
/** outer security key id */
typedef i32 InnerSecurityKeyID
/** security key id */
typedef i32 TIESecurityKeyID
/** undefined key */
const TIESecurityKeyID undefined_securitykey_id = 0;
/** Maximum delta (negative or positive) that a mirrored nonce can /** Maximum delta (negative or positive) that a mirrored nonce can
deviate from local value to be considered valid. If nonces are deviate from local value to be considered valid. If nonces are
changed every minute on both sides this opens statistically changed every minute on both sides this opens statistically
a 5 minutes window of identical LIEs **/ a `maximum_valid_nonce_delta` minutes window of identical LIEs,
TIE, TI(x)E replays.
The interval cannot be too small since LIE FSM may change
states fairly quickly during ZTP without sending LIEs*/
const i16 maximum_valid_nonce_delta = 5; const i16 maximum_valid_nonce_delta = 5;
/** indicates whether the direction is northbound/east-west /** indicates whether the direction is northbound/east-west
* or southbound */ * or southbound */
enum TieDirectionType { enum TieDirectionType {
Illegal = 0, Illegal = 0,
South = 1, South = 1,
North = 2, North = 2,
DirectionMaxValue = 3, DirectionMaxValue = 3,
} }
skipping to change at page 107, line 21 skipping to change at page 108, line 43
PrefixTIEType = 3, PrefixTIEType = 3,
PositiveDisaggregationPrefixTIEType = 4, PositiveDisaggregationPrefixTIEType = 4,
NegativeDisaggregationPrefixTIEType = 5, NegativeDisaggregationPrefixTIEType = 5,
PGPrefixTIEType = 6, PGPrefixTIEType = 6,
KeyValueTIEType = 7, KeyValueTIEType = 7,
ExternalPrefixTIEType = 8, ExternalPrefixTIEType = 8,
TIETypeMaxValue = 9, TIETypeMaxValue = 9,
} }
/** @note: route types which MUST be ordered on their preference /** @note: route types which MUST be ordered on their preference
* PGP prefixes are most preferred attracting PGP prefixes are most preferred attracting
* traffic north (towards spine) and then south traffic north (towards spine) and then south
* normal prefixes are attracting traffic south (towards leafs), normal prefixes are attracting traffic south (towards leafs),
* i.e. prefix in NORTH PREFIX TIE is preferred over SOUTH PREFIX TIE i.e. prefix in NORTH PREFIX TIE is preferred over SOUTH PREFIX TIE.
*
* @note: The only purpose of those values is to introduce an @note: The only purpose of those values is to introduce an
* ordering whereas an implementation can choose internally ordering whereas an implementation can choose internally
* any other values as long the ordering is preserved any other values as long the ordering is preserved
*/ */
enum RouteType { enum RouteType {
Illegal = 0, Illegal = 0,
RouteTypeMinValue = 1, RouteTypeMinValue = 1,
/** First legal value. */ /** First legal value. */
/** Discard routes are most prefered */ /** Discard routes are most prefered */
Discard = 2, Discard = 2,
/** Local prefixes are directly attached prefixes on the /** Local prefixes are directly attached prefixes on the
* system such as e.g. interface routes. * system such as e.g. interface routes.
*/ */
skipping to change at page 108, line 18 skipping to change at page 109, line 42
} }
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"
/** Changes /**
25.0: shorter level and major version types, clarified unsigned on nonces Thrift file for packet encodings for RIFT
25.1: clarifications on `common.TIEType` extensions for new TIEs
26.0: smaller packet sequence number and version number types, adding Copyright (c) Juniper Networks, Inc., 2016-
elements to prefix and link to allow local identification, miscabling indication All rights reserved.
*/ */
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 = 26 const common.VersionType protocol_major_version = 2
/** 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 = 0
/** common RIFT packet header */ /** common RIFT packet header */
struct PacketHeader { struct PacketHeader {
1: required common.VersionType major_version = protocol_major_version; 1: required common.VersionType major_version = protocol_major_version;
2: required common.VersionType minor_version = protocol_minor_version; 2: required common.VersionType minor_version = protocol_minor_version;
/** this is the node sending the packet, in case of LIE/TIRE/TIDE /** this is the node sending the packet, in case of LIE/TIRE/TIDE
also the originator of it */ also the originator of it */
3: required common.SystemIDType sender; 3: required common.SystemIDType sender;
/** level of the node sending the packet, required on everything except /** level of the node sending the packet, required on everything except
* LIEs. Lack of presence on LIEs indicates UNDEFINED_LEVEL and is used * LIEs. Lack of presence on LIEs indicates UNDEFINED_LEVEL and is used
* in ZTP procedures. * in ZTP procedures.
*/ */
4: optional common.LevelType level; 4: optional common.LevelType level;
10: optional common.PacketNumberType packet_number;
} }
/** Community serves as community for PGP purposes */ /** Community serves as community for PGP purposes */
struct Community { struct Community {
1: required i32 top; 1: required i32 top;
2: required i32 bottom; 2: required i32 bottom;
} }
/** Neighbor structure */ /** Neighbor structure */
struct Neighbor { struct Neighbor {
skipping to change at page 110, line 4 skipping to change at page 111, line 30
/** optional node or adjacency name */ /** optional node or adjacency name */
1: optional string name; 1: optional string name;
/** local link ID */ /** local link ID */
2: required common.LinkIDType local_id; 2: required common.LinkIDType local_id;
/** UDP port to which we can receive flooded TIEs */ /** UDP port to which we can receive flooded TIEs */
3: required common.UDPPortType flood_port = 3: required common.UDPPortType flood_port =
common.default_tie_udp_flood_port; common.default_tie_udp_flood_port;
/** layer 3 MTU, used to discover to mismatch. */ /** layer 3 MTU, used to discover to mismatch. */
4: optional common.MTUSizeType link_mtu_size = 4: optional common.MTUSizeType link_mtu_size =
common.default_mtu_size; common.default_mtu_size;
/** local link bandwidth on the interface */ /** local link bandwidth on the interface */
5: optional common.BandwithInMegaBitsType link_bandwidth = 5: optional common.BandwithInMegaBitsType link_bandwidth =
common.default_bandwidth; common.default_bandwidth;
/** this will reflect the neighbor once received to provide /** this will reflect the neighbor once received to provide
3-way connectivity */ 3-way connectivity */
6: optional Neighbor neighbor; 6: optional Neighbor neighbor;
7: optional common.PodType pod = 7: optional common.PodType pod =
common.default_pod; common.default_pod;
/** optional local nonce used for security computations */
8: optional common.NonceType nonce = common.undefined_nonce;
/** optional neighbor's reflected nonce for security purposes. */
9: optional common.NonceType last_neighbor_nonce = common.undefined_nonce;
/** optional node capabilities shown in the LIE. The capabilies /** optional node capabilities shown in the LIE. The capabilies
MUST match the capabilities shown in the Node TIEs, otherwise MUST match the capabilities shown in the Node TIEs, otherwise
the behavior is unspecified. A node detecting the mismatch the behavior is unspecified. A node detecting the mismatch
SHOULD generate according error */ SHOULD generate according error */
10: optional NodeCapabilities node_capabilities; 10: optional NodeCapabilities node_capabilities;
11: optional LinkCapabilities link_capabilities; 11: optional LinkCapabilities link_capabilities;
/** required holdtime of the adjacency, i.e. how much time /** required holdtime of the adjacency, i.e. how much time
MUST expire without LIE for the adjacency to drop */ MUST expire without LIE for the adjacency to drop */
12: required common.TimeIntervalInSecType holdtime = 12: required common.TimeIntervalInSecType holdtime =
common.default_lie_holdtime; common.default_lie_holdtime;
skipping to change at page 111, line 9 skipping to change at page 112, line 31
/** LinkID pair describes one of parallel links between two nodes */ /** LinkID pair describes one of parallel links between two nodes */
struct LinkIDPair { struct LinkIDPair {
/** node-wide unique value for the local link */ /** node-wide unique value for the local link */
1: required common.LinkIDType local_id; 1: required common.LinkIDType local_id;
/** received remote link ID for this link */ /** received remote link ID for this link */
2: required common.LinkIDType remote_id; 2: required common.LinkIDType remote_id;
/** optionally describes the local interface index of the link */ /** optionally describes the local interface index of the link */
10: optional common.PlatformInterfaceIndex platform_interface_index; 10: optional common.PlatformInterfaceIndex platform_interface_index;
/** optionally describes the local interface name */ /** optionally describes the local interface name */
11: optional string platform_interface_name; 11: optional string platform_interface_name;
/** optional indication whether the link is secured, i.e. protected by outer key, absence
of this element means no indication, undefined outer key means not secured */
12: optional common.OuterSecurityKeyID trusted_outer_security_key;
/** more properties of the link can go in here */ /** more properties of the link can go in here */
} }
/** ID of a TIE /** ID of a TIE
@note: TIEID space is a total order achieved by comparing the elements @note: TIEID space is a total order achieved by comparing the elements
in sequence defined and comparing each value as an in sequence defined and comparing each value as an
unsigned integer of according length. unsigned integer of according length.
*/ */
struct TIEID { struct TIEID {
skipping to change at page 111, line 28 skipping to change at page 113, line 4
unsigned integer of according length. unsigned integer of according length.
*/ */
struct TIEID { struct TIEID {
/** indicates direction of the TIE */ /** indicates direction of the TIE */
1: required common.TieDirectionType direction; 1: required common.TieDirectionType direction;
/** indicates originator of the TIE */ /** indicates originator of the TIE */
2: required common.SystemIDType originator; 2: required common.SystemIDType originator;
3: required common.TIETypeType tietype; 3: required common.TIETypeType tietype;
4: required common.TIENrType tie_nr; 4: required common.TIENrType tie_nr;
} }
/** Header of a TIE. /** Header of a TIE.
@note: TIEID space is a total order achieved by comparing the elements @note: TIEID space is a total order achieved by comparing the elements
in sequence defined and comparing each value as an in sequence defined and comparing each value as an
unsigned integer of according length. `origination_time` and unsigned integer of according length.
`origination_lifetime` are disregarded for comparison purposes
and carried purely for debugging/security purposes if present. After sequence number the lifetime received on the envelope
must be used for comparison before further fields.
`origination_time` and `origination_lifetime` are disregarded
for comparison purposes and carried purely for debugging/security
purposes if present.
*/ */
struct TIEHeader { struct TIEHeader {
2: required TIEID tieid; 2: required TIEID tieid;
3: required common.SeqNrType seq_nr; 3: required common.SeqNrType seq_nr;
/** remaining lifetime that expires down to 0 just like in ISIS.
TIEs with lifetimes differing by less than `lifetime_diff2ignore` MUST
be considered EQUAL.
When using security envelope,
this is just a model placeholder for convienence
that is never being modified during flooding. The real remaining lifetime
is contained on the security envelope. */
4: required common.LifeTimeInSecType remaining_lifetime;
/** optional absolute timestamp when the TIE /** optional 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. */
10: optional common.IEEE802_1ASTimeStampType origination_time; 10: optional common.IEEE802_1ASTimeStampType origination_time;
/** optional original lifetime when the TIE /** optional original lifetime 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. */
12: optional common.LifeTimeInSecType origination_lifetime; 12: optional common.LifeTimeInSecType origination_lifetime;
} }
/** Header of a TIE as described in TIRE/TIDE.
*/
struct TIEHeaderWithLifeTime {
1: required TIEHeader header;
/** remaining lifetime that expires down to 0 just like in ISIS.
TIEs with lifetimes differing by less than `lifetime_diff2ignore` MUST
be considered EQUAL. */
2: required common.LifeTimeInSecType remaining_lifetime;
}
/** A TIDE with sorted TIE headers, if headers unsorted, behavior is undefined */ /** A TIDE with sorted TIE headers, if headers unsorted, behavior is undefined */
struct TIDEPacket { struct TIDEPacket {
/** all 00s marks starts */ /** all 00s marks starts */
1: required TIEID start_range; 1: required TIEID start_range;
/** all FFs mark end */ /** all FFs mark end */
2: required TIEID end_range; 2: required TIEID end_range;
/** _sorted_ list of headers */ /** _sorted_ list of headers */
3: required list<TIEHeader> headers; 3: required list<TIEHeaderWithLifeTime> headers;
} }
/** A TIRE packet */ /** A TIRE packet */
struct TIREPacket { struct TIREPacket {
1: required set<TIEHeader> headers; 1: required set<TIEHeaderWithLifeTime> headers;
} }
/** Neighbor of a node */ /** Neighbor of a node */
struct NodeNeighborsTIEElement { struct NodeNeighborsTIEElement {
/** Level of neighbor */ /** Level of neighbor */
1: required common.LevelType level; 1: required common.LevelType level;
/** Cost to neighbor. /** Cost to neighbor.
@note: All parallel links to same node @note: All parallel links to same node
incur same cost, in case the neighbor has multiple incur same cost, in case the neighbor has multiple
skipping to change at page 113, line 4 skipping to change at page 114, line 34
bandwidths of all the parallel links. */ bandwidths of all the parallel links. */
5: optional common.BandwithInMegaBitsType bandwidth = 5: optional common.BandwithInMegaBitsType bandwidth =
common.default_bandwidth; common.default_bandwidth;
} }
/** Flags the node sets */ /** Flags the node sets */
struct NodeFlags { struct NodeFlags {
/** node is in overload, do not transit traffic through it */ /** node is in overload, do not transit traffic through it */
1: optional bool overload = common.overload_default; 1: optional bool overload = common.overload_default;
} }
/** 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
* flags values do not match or * flags values do not match or
* neighbors repeat with different values or * neighbors repeat with different values
* visible in same level/having partition upper do not match
the behavior is undefined and a warning SHOULD be generated. the behavior is undefined and a warning SHOULD be generated.
Neighbors can be distributed across multiple TIEs however if Neighbors can be distributed across multiple TIEs however if
the sets are disjoint. the sets are disjoint. Miscablings SHOULD be repeated in every
node TIE, otherwise the behavior is undefined.
@note: observe that absence of fields implies defined defaults @note: observe that absence of fields implies defined defaults
*/ */
struct NodeTIEElement { struct NodeTIEElement {
1: required common.LevelType level; 1: required common.LevelType level;
/** _All_ of the node's neighbors. /** If neighbor systemID repeats in other node TIEs of same node
* If neighbor systemID repeats in other node TIEs of same node
the behavior is undefined. */ the behavior is undefined. */
2: required map<common.SystemIDType, 2: required map<common.SystemIDType,
NodeNeighborsTIEElement> neighbors; NodeNeighborsTIEElement> neighbors;
3: optional NodeCapabilities capabilities; 3: optional NodeCapabilities capabilities;
4: optional NodeFlags flags; 4: optional NodeFlags flags;
/** optional node name for easier operations */ /** optional node name for easier operations */
5: optional string name; 5: optional string name;
/** PoD to which the node belongs */
6: optional common.PodType pod;
/** if any local links are miscabled, the indication /** if any local links are miscabled, the indication is flooded. */
is flooded. */
10: optional set<common.LinkIDType> miscabled_links; 10: optional set<common.LinkIDType> miscabled_links;
} }
struct PrefixAttributes { struct PrefixAttributes {
2: required common.MetricType metric = common.default_distance; 2: required common.MetricType metric = common.default_distance;
/** generic unordered set of route tags, can be redistributed to other protocols or use /** generic unordered set of route tags, can be redistributed to other protocols or use
within the context of real time analytics */ within the context of real time analytics */
3: optional set<common.RouteTagType> tags; 3: optional set<common.RouteTagType> tags;
/** optional monotonic clock for mobile addresses */ /** optional monotonic clock for mobile addresses */
4: optional common.PrefixSequenceType monotonic_clock; 4: optional common.PrefixSequenceType monotonic_clock;
/** optionally indicates the interface is a node loopback */
6: optional bool loopback = false;
/** indicates that the prefix is directly attached, i.e. should be routed to even if
the node is in overload. **/
7: optional bool directly_attached = true;
/** in case of locally originated prefixes, i.e. interface addresses this can /** in case of locally originated prefixes, i.e. interface addresses this can
describe which link the address belongs to. */ describe which link the address belongs to. */
10: optional common.LinkIDType from_link; 10: optional common.LinkIDType from_link;
} }
/** multiple prefixes */ /** multiple prefixes */
struct PrefixTIEElement { struct PrefixTIEElement {
/** prefixes with the associated attributes. /** prefixes with the associated attributes.
if the same prefix repeats in multiple TIEs of same node if the same prefix repeats in multiple TIEs of same node
skipping to change at page 136, line 7 skipping to change at page 138, line 7
ii. else process like the "DBTIE.HEADER < TIE.HEADER" case ii. else process like the "DBTIE.HEADER < TIE.HEADER" case
2. if DBTIE.HEADER < TIE.HEADER then 2. if DBTIE.HEADER < TIE.HEADER then
i. if originator is this node then bump_own_tie i. if originator is this node then bump_own_tie
ii. else insert TIE into LSDB and ACKTIE = TIE ii. else insert TIE into LSDB and ACKTIE = TIE
3. if DBTIE.HEADER > TIE.HEADER then 3. if DBTIE.HEADER > TIE.HEADER then
i. if DBTIE has content already then TXTIE = TIE i. if DBTIE has content already then TXTIE = DBTIE
ii. else ACKTIE = DBTIE ii. else ACKTIE = DBTIE
c. if TXTIE is set then try_to_transmit_tie(TXTIE) c. if TXTIE is set then try_to_transmit_tie(TXTIE)
d. if ACKTIE is set then ack_tie(TIE) d. if ACKTIE is set then ack_tie(TIE)
C.3.5. TIEs Processing When LSDB Received Newer Version on Other C.3.5. TIEs Processing When LSDB Received Newer Version on Other
Adjacencies Adjacencies
skipping to change at page 138, line 7 skipping to change at page 140, line 7
| signifies end | | TIEID(originator=MAX_UINT64, | | signifies end | | TIEID(originator=MAX_UINT64, |
| of TIDEs | | tietype=TIETypeMaxValue, | | of TIDEs | | tietype=TIETypeMaxValue, |
| | | tie_nr=MAX_UINT64, | | | | tie_nr=MAX_UINT64, |
| | | direction=North) | | | | direction=North) |
+----------------+--------------+-----------------------------------+ +----------------+--------------+-----------------------------------+
Table 6: all_constants Table 6: all_constants
Appendix E. TODO Appendix E. TODO
o explain what needs implemented for leaf/spine/superspine/ToF
version in detail
o section on E-W superspine/ToF flooding scope to connect partitions o section on E-W superspine/ToF flooding scope to connect partitions
o move adjacency formation rules onto FSM text and remove 2.4.2
o Fill in example for multi-plane fabric and negative disaggregation
Author's Address Author's Address
The RIFT Team The RIFT Team
 End of changes. 65 change blocks. 
154 lines changed or deleted 197 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/