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

wei.yuehua@zte.com.cn Thu, 21 January 2021 10:03 UTC

Return-Path: <wei.yuehua@zte.com.cn>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E53F3A186F; Thu, 21 Jan 2021 02:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5cFnd1bRioV; Thu, 21 Jan 2021 02:03:18 -0800 (PST)
Received: from mxde.zte.com.cn (mxde.zte.com.cn [209.9.37.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8223A186E; Thu, 21 Jan 2021 02:03:17 -0800 (PST)
Received: from mse-eu.zte.com.cn (unknown [10.35.13.51]) by Forcepoint Email with ESMTPS id 800F2A6AF51B4E9C6D50; Thu, 21 Jan 2021 18:03:15 +0800 (CST)
Received: from dgapp02.zte.com.cn ([10.35.13.17]) by mse-eu.zte.com.cn with SMTP id 10LA38tW031272; Thu, 21 Jan 2021 18:03:08 +0800 (GMT-8) (envelope-from wei.yuehua@zte.com.cn)
Received: from mapi (dgapp02[null]) by mapi (Zmail) with MAPI id mid1; Thu, 21 Jan 2021 18:03:11 +0800 (CST)
Date: Thu, 21 Jan 2021 18:03:11 +0800
X-Zmail-TransId: 2afa6009515f7e831bc2
X-Mailer: Zmail v1.0
Message-ID: <202101211803112004562@zte.com.cn>
In-Reply-To: <160799060426.8598.6736717839856875163@ietfa.amsl.com>
References: 160799060426.8598.6736717839856875163@ietfa.amsl.com
Mime-Version: 1.0
From: wei.yuehua@zte.com.cn
To: noreply@ietf.org
Cc: gen-art@ietf.org, rift@ietf.org, last-call@ietf.org, draft-ietf-rift-applicability.all@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-eu.zte.com.cn 10LA38tW031272
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/SyEerFWLjdDqxE5oTf0nLJK23o0>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-rift-applicability-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 21 Jan 2021 10:03:21 -0000

Dear Linda,


I updated a new version. I hope it resolved your concerns.


https://tools.ietf.org/rfcdiff?url2=draft-ietf-rift-applicability-04.txt 


Comments and suggestions are always welcome.








Best Regards,


 


Yuehua Wei







M: +86 13851460269 E: wei.yuehua@zte.com.cn









原始邮件



发件人:LindaDunbarviaDatatracker
收件人:gen-art@ietf.org;
抄送人:rift@ietf.org;last-call@ietf.org;draft-ietf-rift-applicability.all@ietf.org;
日 期 :2020年12月15日 08:03
主 题 :Genart last call review of draft-ietf-rift-applicability-03


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