Skip to main content

Last Call Review of draft-ietf-rift-applicability-14

Request Review of draft-ietf-rift-applicability
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2024-05-01
Requested 2024-04-17
Requested by Jim Guichard
Authors Yuehua Wei , Zheng Zhang , Dmitry Afanasiev , Pascal Thubert , Tony Przygienda
I-D last updated 2024-05-01
Completed reviews Rtgdir Last Call review of -14 by Sasha Vainshtein (diff)
Secdir Last Call review of -14 by Watson Ladd (diff)
Secdir Last Call review of -03 by Watson Ladd (diff)
Genart Last Call review of -03 by Linda Dunbar (diff)
Intdir Last Call review of -06 by Ralf Weber (diff)
Iotdir Last Call review of -03 by Samita Chakrabarti (diff)
Rtgdir Last Call review of -03 by Mike McBride (diff)
Tsvart Last Call review of -03 by Tommy Pauly (diff)
Assignment Reviewer Sasha Vainshtein
State Completed
Request Last Call review on draft-ietf-rift-applicability by Routing Area Directorate Assigned
Posted at
Reviewed revision 14 (document currently at 15)
Result Has issues
Completed 2024-05-01
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

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


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.

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,