[Last-Call] RtgDir Last Call review: draft-ietf-rift-applicability-14

[Alexander Vainshtein <Alexander.Vainshtein@xxxxxxxx>]

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.
• 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.
• 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.
• 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.
• 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.
• 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.

 

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).
• 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.
• 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”.

 

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
https://www.ietf.org/mailman/listinfo/last-call