Re: [RTG-DIR] [Last-Call] Rtgdir last call review of draft-ietf-rift-rift-20
loa@pi.nu Mon, 01 April 2024 03:27 UTC
Return-Path: <loa@pi.nu>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E469AC14F5E2; Sun, 31 Mar 2024 20:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzquQxNKu4TK; Sun, 31 Mar 2024 20:27:31 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0EEC14EB19; Sun, 31 Mar 2024 20:27:25 -0700 (PDT)
Received: from pi.nu (localhost.localdomain [127.0.0.1]) by pipi.pi.nu (Postfix) with ESMTP id E9B123A966F; Mon, 1 Apr 2024 05:27:22 +0200 (CEST)
Received: from 124.106.198.177 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Mon, 1 Apr 2024 05:27:23 +0200
Message-ID: <a8bb45f59d6cf5f15c41322178dc5f17.squirrel@pi.nu>
In-Reply-To: <3E42B51C-6188-4837-B783-AA1873BF088D@juniper.net>
References: <171084025066.20222.12149424859698001324@ietfa.amsl.com> <BL0PR05MB5362039AC93B47D17403370BB62C2@BL0PR05MB5362.namprd05.prod.outlook.com> <a1d3d245bdea4a66f7e4d28f37f9898b.squirrel@pi.nu> <A69B6A41-0944-4247-B8A1-44EF7E41027B@juniper.net> <83a9cc7373b18aabe9a759814c597b50.squirrel@pi.nu> <3E42B51C-6188-4837-B783-AA1873BF088D@juniper.net>
Date: Mon, 01 Apr 2024 05:27:23 +0200
From: loa@pi.nu
To: Antoni Przygienda <prz=40juniper.net@dmarc.ietf.org>
Cc: "loa@pi.nu" <loa@pi.nu>, Jordan Head <jhead@juniper.net>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-rift-rift.all@ietf.org" <draft-ietf-rift-rift.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "rift@ietf.org" <rift@ietf.org>, James Guichard <james.n.guichard@futurewei.com>
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/q4jkwfqANTYRNLA-uLp558rVJ7Q>
Subject: Re: [RTG-DIR] [Last-Call] Rtgdir last call review of draft-ietf-rift-rift-20
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2024 03:27:35 -0000
Tony, I said that I am not a subject area expert, and what I gave you is more about the LEVEL of info, rather than the actual content. I trust that you can figure out what to do. /Loa > Ok, sounds reasonable. I would drop references to specific solutions like > data-centres or any such thing. CLOS is timeless (for reason of economics > of connecting crossbars), DC as solution may be as obsolete as steam > engines in 20 years when someone reads the spec. Also protocol is really > CLOS variant since it allows e.g. horizontal links and multi-plane > variants so Iâd stick to CLOS variants (considering the now misnomed > fat-tree a folded CLOS) > > â Tony > > On 31 Mar 2024, at 12:51, loa@pi.nu<mailto:loa@pi.nu> wrote: > > [External Email. Be cautious of content] > > > Tony and Jordaan, > > No, I don't want the list back, something kike this (please remember I'm > nit a subject area expert, if what I say is exactly true please correct > after your own head. > > This document defines a specialized, dynamic routing protocol for > for a type of networks that is either called Clos or Fat Tree networks. > Such topologies were earlier primarily used for router or switch back > planes, but with the growing importance of data-centers Clos or Fat > Tree > architectures has found new target networks. Due to the importance of > such architectures there is an increasing interest for such > non-blocking > topologies. The specified protocol is optimized towards minimization > of control plane state as well as minimization of configuration and > operational complexity. > > /Loa > > > Loa, thanks for comments, all good, last we are on abstract > > Now, as to abstract, up to 13 version we had a far bigger abstract > > > âEURoe > > This document defines a specialized, dynamic routing protocol for > Clos and fat-tree network topologies optimized towards minimization > of configuration and operational complexity. The protocol > > o deals with no configuration, fully automated construction of fat- > tree topologies based on detection of links, > > o minimizes the amount of routing state held at each level, > > o automatically prunes and load balances topology flooding exchanges > over a sufficient subset of links, > > o supports automatic disaggregation of prefixes on link and node > failures to prevent black-holing and suboptimal routing, > > o allows loop-free non-ECMP forwarding, > > o automatically re-balances traffic towards the spines based on > bandwidth available and finally > > o provides mechanisms to synchronize a limited key-value data-store > that can be used after protocol convergence to e.g. bootstrap > higher levels of functionality on nodes. > > âEURoe > > This was roughly modelled on RFC2328 in list form ;-) > > That was nuked based on reviewer comments (donâEUR(tm)t remember who) as > âEURoeway > too long, way too much descriptionâEUR > > So, what do you suggest so we donâEUR(tm)t go in circles. Re-incliude > that? > Rewrite that? Any idea on wording? > > âEUR" Tony > > > > On 24 Mar 2024, at 05:29, loa@pi.nu<mailto:loa@pi.nu><mailto:loa@pi.nu> > wrote: > > [External Email. Be cautious of content] > > > Jordan, > > I'm mostly happy with your replies. > > One thing is my comment on the Abstract, I think it is valid. > I'm not asking for more details, rather is more overview. > > The abstract is intended to be stand alone, it shall be possible to cut > it out and pasted in a relevant context (e.g. a test on "What are the > RIFT RFCs all about" and still be understood stand alone. > > When I started to write my first Abstracts Scott Bradner told me, think > of your own manager and write a text so he can understand what the draft > is about. > > That is what I'm looking for, not more details. > > /Loa > > > > Hi Loa, > > Thank you very much for the review. > > My comments are inline as jhead>> > > Jordan > > > > Juniper Business Use Only > From: Loa Andersson via Datatracker > <noreply@ietf.org<mailto:noreply@ietf.org><mailto:noreply@ietf.org>> > Date: Tuesday, March 19, 2024 at 5:24 AM > To: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org><mailto:rtg-dir@ietf.org> > <rtg-dir@ietf.org<mailto:rtg-dir@ietf.org><mailto:rtg-dir@ietf.org>> > Cc: > draft-ietf-rift-rift.all@ietf.org<mailto:draft-ietf-rift-rift.all@ietf.org><mailto:draft-ietf-rift-rift.all@ietf.org> > <draft-ietf-rift-rift.all@ietf.org<mailto:draft-ietf-rift-rift.all@ietf.org><mailto:draft-ietf-rift-rift.all@ietf.org>>, > last-call@ietf.org<mailto:last-call@ietf.org><mailto:last-call@ietf.org> > <last-call@ietf.org<mailto:last-call@ietf.org><mailto:last-call@ietf.org>>, > rift@ietf.org<mailto:rift@ietf.org><mailto:rift@ietf.org> > <rift@ietf.org<mailto:rift@ietf.org><mailto:rift@ietf.org>> > Subject: Rtgdir last call review of draft-ietf-rift-rift-20 > [External Email. Be cautious of content] > > > Reviewer: Loa Andersson > Review result: Has Nits > > 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://urldefense.com/v3/__https://wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!BRuyr5rrXI7fzEEwSLkBFPHxwxMpAQ2JqcFYDfAidh4TTICD4Pz1ksoGTHCoSzGMntg0TwEwstFA9w$<https://urldefense.com/v3/__https:/wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!BRuyr5rrXI7fzEEwSLkBFPHxwxMpAQ2JqcFYDfAidh4TTICD4Pz1ksoGTHCoSzGMntg0TwEwstFA9w$><https://urldefense.com/v3/__https://wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!BRuyr5rrXI7fzEEwSLkBFPHxwxMpAQ2JqcFYDfAidh4TTICD4Pz1ksoGTHCoSzGMntg0TwEwstFA9w$%3Chttps://urldefense.com/v3/__https:/wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!BRuyr5rrXI7fzEEwSLkBFPHxwxMpAQ2JqcFYDfAidh4TTICD4Pz1ksoGTHCoSzGMntg0TwEwstFA9w$%3E><https://urldefense.com/v3/__https://wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!BRuyr5rrXI7fzEEwSLkBFPHxwxMpAQ2JqcFYDfAidh4TTICD4Pz1ksoGTHCoSzGMntg0TwEwstFA9w$%3Chttps://urldefense.com/v3/__https:/wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!BRuyr5rrXI7fzEEwSLkBFPHxwxMpAQ2JqcFYDfAidh4TTICD4Pz1ksoGTHCoSzGMntg0TwEwst FA9w$%3E%3Chttps://urldefense.com/v3/__https://wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!BRuyr5rrXI7fzEEwSLkBFPHxwxMpAQ2JqcFYDfAidh4TTICD4Pz1ksoGTHCoSzGMntg0TwEwstFA9w$%3Chttps://urldefense.com/v3/__https:/wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!BRuyr5rrXI7fzEEwSLkBFPHxwxMpAQ2JqcFYDfAidh4TTICD4Pz1ksoGTHCoSzGMntg0TwEwstFA9w$%3E%3E> > > 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-rift-20 (the current version is -20) > Reviewer: Loa Andersson > Review Date: 2024-03-19 > IETF LC End Date: > Intended Status: Standards Track > > Summary: > > This document is basically ready for publication (with nits) ; though I > found it a bit > hard to read. > > - at least for me the appendixes contain info that was useful when it > came to understand the document. This could be mentioned early in the > document. Admittedly the Readers Digest does a good work, but it is > quite a bit into the document. > > > Document Overview: > > This document defines a routing protocol for Clos and fat tree network > topologies optimized towards control plane state efficiency and a > minimum of configuration and operational complexity. > > Note: One have to get far into the document (even into appindixes) before > you understand the specification of that protocol > > Comments: > > The draft is long (189 pages), and it takes time to get through all the > details. That said the authors does a good job, it is more that the > topic is new and fairly complicated. Especially the "Readers Disgest" > section is useful and I had to return to it serval times, > > jhead>> Ah yes, I think this comes with the territory (as you said, it is > a new protocol). I'm glad to hear that the Reader's Digest section was > useful. > > Major Issues: > > None > > Minor Issues > > Abstract > > The abstract of a bit thin, I can't really get what it is asll about > from just reading the abstract, and that it what is there for, right? > jhead>> We originally listed the various optimizations made by RIFT in > the > abstract, but it was quite a long list, and well, not very abstract. In > working with other reviewers (AD, etc.) it was decided that a more > concise > approach was better for the reader. > > Nits: > > There is a long list of nits found by the nits-tool (not running > verbose), please fix those! > jhead>> The majority of these are a byproduct of using the --expand flag > when running xml2rfc before submission (this is required for our document > due to the use of SVGs). I have already started combing through and > addressing the other ones, however. > > In the abstract you say "clos and fat tree topologies", in the the > Terminology section you say "This document uses the terms Clos and > Fat Tree interchangeably". > Should the abstract asy "clos or fat tree topologies"? > Caveat: This is a grammar comment and I do not normally make grammar > comments :)! > jhead>> I agree, good catch. > > You mixed "terms" and "abbreviations", have concidered two lists? > > jhead>> They are all ultimately terms that are used in the document, some > just happen to be abbreviations until we expand them on first-use. I > don't > think having two separate lists would make the document easier to read. > > In section 5.3.1 you use "acronym", I think the preferred word is > "abbreviation". > All acronyms are abbreviations, but not all abbreviations are acronyms. > > jhead>> I presume you mean 5.2.1 (as we don't have a 5.3.1) where we say > "This section describes the terminology and acronyms...". I'll change > acronyms to abbreviations as it is more accurate. > > One question on the policy defintion in the IANA registries, can you > have a reference to an Appendix in the IANA registry? > > jhead>> I don't know the answer to your specific question, however IANA > has had several discussions with Tony so that the spec meets their needs. > > I have not found any other nits. > > > /Loa > > > -- > Loa Andersson email: > loa@pi.nu<mailto:loa@pi.nu><mailto:loa@pi.nu> > Senior MPLS Expert > loa.pi.nu@gmail.com<mailto:loa.pi.nu@gmail.com><mailto:loa.pi.nu@gmail.com> > Bronze Dragon Consulting phone: +46 739 81 21 64 > > -- > last-call mailing list > last-call@ietf.org<mailto:last-call@ietf.org><mailto:last-call@ietf.org> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!CUKQcwvj6gulB67XPsxOXSWO5ELAXnv5EyFbZp853U0a6lFypiUSl93VfbPSRYltgm4gWQM$ > > -- > last-call mailing list > last-call@ietf.org<mailto:last-call@ietf.org> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!A_YTiZvtXDJ5ua-1uMGjF-IiC-EbNOluVeOM2RQ294P7LbyZljO6uwZ9Kis6Um-WI1epYYM$ > >
- [RTG-DIR] Rtgdir last call review of draft-ietf-r… Loa Andersson via Datatracker
- Re: [RTG-DIR] Rtgdir last call review of draft-ie… Jordan Head
- Re: [RTG-DIR] [Last-Call] Rtgdir last call review… loa
- Re: [RTG-DIR] [Last-Call] Rtgdir last call review… Antoni Przygienda
- Re: [RTG-DIR] [Last-Call] Rtgdir last call review… loa
- Re: [RTG-DIR] [Last-Call] Rtgdir last call review… Antoni Przygienda
- Re: [RTG-DIR] [Last-Call] Rtgdir last call review… loa
- Re: [RTG-DIR] [Last-Call] Rtgdir last call review… Jordan Head