[Bier] Genart last call review of draft-ietf-bier-te-arch-10

Robert Sparks via Datatracker <noreply@ietf.org> Sat, 07 August 2021 22:42 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: bier@ietf.org
Delivered-To: bier@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A763A09D3; Sat, 7 Aug 2021 15:42:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Sparks via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: bier@ietf.org, draft-ietf-bier-te-arch.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162837612276.27380.5075158730530971495@ietfa.amsl.com>
Reply-To: Robert Sparks <rjsparks@nostrum.com>
Date: Sat, 07 Aug 2021 15:42:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/bPfEoOGCM2o1b74Ja3dFL8Afi3s>
Subject: [Bier] Genart last call review of draft-ietf-bier-te-arch-10
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Aug 2021 22:42:03 -0000

Reviewer: Robert Sparks
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bier-te-arch-10
Reviewer: Robert Sparks
Review Date: 2021-08-07
IETF LC End Date: 2021-08-11
IESG Telechat date: Not scheduled for a telechat

Summary: Essentially ready for publication as a Proposed Standard RFC, but with
nits, and possibly a minor issue, to address before publication.

Possible minor issue:

The Security Considerations section of this document could discuss an
exponential amplification attack by way of misconfiguration using the DNC bit.
If you have the following configuration (best read in a fixed-width font):

BFRA: p1 -> forward_connected(DNC) BFRC
      p2 -> forward_connected(DNC) BFRD
      p3 -> local_decap

BFRB: p1 -> forward_connected(DNC) BFRC
      p2 -> forward_connected(DNC) BFRD
      p3 -> local_decap

BFRC: p1 -> forward_connected(DNC) BFRA
      p2 -> forward_connected(DNC) BFRB
      p3 -> local_decap

BFRD: p1 -> forward_connected(DNC) BFRA
      p2 -> forward_connected(DNC) BFRB
      p3 -> local_decap

A single packet with bits (p1,p2,p3) introduced to any of the 4 BFR will
produce an exponentially increasing amount of internal traffic, and traffic
sent to whatever the local_decaped packets is configured for.

         p3              p3
        BFRA p1 ---- p1 BFRC
              \     /
               \   /
                 X
               /   \
              /     \
        BFRB p2 ---- p2 BFRD
         p3              p3

This may be easy to achieve accidentally if following the suggestion for
creating a bidirectional ring described in section 5.1.6.

Larger Nits:

The first example uses terms defined later in the document (like local_decap).
It would help the reader to say that right before the example.

Section 2.3 list 2 item 2. What is a "reference option"? This first sentence of
this item should be simplified, possibly by breaking it into two or more.

The first sentence of section 2.4 does not parse. Perhaps "BIER-TE forwarding
is designed to make it easy to build or program common forwarding hardware."
but I'm lost at "with BIER". Please clarify.

In section 3.2, there is a nested list that is introduced as "functionality"
but later referred to as "steps". Please provide a clearer description, and
make it obvious that these are the steps that the subsections (such as 3.2.1)
refer to.Is the outer list the steps 3.2.1 refers to?

Section 3.2 list item 2, sublist item 3. "Install state on the BFIR to
imposition the desired BIER packet header(s) for packets of the overlay flow"
does not parse. Please clarify.

Please clarify the last sentence (starting "See also") of 3.2.1.2. I don't know
what you are really trying to say but "solution describes interaction" doesn't
make sense.

At 3.2.1.4, what does "out-of-scope FRR procedures" mean? I suggest just
dropping "out-of-scope". If that's not right, more clarification is needed.

Section 3.4 second paragraph last sentence: Did you mean "BIER specific
routing" rather than "BFER specific routing"?

Section 4.1, Check that you really meant BFR-id = SI * 2^BSL + BP in paragraph
three.

Section 5.1, second paragraph: The list of sections '(4.1, ... 4.8)' didn't
track a document change. I think you mean to point to '(5.1.1, ...'. But the
list is unnecessary - I suggest deleting it.

In section 5.1.6, I think you are using L3 to mean different things in the
first paragraph and in the example.

Section 5.1.9 after Figure 17, you point to figure 20, but I think you really
meant figure 17. (It's interesting that figure 17 and 20 are essentially the
same, perhaps the document could be simplified).

Section 5.3.5: Where did this 20%..80% range come from? The last sentence is
unclear.

Section 5.3.6.2: paragraph 3. The sentence starting "This is much worse" is
complex. Please break it into several.

Section 5.3.7 First paragraph. This long sentence fails to parse. Please
simplify it.

Section 7 paragraph 6 (beginning "For additional,"): This sentence is very hard
to parse. Please simplify it.

Smaller Nits:

Overview: Expand BIFT on first use.

The Overview claims that the reader is expected to be familiar with both
RFC8279 and RFC 8296, but only lists the first as a normative reference.
Consider making RFC 8296 normative, or adjusting the introduction text.

First bullet in overview: "reference forwarding examples" -> "forwarding
examples"

Last bullet in overview: "sections of document" -> "sections of the document"

In 2.1, "To send in addition to BFR6 via BFR4 also a copy to BFR3" is hard to
parse. Perhaps: "To send a copy to BFR3 in addition to BFR6 via BFR4".

Section 3.2.1: Why is "Notwithstanding other option," necessary. I suggest
deleting it.

Section 3.2.1: "without any active dynamic components" is odd. Perhaps replace
the sentence with "Automated configuration of the BIER control plane is not
required. An operator can manually configure the BIER control plane via CLI on
the BFRs."

Section 3.3: "constitutes of the following components" is obtuse. Perhaps you
could replace it with "consists of"?

Section 3:3: I suggest replacing "This is done to inhibit that packets can
loop" with "This inhibits loop detection."

Section 4.6: I suggest replacing "support to configure" with "support
configuring" and "support to have" with "support having".

Section 4.6 (and other places) Saying "clear DNC", that is clear Do-Not-Clear
is dissonant. It might help avoid confusion to say "unset DNC", or replace
"with clear DNC flag" with "with the DNC flag net set".

Section 5.1.7: I suggest replacing "allows to use" with "allows using"

Section 5.3.4: Why is complex quoted in 'how "complex" the Tree Engineering is'?

Section 5.3.4: "Communications between BFIR flow" -> "Communications between
the BFIR flow"

Section 5.3.6.1, paragraph 3 first sentence: You say "over time" three times in
this sentence. Please simply it.

Section 5.3.6.1, paragraph 3, last sentence: I suggest changing "consider to
use" to "consider using"