Re: [Bier] [Last-Call] Genart last call review of draft-ietf-bier-te-arch-10

Lars Eggert <lars@eggert.org> Tue, 24 August 2021 09:14 UTC

Return-Path: <lars@eggert.org>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642703A17EB; Tue, 24 Aug 2021 02:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tsoHO0UriKM; Tue, 24 Aug 2021 02:14:06 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75913A1573; Tue, 24 Aug 2021 02:14:05 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:1815:5480:b768:b865]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 195CA600370; Tue, 24 Aug 2021 12:13:31 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1629796412; bh=v0WGIBONtBjcebqU5HZrJpD5+1rfyKP2jr1JB5VQANQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Kn1UoLL8/v79Z4zU3xZGwkjoW+wH83p93smkHRwd6vdVoyaLrEUReVMdbp8LJWXRo tglECOWdlXuquBsCICYY1XyXv8SA9e1wIkYehm1GiJyjPWj52oDxV2c/loncjDkaXh rwUyZC7+rJli578lXz3P2nJupQwg3zfXq2/JweUo=
From: Lars Eggert <lars@eggert.org>
Message-Id: <CE49259E-F758-4B28-B358-E2DC5CF9B160@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_20805AF1-1073-4829-8492-CF4B939FF888"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Tue, 24 Aug 2021 12:13:30 +0300
In-Reply-To: <162837612276.27380.5075158730530971495@ietfa.amsl.com>
Cc: General Area Review Team <gen-art@ietf.org>, last-call@ietf.org, bier@ietf.org, draft-ietf-bier-te-arch.all@ietf.org
To: Robert Sparks <rjsparks@nostrum.com>
References: <162837612276.27380.5075158730530971495@ietfa.amsl.com>
X-MailScanner-ID: 195CA600370.A3E7D
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/AQrJdVEzXNuVqZ7VGqQH3JYXwI8>
Subject: Re: [Bier] [Last-Call] Genart last call review of draft-ietf-bier-te-arch-10
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Tue, 24 Aug 2021 09:14:13 -0000

Robert, thank you for your review; I am expecting the authors to reply. I have entered a No Objection ballot for this document.

Lars


> On 2021-8-8, at 1:42, Robert Sparks via Datatracker <noreply@ietf.org> wrote:
> 
> 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"
> 
> 
> --
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call