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 > > > â?? > > 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. > > â?? > > This was roughly modelled on RFC2328 in list form ;-) > > That was nuked based on reviewer comments (donâ??t remember who) as â??way > too long, way too much descriptionâ?? > > So, what do you suggest so we donâ??t go in circles. Re-incliude that? > Rewrite that? Any idea on wording? > > â?? Tony > > > > On 24 Mar 2024, at 05:29, loa@xxxxx<mailto:loa@xxxxx> 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@xxxxxxxx<mailto:noreply@xxxxxxxx>> > Date: Tuesday, March 19, 2024 at 5:24 AM > To: rtg-dir@xxxxxxxx<mailto:rtg-dir@xxxxxxxx> > <rtg-dir@xxxxxxxx<mailto:rtg-dir@xxxxxxxx>> > Cc: > draft-ietf-rift-rift.all@xxxxxxxx<mailto:draft-ietf-rift-rift.all@xxxxxxxx> > <draft-ietf-rift-rift.all@xxxxxxxx<mailto:draft-ietf-rift-rift.all@xxxxxxxx>>, > last-call@xxxxxxxx<mailto:last-call@xxxxxxxx> > <last-call@xxxxxxxx<mailto:last-call@xxxxxxxx>>, > rift@xxxxxxxx<mailto:rift@xxxxxxxx> <rift@xxxxxxxx<mailto:rift@xxxxxxxx>> > 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> > > 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@xxxxx<mailto:loa@xxxxx> > Senior MPLS Expert > loa.pi.nu@xxxxxxxxx<mailto:loa.pi.nu@xxxxxxxxx> > Bronze Dragon Consulting phone: +46 739 81 21 64 > > -- > last-call mailing list > last-call@xxxxxxxx<mailto:last-call@xxxxxxxx> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!CUKQcwvj6gulB67XPsxOXSWO5ELAXnv5EyFbZp853U0a6lFypiUSl93VfbPSRYltgm4gWQM$ > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
