Re: [Rift] AD Review of draft-ietf-rift-rift-12 (Part 1)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Tony and all:

Happy new year! (covid disclaimer: as far as realistically possible that is) 

Could we move the requirement section to the applicability draft instead of removing it?

We had pretty much the reverse comment in that draft that an explanation of the what and the why is missing...

Take care;

Pascal

> -----Original Message-----
> From: RIFT <[e-mail]> On Behalf Of Antoni Przygienda
> Sent: vendredi 15 janvier 2021 21:28
> To: Alvaro Retana <[e-mail]>; [e-mail]
> Cc: [e-mail] <[e-mail]>; rift-
> [e-mail]; [e-mail]
> Subject: Re: [Rift] AD Review of draft-ietf-rift-rift-12 (Part 1)
> 
> Alvaro, on my to do list with other authors to comb through, I only address
> the first high level comments you gave
> 
> On 1/15/21, 8:56 PM, "Alvaro Retana" <[e-mail]> wrote:
> 
>     [External Email. Be cautious of content]
> 
> 
>     Dear authors:
> 
>     This is Part 1 of my review of this document.  Given that it is so
>     long, in order to make progress and not completely block the rest of
>     my publication queue [1], I decided to provide comments in parts.
>     Please address each set of comments as you can and update the document
>     accordingly -- I also expect a reply to this message, especially to
>     any points/comments that you might not agree with or want to discuss
>     further.  That will make my review of any changes easier/faster.  I
>     will wait for a reply before looking at any document updates.
> 
> Prz> thanks
> 
> 
>     Part 1 includes the introductory text through the end of §4.1 (Overview).
> 
>     While I appreciate the overview of the topologies and the protocol, I
>     think that this extended introductory material is at times too
>     long/wordy and complex (for the average reader, sometimes being forced
>     to make assumptions or jump ahead), but also incomplete.  To be more
>     specific:
> 
>     - The description of the general topology (§4.1.2) gets in to significant
>       detail and complexity, including the way in which the concepts are
> depicted
>       in the figures.  (ASCII art is not the best, you might want to take
>       advantage of using SVI.)  I noticed that none of the figures/sections in
>       §4.1.2 are referenced elsewhere (but the simple Figures 2 and 3 are),
> which
>       makes me think about the value of the in-depth treatment if it will not be
>       explicitly considered later on.
> 
> prz> we tried SVI, it does not work, in more detail the SVG tooling for xml did
> not work and we could not find any document including figures or being
> published with SVG or even clear description how we're supposed to get the
> figures in. So we reverted to ASCII art after having gone in circles for a bit.
> The terminology section, representation guide is of significant value IMO,
> without that it's very hard to talk to people clearly about multi-plane fabrics
> from direct experience.
> 
> 
>        In several places I was under the impression that a DC design guide was
>        being presented.  Which brings up the question: does RIFT require the
>        topologies to be exactly as the ones described to operate correctly?
> 
> Prz> no, it does operate in other topology variants (section 6 mentions that)
> but this is not a design guide, this is documenting what is in vast amount of
> cases being built and needs addressing simply providing a clean terminology.
> Since no'one much builds anything else than multi-stage CLOS for IP fabrics it
> would be futile to complicate the specification with variants and their
> implications albeit such documents can be written of course outside the core
> spec.
> 
> 
>     - My main expectation of the overview was to get a high-level idea of the
>       operation of RIFT, but that is not done there.  Besides a quick mention in
>       §4.1.1 and some text in the introduction, the focus of the overview is on
>       fallen leaves/dissaggregation.  I understand that may be a significant
>       issue/feature, but it shouldn't be the dominating topic in the overview.
>       Maybe some of the other pieces are more "well-known" (neighbor
> discovery,
>       flooding, etc.), but even ZTP (even if optional) is not mentioned.
> 
> Prz> This is an artefact now given we had to remove the requirements
> section based on other reviewer's comment. The req section was pretty
> clearly describing what the protocol solves. I agree that we should have a
> "this protocol does that" intro now instead. I think more and more actually
> that we should have never removed the REQ section.
> 
> 
>     In general, I don't think that the deep-/complex treatment is
>     necessary.  You may still decide to keep it (see specific comments
>     inline below), but I think it will represent a significant distraction
>     for other reviewers.
> 
> Prz> Multi-plane topologies are some of the hardest discussions to get clarity
> on behavior/topologies/procedures IME and the nomenclature given here is
> paramount to have meaningful discussions and explain why negative
> disaggregation is needed and how it is achieved. I agree again that we need
> more intro on the things that fell away with the REQ section but I would not
> remove the detailed explanation and representation of multi-plane fabric.
> You are correct that it would be good to reference those figures in detailed
> procedure sections though
> 
> Detailed answer later
> 
> -- tony
> 
> 
> Juniper Business Use Only
> _______________________________________________
> RIFT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rift