Ballot for draft-ietf-rift-rift
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Needs 5 more YES or NO OBJECTION positions to pass.
# Gunter Van de Velde, RTG AD, comments for draft-ietf-rift-rift-21 Thanks to the authors for the epic amount of work put into this document. Thanks to Loa Andersson, Jonathan Hardwick and Russ White for their valuable RTG DIR reviews Thanks to Zheng Zhang for the shepherd writeup Please find some some blocking DISCUSS items (easy to resolve) and a few non-blocking COMMENT points. Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots. #DISCUSS items #============= 359 First, it introduces RIFT's packet format content in the form of a 360 normative Thrift model given in Appendix B.3 carried in according [DISCUSS#1] Normative statements are normally not added in Appendixes. Normative content, procedure rules that must be followed to conform to the standard, is typically found in the main body of the document. [DISCUSS#2] What is the difference between Distance and Cost used in the document? These are both in the terminology section, however the difference is unclear (to me). Both are used within the document extensive. Readers understanding of the difference is paramount. [DISCUSS#3] Section 6.2 talks about MTU. I have seen often issues between neighbors due to (accidental) MTU mismatches. In addition the section assumes that MTU (transmit) == MRU (receive). Beyond this it is not specified if this is the L2 MTU or L3 MTU? Often the MTU on the wire depends upon the L2/L3 encap used. The specifics should be nailed down on what is intended as the MTU used for RIFT schema. [DISCUSS#4] Section 6.7 about ZTP. Often the terminology ZTP is associated with securely adding/booting nodes into a network and guarding none have been tampered with. ZTP in section 6.7 however seems to describe ZTP from the perspective of RIFT to allow a node to figure out its level, its neighbors and its RIFT centric configuration. Unless somewhere else specified a more explicit RIFT ZTP goals, non-goals and objectives will be help. In section 6.9 some of this is touched upon, however i found the role (current and potential future extensions) of section 6.7 ZTP somewhat unclear from this perspective.
#GENERIC COMMENTS #================ ##The document is well written in both descriptive and normative style. In general a wonderful achievement from the authors. i did wonder however if certain sections can not be made less complicated and with less wide scope to lower the threshold level for implementers to implement RIFT. ##The document is very long and is an intense complex read. I can not claim i understand everything in super detail as that would take a lot more time then available to digest/review this document. ##The security section 9 is a nice security overview of RIFT with loads of details ##The abstract appears to present a rationale for employing Clos or fat pipe topologies in IP fabrics. However, I would argue that the primary intent of RIFT is not to justify the use of these specific topologies but is aimed to be a routing protocol specifically designed for these architectures. The abstract should provide a glimpse into what RIFT is about. What about this conceptual rewrite proposal: "The document details the Routing in Fat Trees (RIFT) protocol, specifically designed for use in Clos and fat-tree network topologies. It aims to reduce the complexity and state requirements of the control plane in these networks. RIFT addresses both the configuration and operational aspects, enhancing efficiency through specialized mechanisms." ##May i suggest add the following introduction summary overview into the introduction section an overview of the key promised features from RIFT. Key features of RIFT include: Topology Awareness: RIFT is tailored for networks with a clear "top" and "bottom", which is typical of Clos or fat-tree structures. This orientation allows for optimized data flow management. Dual Functionality: The protocol functions as a link-state protocol when routing "north" and as a path-vector protocol when routing "south". This dual approach helps in efficiently managing the routing information. Flooding Mechanisms: RIFT employs selective flooding techniques to limit the spread of routing information to necessary nodes only, thereby reducing overhead. Zero Touch Provisioning (ZTP): RIFT supports ZTP, which allows devices to be configured automatically with minimal manual intervention, leveraging the structured nature of fat-tree topologies. Topology Exchange: Through Topology Information Elements (TIEs), RIFT handles the dissemination of topology and routing information, facilitating both northbound and southbound routing directions. Failure Management: The protocol includes mechanisms for handling link and node failures effectively, using concepts like automatic disaggregation to maintain network stability and route availability. Efficient Convergence: RIFT is designed to achieve fast convergence across large and complex topologies, essential for maintaining high availability and performance in data center environments. ##YANG data model vs KV store The document includes a KV datastore, but makes no statement or indication about YANG models/keys/lists. Seems as a missed opportunity #DETAILED COMMENTS #================= classified as [minor] and [major] 359 First, it introduces RIFT's packet format content in the form of a 360 normative Thrift model given in Appendix B.3 carried in according [minor] Thrift model: Thrift is a software framework for scalable cross-language services development. Maybe the pointer to the reference should be used at first occurrence. There is a reference, but its not added to the first terminology occurrence but at a later moment. 406 Section 7 contains a set of comprehensive examples that show how RIFT 407 contains the impact of failures to only the required set of nodes. 408 It should also help cement some of RIFT's core concepts in the 409 reader's mind. [minor] Should section 7 be better located in an informative appendix to reduce the normative part of the RIFT procedures 411 Last, but not least, RIFT has other optional capabilities. One 412 example is the key-value data-store, which enables RIFT to advertise 413 data post-convergence in order to bootstrap higher levels of 414 functionality (e.g. operational telemetry). Those are covered in 415 Section 6.8. [minor] KV store seems close aligned with how the yang model will look like. However, the word yang only appears once for a different purpose. intentional? 452 Clos/Fat Tree: 453 This document uses the terms Clos and Fat Tree interchangeably 454 where it always refers to a folded spine-and-leaf topology with 455 possibly multiple Points of Delivery (PoDs) and one or multiple 456 Top of Fabric (ToF) planes. Several modifications such as leaf- 457 2-leaf shortcuts and multiple level shortcuts are possible and 458 described further in the document. [minor] It would be useful to at least introduce once what is exactly a fat tree topology. This seems as a fine location for that purpose. "A fat tree topology is a structured network design that is commonly used in large-scale and high-performance computing environments, including data centers. This topology is a variation of the tree topology, characterized by increased bandwidth closer to the root of the tree where traffic concentration is higher." 460 Cost: 461 The sum of metrics between two nodes. ... 479 Distance: 480 The sum of costs (bound by infinite distance) between two nodes. [major] I have no idea what the difference between Cost and Distance is based upon this description. Can this be explained better? 505 Leaf-to-Leaf Shortcuts (L2L): 506 East-West links at leaf level will need to be differentiated from 507 East-West links at other levels. [minor] risk for Terminology confusion. A "shortcut" typically, especially used with MPLS, refers to a technique used to optimize the path that data takes through a network, potentially bypassing certain nodes or segments to improve performance, reduce latency, or manage bandwidth more effectively. The shortcut here seems something else? is shortcut the best term to use for this? 847 the overhead of building an update per adjacency. For the moment 848 describing the East-West direction is left out. [minor] "left out" of the RIFT specification or out of the current section? 860 reachability information from multiple directions. Its computation 861 principles (south forwarding direction is always preferred) leads to 862 valley-free [VFR] forwarding behavior. And since valley free routing 863 is loop-free, it can use all feasible paths. This is another highly [minor] i was not familiar with the term Valley-Free routing. I did some research and found that in valley-free routing, a route is considered valid if it only traverses paths that go up the hierarchy (from a lower-tier level to a higher-tier level) or horizontally (between levels of the same tier), and then potentially down the hierarchy (from a higher-tier level to a lower-tier level). What it avoids is the "valley" - a path that goes up and then down through level tiers without proper hierarchical or commercial rationale, such as going from a lower-tier level up to a higher-tier and then back down to another lower-tier level. Maybe few summary words could be provided beyond the reference provided. 1307 5.3. Fallen Leaf Problem [minor] The text illustrates the complexity of managing a fabric network under the RIFT protocol, emphasizing the need for dynamic response strategies to maintain connectivity and ensure robust network performance in various failure scenarios. Can an easy to digest summary of the dynamic response by RIFT to the fallen leaf problem be added to the section to guide the reader into section 5.4 and 5.5? 1590 RIFT supports any combination of IPv4 and IPv6 addressing on the 1591 fabric with the additional capability for forwarding paths that are 1592 capable of forwarding IPv4 packets in presence of IPv6 addressing 1593 only. [major#1] does RIFT care about address scopes used? i.e. Link-locals or unnumbered interfaces using interface id's, etc [major#2] Does RIFT allow one side to be IPv4-only and the other side IPv6-only? There is a table later explaining some aspects, but that may not to fully conform to the perceived allowed addressing combinations. 1600 schema Appendix B.2 is used unless configured otherwise. LIEs MUST 1601 be sent with an IPv4 Time to Live (TTL) or an IPv6 Hop Limit (HL) of 1602 either 1 or 255 to prevent RIFT information reaching beyond a single 1603 L3 next-hop in the topology. LIEs SHOULD be sent with network [major] what hapens if LIE is sent with another TTL? silently ignored or error message returned or something else?? 1624 A simplified version MAY be implemented on platforms with limited or 1625 no multicast support (e.g. IoT devices) by sending and receiving LIE 1626 frames on IPv4 subnet broadcast addresses or IPv6 all routers 1627 multicast address. However, this technique is less optimal and 1628 presents a wider attack surface from a security perspective. [minor] i assumed that RIFT find applicability in fat tree architectures. These architecture tend not to be IoT devices. This make me wonder if this paragraph is needed? 1690 Table 1: Control Plane Behavior for Neighbor AF Combinations [minor] Why is the IPv4,IPv6 -> IPv4 not included in this table? the IPv4,IPv6 -> IPv6 is included however. 1757 1. the neighboring node is running the same major schema version as 1758 indicated in the _major_version_ element in _PacketHeader_ *and* [major] the difference between a RIFT version number and the schema version is unclear. I may missed reading it when going through the document. What about an text blob about Thrift schema version in section 2 to provide context about 'what-is-this-schema-version' used with RIFT KV datastore and how it differs from RIFTversion number. 1767 4. (the advertised MTU values in the _LiePacket_ element match on 1768 both sides while a missing MTU in the _LiePacket_ element is 1769 interpreted as _default_mtu_size_) *and* [major] i have been exposed to loads of troubleshooting and HW troubles when MTU is mentioned with protocols. Also the MRU (Maximum Receive Unit) is a property different as the MTU. Is it assumed that L2 encaps play a role in the MTU? Accordingly, MTU can be seen in Different Contexts. Which ones is implied for RIFT? Ethernet: The standard MTU for Ethernet is typically 1500 bytes. Internet (IPv4 and IPv6): For internet traffic, the MTU considerations become more complex due to the need to traverse multiple networks of potentially varying capabilities. 4135 6.7. Optional Zero Touch Provisioning (ZTP) 4137 Each RIFT node can operate in zero touch provisioning (ZTP) mode, 4138 i.e. it has no configuration (unless it is a ToF or it is explicitly 4139 configured to operate in the overall topology as leaf and/or support 4140 leaf-2-leaf procedures) and it will fully configure itself after 4141 being attached to the topology. Configured nodes and nodes operating 4142 in ZTP can be mixed and will form a valid topology if achievable. [major] in DC environment security is important. In some DCs i visited each device plugged into the network is authenticated before allowed being connected. Maybe the ZTP used for device security is a different ZTP to be used for RIFT and they can be considered as ships-in-the-night solutions?. 5350 RIFT MAGIC: 5351 16 bits. Constant value of 0xA1F7 that allows easy classification 5352 of RIFT packets independent of the UDP port used. [minor] Out of interest, why is this particular number chosen? What happens if a different value is encoded? will the RIFT MAGIC number have secret RIFT Protocol Versioning embedded? 5501 There in no mechanism to convert a security envelope for the same Key 5502 ID from one algorithm to another once the envelope is operational. [minor] "There in" looks as a typo. Not sure if there are few words misisng.
A nit... Section 11, last paragraph: Andrew Alaton should be Andrew Alston.
# Internet AD comments for draft-ietf-rift-rift-21 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S3.2 * Figure 3 is excellent, thanks for that. ### S6.2, S6.3.1, S9.2 * TTL/HL of 1 is sometimes used with mulitcast communications, but I have found that 255 can be a stronger requirement (and one used in IPv6 link-local unicast communications). Consider standardizing on just 255, and perhaps a add a reference in this section to RFC 5082. I see some some thought has been given to this in S9.2. Nevertheless, my two cents recommendation is to stick with just 255. ### S10.2 * Per RFC 5952 S4.3: "ff02::a1f7". ## Nits ### S1 * "information will be necessary to perform certain algorithms necessary" Consider de-dup'ing the "necessary". ### S3.1 * "A radix of a switch is number of switching ports" "A radix of a switch is the number of switching ports" ### S5.1 * _super_ nitty, but consider: "not flooded East-West or back South again" "not flooded East-West nor back South again"
# Orie Steele, ART AD, comments for draft-ietf-rift-rift-21 CC @OR13 This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues, or using this [online validator](https://mnot.github.io/ietf-comments/). Line numbers are generated with this: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-rift-rift-21.txt&submitcheck=True ## Comments ``` 1458 Figure 13: Using rings to bring all planes and at the ToF bind them ``` love this. ## Nits ### List Formatting ``` 1774 6. [ 1776 i) the node is at _leaf_level_ value and has no _ThreeWay_ 1777 adjacencies already to nodes at Highest Adjacency _ThreeWay_ 1778 (HAT as defined later in Section 6.7.1) with level different 1779 than the adjacent node *or* 1781 ii) the node is not at _leaf_level_ value and the neighboring 1782 node is at _leaf_level_ value *or* 1784 iii) both nodes are at _leaf_level_ values *and* both indicate 1785 support for Section 6.8.9 *or* 1786 iv) neither node is at _leaf_level_ value and the neighboring 1787 node is at most one level difference away 1789 ]. ``` The use of brackets and absence of sub bullets, is slightly confusing. ### Text based emphasis ``` 1723 The protocol does *not* support selective disabling of address 1724 families after adjacency formation, disabling IPv4 forwarding ``` I'm *not* a huge fan or text based emphasis, it does not translate well into HTML. ### Spelling ``` 715 Zero Touch Provisioning (ZTP): 716 Optional RIFT mechanism which allows the automatic derivation of 717 node levels based on minimum configuration. Such a mininum 718 configuration consists solely of ToFs being configured as such. ``` mininum -> minimum