Hi Sasha,
I uploaded a new version reflecting discussion about R1~R4, R6~R9, please take a look. https://datatracker.ietf.org/doc/draft-ietf-rift-applicability/
About R5, I think rift is theoretically applicable to internal router switching fabric use case.
Best Regards,
Yuehua Wei
Hi Yuehua Wei,
Lots of thanks for a prompt and detailed response to my review.
Please see some comments inline below.
I will wait for the new revision of the draft to include the changes you’ve proposed.
Regards,
Sasha
From: wei.yuehua@xxxxxxxxxx <wei.yuehua@xxxxxxxxxx>
Sent: Tuesday, May 7, 2024 5:11 AM
To: Alexander Vainshtein <Alexander.Vainshtein@xxxxxxxx>
Cc: rtg-ads@xxxxxxxx; rtg-dir@xxxxxxxx; draft-ietf-rift-applicability.all@xxxxxxxx; last-call@xxxxxxxx; daniam.henriques@xxxxxxxxxxx; zhenghaomian@xxxxxxxxxx; rift@xxxxxxxx
Subject: [EXTERNAL] Re: RtgDir Last Call review: draft-ietf-rift-applicability-14 （cc rift wg）
Hi Sasha,
Thank you so much for the valuable comments and suggestions.
Based on the previous discussions, I sorted out the proposed resolutions listed as "Rx>..." inline.
Best Regards,
Yuehua Wei
Original
From: AlexanderVainshtein <Alexander.Vainshtein@xxxxxxxx>
To: rtg-ads@xxxxxxxx <rtg-ads@xxxxxxxx>;
Cc: rtg-dir@xxxxxxxx <rtg-dir@xxxxxxxx>;draft-ietf-rift-applicability.all@xxxxxxxx <draft-ietf-rift-applicability.all@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;Daniam Henriques <daniam.henriques@xxxxxxxxxxx>;Zhenghaomian <zhenghaomian@xxxxxxxxxx>;
Date: 2024年05月01日 21:20
Subject: RtgDir Last Call review: draft-ietf-rift-applicability-14
Hello,
I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir.
Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive and strive to resolve them through discussion or by updating the draft.
Document: draft-ietf-rift-applicability-14
Reviewer: Alexander (“Sasha”) Vainshtein email: Alexander.Vainshtein@xxxxxxxx
Review Date: 30-Apr-2024
IETF LC End Date: 01-May-2024
Intended Status: Informational
Summary: I have some minor concerns about this document that I think should be resolved before publication.
Comments:
This draft is an expanded Applicability Statement for a new routing protocol that targets networks with CLOS and CLOS-like topologies - RIFT.
In these topologies:
· Each link is associated with a dedicated direction (North, South or East-West)
· Some nodes do not have any North-bound links
· Each node is associated with a dedicated grade (a.k.a. rank or level) that indicates the number of North-bound hops to any of the “North Pole” nodes.
RIFT is designed to provide effective routing in such topologies.
The draft provides the problem statement for routing in CLOS topologies, discusses multiple use cases for which RIFT is – or potentially could be – applicable, and operational considerations with emphasis on zero-touch provisioning (ZTP), auto-negotiation of BFD and other interesting features (such as auto-detection of mis-cabling if it violates the CLOS topology).
It is worth noting unexpected (at least, for me) references to prior art including OLSR (RFC 3626) and RPL (RFC 6550).
I am not aware of the reasons for separating the Applicability Statement from the base protocol spec – from my experience, such separation is somewhat unusual.
In my review I have tried to understand to which extent the draft would serve the interests of the presumed target audience that IMHO may have limited understanding of the protocol itself. Therefore, while the RIFT spec is listed as a Normative reference in this draft, I have tried to minimize reading of the spec. This was not always possible – e.g., the Terminology section of the draft simply says that “This document uses the terminology of RIFT”. IMHO this is not really reader friendly since the Terminology section of the base spec is quite long and detailed.
I have also tried to see to which extent the draft helps to the reader to place RIFT in the common scope and context of modern routing including such issues as Segment Routing, Loop-Free Alternates and micro-loop avoidance. These attempts resulted in raising several minor issues listed below.
I have sent a few questions and comments to the authors. Some of these questions have resulted in intensive discussion between the authors, and that was very useful to me.
Among other things, I have learned that the mathematical foundations of RIFT are somewhat different from that of the popular link-state routing protocols, and that RIFT routing does not necessarily follow the shortest path. I have also learned that, as of this moment, there is no interaction between RIFT and Segment Routing.
Lots of thanks to Pascal, Tony and Yuehua Wei (listed in alphabetical order) for their patience, help and cooperation.
Major Issues: None found.
Minor Issues:
· Readability of the draft could be greatly improved by expanding the terminology section (e.g., by copying the definitions of terms that are frequently used and RIFT-specific – e.g., positive and negative disaggregation - from the Terminology section of the base spec). This seems to be acceptable to the authors in principle, but the details are not clear.
R1> Will add more terms to this section. The terms will keep consistent with base spec. [[Sasha]] Sounds good, I will be waiting for the new version to see if anything is missing.
· The term “valley-free routing” is used in Section 5 of the draft without any explanation at all, while the base spec provides a reference that is not publicly accessible. Since this term is used to explain why RIFT routing is loop-free, some explanation would be most helpful. Several alternative explanations of this term, and its relationship with loop-free routing have been already suggested by the authors.
R2> The following text will add to section 5 "Operational Considerations" :
· RIFT provides valley-free routing and with that is loop free. A valley-free path allows reversal of direction at most once from a packet heading northbound to southbound while permitting traversal of horizontal links in the northbound phase. This allows the use of any such valley-free path in bi-sectional fabric bandwidth between two destinations irrespective of their metrics which can be used to balance load on the fabric in different ways. Valley-free routing eliminates the need for any specific micro-loop avoidance procedures for RIFT. [[Sasha]] Sounds good.
· The Problem Statement section explains why traditional IGPs would not be effective in CLOS and CLOS-like topologies. However, there is no comparison with BGP that, AFAIK, has successfully been used in such topologies (RFC 7938). My guess is that such a comparison, if possible, would be important for the expected target audience.
R3> Problem Statement section doesn't describe problems specific to traditional IGPs. This section emphersizes the problems of routing in IP Fabric Fat Tree Networks in order to introduce following rift features.
[[Sasha]] I respectfully disagree. The Problem Statement section says that “All nodes including spine and leaf nodes learn the entire network topology and routing information” and “They flood significant amounts of duplicate link state information between spine and leaf nodes during topology updates and convergence events”. This is correct for the popular link-state routing protocols, but not correct for BGP IMHO.
· My understanding (confirmed by the authors) is that rich ECMP in Fat Tree topologies eliminates the need for more complicated Loop-Free Alternates procedures, while valley-free routing (if I understand the term correctly) eliminates the need for any specific micro-loop avoidance procedures for RIFT. IMHO it would be nice to see this explicitly stated in the draft because both issues are actively discussed in the IETF RTGWG these days.
R4>Yes, see R2 and the following text will be added to the end of the paragraph:
· RIFT inherently solves many difficult problems associated with the use of traditional routing topologies with dense meshes and high degrees of ECMP by including automatic bandwidth balancing, flood reduction and automatic disaggregation on failures while providing maximum aggregation of prefixes in default scenarios. ECMP in RIFT eliminates the need for more Loop-Free Alternates procedures. [[Sasha]] Sounds good.
· The Use Cases section of the draft lists, in addition to the DC and Cloud CO topologies, such use cases as metro fabric, building cabling and internal router switching fabric. It is not clear to me whether applicability of RIFT in these scenarios is built on actual experience or on purely theoretical considerations (at least, the use case of the internal router switching fabric is defined as “conceivable”). It would be nice if the authors could clearly distinguish between use cases in which applicability of RIFT has been verified in actual deployments, and “conceivable” use cases.
R5> RIFT inherits properties from RPL and explain the experience we have in RPL. As to practical, the industry had real experience, as in deployment on real/virtual up to couple hundred switches at least under real customer requirements.Scale testing somewhat higher … All in context of IP fabrics with mostly EVPN as use case but not always . All that on 3-4 different silicon substrates dancing around all kind of issues on cheap hardware (like UDP fragmentation impact etc.) [[Sasha]] Sounds good. But, to the best of my understanding, this does not cover the internal router switching fabric use case – can you please clarify this point?
· Section 5 mentions that “RIFT design follows … minimum necessary epistemological scope philosophy”. I have looked up “epistemology” in the dictionary, and found that it means “the study or a theory of the nature and grounds of knowledge especially with reference to its limits and validity”, but, unfortunately, failed to understand how such a study – or theory - may affect design of a routing protocol. (Not sure whether this should be classified as a minor issue or as a nit, and, in any case, could be my personal problem, of course).
· The same section mentions “good scaling properties while delivering maximum reactiveness” of RIFT but does not provide any numbers. My guess is that such information, if it is available and can be shared, would be quite important for the presumed target audience.
R6> I'd prefer to keep "RIFT only floods routing information to the devices that absolutely need it." in this section only. [[Sasha]] Sounds good.
Nits:
I have not run the nit checker on the draft. However, I have noticed several cases that look like nits to me:
· The names of some of the authors appear on the cover page of the draft in the usual form (the first letter of the given name separated by a dot from the family name). But in some cases, the full given name and family name separated by a dot appear there. (My guess is that this would be handled by the RFC Editor in any case).
R7>Good catch, will update the draft
· The Contributors Section says that “The following people (listed in alphabetical order) contributed significantly to the content of this document and should be considered co-authors”. However, the names of the two contributors - Tom Verhaeg and Jordan Head – listed in this section appear in the reverse order. Should be simple to fix.
R8>Good catch, will update the draft
· Section 5.6 of the draft mentions “imbedded devices”. I have used the dictionary and found that “imbedded” is just a rarely used form of much more popular “embedded”.
R9>Good catch, will update the draft
[[Sasha]] Sounds good.
Hopefully, these notes will be useful,
Regards,
Sasha
Disclaimer
This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
