Re: [Bier] AD Review of draft-ietf-bier-te-arch-09

Toerless Eckert <tte@cs.fau.de> Tue, 18 May 2021 21:41 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 64BC93A103C; Tue, 18 May 2021 14:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 5iihkGXimXIw; Tue, 18 May 2021 14:41:08 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F85D3A1031; Tue, 18 May 2021 14:41:06 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 56679548015; Tue, 18 May 2021 23:40:55 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4ACFA4E74E9; Tue, 18 May 2021 23:40:55 +0200 (CEST)
Date: Tue, 18 May 2021 23:40:55 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: draft-ietf-bier-te-arch@ietf.org, "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, BIER WG Chairs <bier-chairs@ietf.org>, BIER WG <bier@ietf.org>
Message-ID: <20210518214055.GC5939@faui48e.informatik.uni-erlangen.de>
References: <CAMMESsxEH-bNuEX6ETZLg1asBj+tPo67GC8BFA2sFx8fD_G9Yg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMMESsxEH-bNuEX6ETZLg1asBj+tPo67GC8BFA2sFx8fD_G9Yg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/ssjAkjqT69FjfYkJtum1WyyMu2g>
Subject: Re: [Bier] AD Review of draft-ietf-bier-te-arch-09
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, 18 May 2021 21:41:13 -0000

On Fri, May 14, 2021 at 01:14:43PM -0700, Alvaro Retana wrote:
> Dear authors:
> Thank you for the interesting work!

Thanks for the review! Just some quick feedback / questions, before
i get to work on the requested changes. Unless i comment, i agree in general
with your feedback, which doesn't necessarily mean that they all can be resolved
perfecly (e.g.: reshuffling sections may create a better structure, but i have
to check if it works because of sequential introduction of new concepts required
by the later chapters).

> I have a couple of high-level comments/concerns.
> 
> (1) What is this document specifying?
> 
>   To start, I believe it is ok for an architecture document to be in the
>   Standards Track.
> 
>   As far as I can see, this document mainly specifies alternate semantics for
>   the BitString.  Beyond that, the BIER-TE architecture (§2) maps well onto
>   the layering described in §4/rfc8297, where the BIER layer (§4.2/rfc8297) is
>   "replaced" with the BIER-TE Control Plane and the BIER-TE forwarding layer.
>   Is this a fair high-level representation of what is defined in this
>   document?

"replaced" is certainly how the doc is written, so as to make it read
as simple as possible. The intent of course is to "amend" BIER by sharing
as much as possible with it such that a joint BIER/BIER-TE implementation
is but slightly more work than just a BIER implementation.

>   In general, the BIER-TE forwarding is well specified.  I would prefer it if
>   the definition of the adjacencies included normative language.  The
>   requirements section (§3.6) introduces some confusion with the use of "basic
>   BIER-TE forwarding" (vs "BIER-TE forwarding").  Suggestion: the
>   specification should include required ("basic") and recommended/optional
>   behaviors.  See specific comments in-line.
> 
>   OTOH, the functions of the BIER-TE control plane are described (not
>   specified) in what I consider a set of operational considerations (things
>   the controller could consider -- including sections 4, 5, and 7).  Having an
>   extensive set of operational considerations is a good thing, specially given
>   how much BIER-TE relies on the controller.  The BIER-TE control protocol is
>   central to the operation/implementation of BIER-TE, but left out of scope
>   (see my comments in §2.2).
> 
>   The BIER-TE topology is a "key new component in BIER-TE".  The document
>   doesn't specify, explain, or leave out of scope how "BIER-TE Controller
>   discovers the network topology and creates the BIER-TE topology from it"
>   (§2.2).  This omission is a significant hole in the architecture.

How about this. As long as it is clear that no references here are normative,
but all informational (like any similar references in RFC8279 that are all
informational too).

| In statically managed networks, such as in industrial environments, topology
| discovery may be a manual/offline process. In other networks topology discovery may rely on
| protocols such extending the LSP IGP into the controller itself, RFC7752 (BGP-LS)
| or RFC8345 (Yang topology) as well as BIER-TE specific extensions for example
| via draft-ietf-bier-te-yang. These examples are non-exhaustive.

>   It would be ideal if the Introduction included a high-level overview of the
>   document.
> 
> (2) Can BIER and BIER-TE really coexist in the same network?
> 
>   The Abstract mentions that they can:
> 
>      BIER-TE can co-exist with BIER forwarding in the same domain, for
>      example by using separate BIER sub-domains.
> 
>   The result of separate sub-domains is more akin to ships-in-the-night than
>   having them be "mixed": in the same sub-domain using a single BIFT
>   (populated by different sources).   Is this correct?

The way in which the BIER-TE draft defines BIER-TE forwarding, it is exclusively
"owning" a BIFT. This is because the code, e.g.: Figure 15 shows the bit-reset
semantic for all bits to use BIER-TE ([1] vs. [2]). So, what you call "mixed"
is not part of the draft.

Of course, implementations can easily build a single implementation of forwarding
across BIER/BIER-TE, even with semantic, BIER vs. BIER-TE different for every bit,
but to me this is just implementation optimization. Reason is that i have not 
identified good operational benefits to make this part of the BIER-TE architecture.
(aka: use case with some bits using bier othre bits in same bitstring using bier-te
 bit-reset logic).

However, your ships-in-the night semantic is probably incorrect. 
Even BIER alone can already have multiple BIFT per sub-domain,
because according to rfc8279, you need a combination of (sub-domain, bsl) 
to map to a BIFT, not just a sub-domain.

Here is suggested text to help clarify:

| When BIER-TE is used with rfc8296 encapsulation, the bift-id identifies an SI,
| a sub-domain, and a BitStringLength (as specified in rfc8279) AND whether to
| use BIER or BIER-TE forwarding for this bift-id.

>   §3.3 speculates about potential "definitions in BIER encapsulation
>   specifications" to "distinguish BIER from BIER-TE packets"

Yes. we had a draft to that end (one more bit in BIER header used to indicate
BIER/BIER-TE mode), but that was not met with much love by the WG back then,
but i see no good reason to now mention this as a still open option given how
rfc8279 also did not constrain itself to only rfc8296 encap.

>    -- and offers a
>   workaround if the MPLS encapsulation is used.

Not a workaround, See above proposed text "|".

In the rfc8296 forwarding plane we can easily have the same
(sub-domain, bsl) with BIER as well as BIER-TE by just giving them
different bift-ids. And that works for both mpls and non-mpls.

The routing protocol signaling right now would only work for BIER semantic bift,
but that is fine as we do not use/need the IGP BIER extensions for BIER-TE.

>   Even here, a "mixed" environment would seem to at least require independent
>   BIFTs, and not be possible with non-MPLS encapsulations.

Hope this is clear by now (yes, each BIFT is either BIER or BIER-TE architecturally,
but no - will work for MPLS and non-MPLS).

>   My conclusion is that using the encapsulation from rfc8296 it is not
>   possible to have a "mixed" BIER/BIER-TE network -- unless using MPLS with
>   extra labels and separate BIFTs.   This is just a guess --  the coexistence
>   topic deserves better coverage so that no one has to guess.
> 
> 
> (3) Organization
> 
>   The document jumps right into examples and a short discussion of the BIER-TE
>   topology -- including a quick comparison with BIER (§1.2).  There are 3
>   other sections that are also called "comparison with BIER" (§1.3, §3.5, and
>   §7.2). It may make the document clearer if the "baseline" comparison with
>   BIER was set from the start (you can dig deeper later of course).
> 
>   §3 describes BIER-TE forwarding, but sample pseudocode is in §6.  Please
>   move that to §3.
>
>   As I mentioned above, several of the sections (4, 5, and 7) include
>   considerations for the BIER-TE Controller.  It would be great if these
>   sections were consolidated under a single heading: Operational
>   Considerations for the BIER-TE Controller (for example).

Let me see if i can do the reshuffling without having to completely rewrite explanations
(stuff was put in order of explanation dependencies).

Stay tuned.

Cheers
    Toerless

> Thanks!
> 
> Alvaro.
> 
> 
> [Line numbers from idnits.]
> 
> 13	Abstract
> 
> [] In general, I think this Abstract is longer than needed -- in fact,
> it is longer than the initial part of the Introduction.  Consider
> making it shorter.
> 
> 
> 15	   This memo introduces per-packet stateless strict and loose path
> 16	   steered replication and forwarding for Bit Index Explicit Replication
> 17	   packets (RFC8279).  This is called BIER Tree Engineering (BIER-TE).
> 18	   BIER-TE can be used as a path steering mechanism in future Traffic
> 19	   Engineering solutions for BIER (BIER-TE).
> 
> [major] "BIER-TE" has two different meanings?  I'm assuming the last
> mention is just a leftover.
> 
> 
> ...
> 25	   In BIER, the BitPositions (BP) of the packets bitstring indicate BIER
> 26	   Forwarding Egress Routers (BFER), and hop-by-hop forwarding uses a
> 27	   Routing Underlay such as an IGP.
> 
> [major] The terminology used here doesn't correspond to what is used
> in rfc8279.  Please be consistent and don't make up new terminology
> unless it is to present something new.
> 
> "BitPositions (BP)" doesn't appear in rfc8297.  Instead, "bit position" is used.
> 
> s/bitstring/BitString/g
> 
> s/BIER Forwarding Egress Routers (BFER)/Bit-Forwarding Egress Routers (BFERs)
> 
> 
> 29	   In BIER-TE, BitPositions indicate adjacencies.  The BIFT of each BFR
> 30	   are only populated with BPs that are adjacent to the BFR in the BIER-
> 31	   TE topology.  The BIER-TE topology can consist of layer 2 or remote
> 32	   (routed) adjacencies.  The BFR then replicates and forwards BIER
> 33	   packets to those adjacencies.  This results in the aforementioned
> 34	   strict and loose path steering and replications.
> 
> [minor] Expand all acronyms in the Abstract *and* on first mention later on


-- 
---
tte@cs.fau.de