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@xxxxx<mailto:loa@xxxxx> 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@xxxxx<mailto: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><mailto:noreply@xxxxxxxx>> > Date: Tuesday, March 19, 2024 at 5:24 AM > To: rtg-dir@xxxxxxxx<mailto:rtg-dir@xxxxxxxx><mailto:rtg-dir@xxxxxxxx> > <rtg-dir@xxxxxxxx<mailto:rtg-dir@xxxxxxxx><mailto:rtg-dir@xxxxxxxx>> > Cc: > draft-ietf-rift-rift.all@xxxxxxxx<mailto: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><mailto:draft-ietf-rift-rift.all@xxxxxxxx>>, > last-call@xxxxxxxx<mailto:last-call@xxxxxxxx><mailto:last-call@xxxxxxxx> > <last-call@xxxxxxxx<mailto:last-call@xxxxxxxx><mailto:last-call@xxxxxxxx>>, > rift@xxxxxxxx<mailto:rift@xxxxxxxx><mailto:rift@xxxxxxxx> > <rift@xxxxxxxx<mailto: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><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@xxxxx<mailto:loa@xxxxx><mailto:loa@xxxxx> > Senior MPLS Expert > loa.pi.nu@xxxxxxxxx<mailto: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><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<mailto:last-call@xxxxxxxx> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!A_YTiZvtXDJ5ua-1uMGjF-IiC-EbNOluVeOM2RQ294P7LbyZljO6uwZ9Kis6Um-WI1epYYM$ > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
