Re: [RTG-DIR] [Last-Call] Rtgdir last call review of draft-ietf-rift-rift-20

[Antoni Przygienda <[e-mail]>]

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, [e-mail]<mailto:[e-mail]> 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, [e-mail]<mailto:[e-mail]><mailto:[e-mail]> 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
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
Date: Tuesday, March 19, 2024 at 5:24 AM
To: [e-mail]<mailto:[e-mail]><mailto:[e-mail]>
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
Cc:
[e-mail]<mailto:[e-mail]><mailto:[e-mail]>
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>,
[e-mail]<mailto:[e-mail]><mailto:[e-mail]>
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>,
[e-mail]<mailto:[e-mail]><mailto:[e-mail]> <[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
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!BRuyr5rrXI7fzEEwSLkBFPHxwxMpAQ2JqcFYDfAidh4TTICD4Pz1ksoGTHCoSzGMntg0TwEwstFA9w$%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: [e-mail]<mailto:[e-mail]><mailto:[e-mail]>
Senior MPLS Expert
[e-mail]<mailto:[e-mail]><mailto:[e-mail]>
Bronze Dragon Consulting             phone: [phone]

--
last-call mailing list
[e-mail]<mailto:[e-mail]><mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!CUKQcwvj6gulB67XPsxOXSWO5ELAXnv5EyFbZp853U0a6lFypiUSl93VfbPSRYltgm4gWQM$

--
last-call mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!A_YTiZvtXDJ5ua-1uMGjF-IiC-EbNOluVeOM2RQ294P7LbyZljO6uwZ9Kis6Um-WI1epYYM$