[Gen-art] Genart last call review of draft-ietf-rift-applicability-03

Linda Dunbar via Datatracker <noreply@ietf.org> Tue, 15 December 2020 00:03 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3E53A129E; Mon, 14 Dec 2020 16:03:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Linda Dunbar via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Cc: rift@ietf.org, last-call@ietf.org, draft-ietf-rift-applicability.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160799060426.8598.6736717839856875163@ietfa.amsl.com>
Reply-To: Linda Dunbar <linda.dunbar@futurewei.com>
Date: Mon, 14 Dec 2020 16:03:24 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/5jbxo6Xa4uvPoRwmJJjVm9Z5D2g>
Subject: [Gen-art] Genart last call review of draft-ietf-rift-applicability-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Dec 2020 00:03:24 -0000

Reviewer: Linda Dunbar
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-rift-applicability-3
Reviewer: Linda Dunbar
Review Date: 2020-12-14
IETF LC End Date: None
IESG Telechat date: Not scheduled for a telechat

Summary:

This document claims to describe the properties and the applicability of RIFT
in different deployment scenarios and highlight the operational simplicity of
RIFT.

But I find the description is not complete.  For example, I can't find any
sections describing "the consideration when RIFT is used with or without
overlays", nor can I find how RIFT is operationally simpler than Link State
protocol.

Major issues:

Section 3.1  Overview of RIFT listed many benefits of RIFT, but doesn't have
any description how those benefits are realized by RIFT. Strongly suggest to
have a reference to each of the benefits described in the Section 3.1.

There is one statement saying that RIFT uses Link State for the north direction
and Distance Vector for the south direction, therefore, RIFT has the benefits
of both. But the document doesn't have any description on why RIFT didn't
inherent the disadvantages of both.

Minor issues:
The document uses many acronyms that don't have reference nor definitions:

Section 3.2.1
-  What do "PoD" and "multi-plane" mean?
- What do  N-SPF and S-SPF stand for?

Section 3.3.1:
What does it mean by saying "application in underlay of data center IP
fabrics"?  Do you mean "applications connected by Clos architecture in DC "?

Section 3.3.3 Last sentence: "Moreover, due the limited size of forwarding
tables ..."

How do the active elements of building cabling related to  the "limited sizes
of forwarding tables"?

Section 3.3.4:  First sentence:  "It is common ... to use fabrics when crossbar
is not feasible" Do you mean "Clos Fabrics"?

Section 4:
what does "minimum blast radius" mean?
What aspects of "extensive Zero Touch Provisioning" achieved by RIFT that can't
be achieved by Link State protocols?

"RIFT negotiates automatically BFD per link".
RIFT uses Link State for North Bound, does it inherit all the properties from
Link State (OSPF or  IS/IS)?  There is no description on how RIFT can automate
BFD better than OSPF or IS/IS.

 "RIFT reduces FIB size towards the bottom of the IP fabric". Do you mean RIFT
 reduces FIB size for leaf nodes?

Page 13: "without disaggregation mechanism, when linkSL6 fails, ..."
When Link State protocol is used , if LinkSL6 fails, packets towards prefix 122
should go through LinkSL5-> LinkSL7->LinkSL8.   How does it go through
linkSL5->LinkT3?

Page 16:
"the RIFT control protocol can discover the physical links and detect cabling
that violates fat-tree". Is it by configuration on the Leaf nodes?

Page 25:
What is "LIEs"? what is "TIEs"?

Page 26:
What is "PGP reference"?

Nits/editorial comments:

Cheers,
Linda Dunbar