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

[Antoni Przygienda <[e-mail]>]

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