|
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
[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>
Date: Tuesday, March 19, 2024 at 5:24 AM
To: rtg-dir@xxxxxxxx <rtg-dir@xxxxxxxx>
Cc: draft-ietf-rift-rift.all@xxxxxxxx <draft-ietf-rift-rift.all@xxxxxxxx>,
last-call@xxxxxxxx <last-call@xxxxxxxx>, rift@xxxxxxxx <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$>
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
Senior MPLS Expert loa.pi.nu@xxxxxxxxx
Bronze Dragon Consulting phone: +46 739 81 21 64
--
last-call mailing list
last-call@xxxxxxxx
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!CUKQcwvj6gulB67XPsxOXSWO5ELAXnv5EyFbZp853U0a6lFypiUSl93VfbPSRYltgm4gWQM$
|
