Loa,
Thanks very much for the clarification and suggestion. I think the expanded scope and context improves the document.
I have what I need to make the necessary edits.
Jordan
Juniper Business Use Only
From:
loa@xxxxx <loa@xxxxx>
Date: Sunday, March 31, 2024 at 11:27 PM
To: Antoni Przygienda <prz=40juniper.net@xxxxxxxxxxxxxx>
Cc: loa@xxxxx <loa@xxxxx>, Jordan Head <jhead@xxxxxxxxxxx>, rtg-dir@xxxxxxxx <rtg-dir@xxxxxxxx>, draft-ietf-rift-rift.all@xxxxxxxx <draft-ietf-rift-rift.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, rift@xxxxxxxx <rift@xxxxxxxx>, James Guichard
<james.n.guichard@xxxxxxxxxxxxx>
Subject: Re: [RTG-DIR] [Last-Call] Rtgdir last call review of draft-ietf-rift-rift-20
[External Email. Be cautious of content]
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âEUR(tm)d stick to CLOS variants (considering the now misnomed
> fat-tree a folded CLOS)
>
> âEUR" 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$
>
>
|
