Re: [Rift] AD review through (but not including) section 4 draft-ietf-rift-rift-17

[Jordan Head <[e-mail]>]

Replies inline as jhead>

From: RIFT <[e-mail]> on behalf of Antoni Przygienda <prz=[e-mail]>
Date: Saturday, May 6, 2023 at 1:35 AM
To: James Guichard <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, James Guichard <[e-mail]>
Subject: Re: [Rift] AD review through (but not including) section 4 draft-ietf-rift-rift-17

[External Email. Be cautious of content]


From: James Guichard <[e-mail]>
Date: Friday, 5 May 2023 at 20:13
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, James Guichard <[e-mail]>
Subject: AD review through (but not including) section 4 draft-ietf-rift-rift-17
[External Email. Be cautious of content]

Dear authors,

Please find a partial AD review for draft-ietf-rift-rift-17. This review covers sections up to, but not including, section 4 of the document. Note that I have used the idnits output for v-17 so that you can easily find the relevant line numbers.

168        1.  Introduction

170           Clos [CLOS] topologies (called commonly a fat tree/network in modern
171           IP fabric considerations [VAHDAT08] as homonym to the original
172           definition of the term [FATTREE]) have gained prominence in today's

Jim> I am not sure that the text in () adds much value to the text and I would simply state that "Clos [CLOS] topologies have gained etc..." and remove the text in ().

Prz> Questions arose when things were done and people ran around with jelly fish/dragonfly and other animals claiming those would take over the world 😉 IMO good old style of peer reviewed papers to give folks some minimal bootstrap and acknowledge previous work.

173           networking, primarily as result of the paradigm shift towards a

Jim> add 'a' between 'as' and 'result' above.

jhead> Will add.

174           centralized data-center based architecture that is poised to deliver

Jim> I would remove 'based' from the above

jhead> Agreed.

184           requirements, RIFT addresses those challenges not through an

Jim> expand RIFT on first usage.

jhead> Sure.

195           resolved or even cause partial network partitioning and this has to

Jim> is there such a thing as partial network partitioning? its either partitioned or it is not. I would remove 'partial'.

Prz> fair

jhead> Will fix.

197           described in Section 4.2.5 and is basically based on automatic,

Jim> remove 'basically' from the above text.

201           The protocol does further provide:

203           *  optional fully automated construction of fat tree topologies based
204              on detection of links without any configuration (Section 4.2.7)
205              while allowing for conventional configuration methods and
206              arbitrary mix of both types of nodes as well,

Jim> I do not understand the last part of the above paragraph. Do you mean a mix of ZTP and non-ZTP nodes?

Prz> yes

208           *  minimum amount of routing state held at each level,

Jim> you introduce level here but assume the reader knows what level you are discussing. Suggest to add 'of the topology' or 'of the IP fabric' to the end of the sentence to make it clearer what you are talking about.

Prz>  probably should do something like this, or maybe say “CLOS level” and make sure in glossary it says it’s equivalent and “level” is a shortcut word.  Fair point.

jhead> I’ll address this.

229           Figure 1 presents as first example of operation a simplified,
230           conceptual view of the resulting information and routes on a RIFT

Jim> insert 'database' before 'information' as the figure is showing both database information and routes.

jhead> Agreed.

231           fabric.  The top of the fabric is holding in its link-state database
232           the information about the nodes below it and the routes to them
233           whereas the notation A/32 is used to indicate a loopback route to
234           node A and 0/0 is the usual notation for a default route.  First row

Jim> I do not think the blurb about A/32 and the default is necessary. Simply end the sentence at 'and the routes to them.'. No need to explain what 0/0 means.

jhead> Generally speaking I agree with you, but unless you think it detracts from the document, I’d like to leave this in (though I’ll clean it up a bit in conjunction with the next comment). If a newbie is reading the introduction, I don’t want to assume what they know or don’t know.

235           of information represents the nodes for which full topology

Jim> it took me a while to figure out what information you were referring too in this text. Perhaps start the sentence with 'Referring to Figure 1, the first row represents database information and shows the nodes for which etc.'. You can then remove the text 'of the database table' from the next sentence.

jhead> Good catch, will clarify.

279        2.  A Reader's Digest

281           This section should serve as an initial guided tour through the
282           document in order to convey the necessary information for any reader,
283           depending on their level of interest.  The glossary section

Jim> it is actually the 'Terminology' section so should say this rather than glossary.

Prz> yes

jhead> Will fix.

287           The indications of direction (i.e. "top", "bottom", etc.) referenced
288           in the Section 1 are of paramount importance.  RIFT (Routing in Fat

Jim> remove 'in the' from the above sentence. Also no need to expand RIFT here as already did so in introduction (see previous comment).

jhead> I can take “the” out, but if we take “in the” out it would read: “The indications of direction … referenced Section 1 are…”

352           reader as it outlines how the RIB and FIB are built via the

Jim> Expand RIB and FIB on first use.

jhead> Sure.

376        3.1.  Terminology

Jim> General comment for this section. The entries should be in alphabetical order.

jhead> Can do.

564           Valid LIE:
565              LIEs undergo different checks to determine their validity.  The
566              term "valid LIE" is used to describe a LIE that can be used to
567              form or maintain an adjacency.  The amount of checks itself
568              depends on the FSM involved and its state.  A "minimally valid
569              LIE" is a LIE that passes checks necessary on any FSM in in any

Jim> remove the additional 'in' from the above text. Expand FSM on first use.

Prz> fair

jhead> Will address.


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only