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

Alvaro Retana <> Fri, 21 May 2021 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09F563A12AE; Fri, 21 May 2021 07:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Vo-5d_9Xfke; Fri, 21 May 2021 07:38:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9877F3A12A0; Fri, 21 May 2021 07:38:51 -0700 (PDT)
Received: by with SMTP id o5so14598991edc.5; Fri, 21 May 2021 07:38:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=LtvapuyXiBFjUSBHDVl0/mPkNx/bb292saiLwgAlU/g=; b=fO50PsYRIFncE54geij3hgFZ8+NzW5ZS4Ga5DIycWr/aTciYJI2uFDgcUf6YrhRe2Z Yd+zd7kHvsQ9YxUEkYpLZP8y9bw6lSxiPFExbdQKNZYCmdElCRvFDmjh2tCFWxR80Gma RhywoOqOO5cU+rzbe5ne2mz8HPUUMUGedACU4d3CKuNvREDsLBomq/F32CDnzD7qM+Z6 6ILZifA+uPBfE0cI1hFVTSWBgQyuRrRV16/9dwjLi9ca2qsgM62CljLAsRB+vR/yR1F5 R5nSb5xktWM62z78+iZ6iRzkffWoyGodiFPjWaz1+vMeuviQ9J6GUKNMOBPRE0jXOI4I 97jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=LtvapuyXiBFjUSBHDVl0/mPkNx/bb292saiLwgAlU/g=; b=eTuBR43QX5tnyXsvDSlLNcK8x0ddwkFWq9Pfa79FN1fxuQfW4ILqKTZIMfFiYPdFO5 EEtbE1Mn58EYUHQSWfYXOEwtByORVBmd/h1p/F8txR9L68xbDdKvRH+2G3tqI8AJqX2y OtUzKlt+VQlnP0kgVGpCIlCPZnHlmdIdg4YFIgMspvWIOhTwchUcyrW4WbpvlYByioKg J6hJFchmSu1iS6d4zI/nOAAufq4dHZ64eTkAVJ9i705suMzq2em2v1QAls6/KvICfQsv +pqPU1URmmJ0w8Cr9W40HEGfXZ/KufGYPh/4IIgAGNJ3En19sVcLzPzSDZ014Q/dC60p tN5w==
X-Gm-Message-State: AOAM533kpZAUMe0U269DcMaIc9gEWeGB4SLNQ9cmdenySMtnAfHhv1u/ 8eIoCLzihkeZ1WmQfxkXcG2rbvAtj5rgPIaGi4s=
X-Google-Smtp-Source: ABdhPJw7DVUVcHqsDvczbY6JMcJ06swaBmTHn5qeqjiyif390ATAUonSdU28fUCiVGwMs7d8RmsEq5f1vxRQtgxvSBk=
X-Received: by 2002:a05:6402:5201:: with SMTP id s1mr11637436edd.86.1621607929366; Fri, 21 May 2021 07:38:49 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 21 May 2021 07:38:48 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Fri, 21 May 2021 07:38:48 -0700
Message-ID: <>
To: Toerless Eckert <>
Cc:, "Gengxuesong (Geng Xuesong)" <>, BIER WG <>, BIER WG Chairs <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Bier] AD Review of draft-ietf-bier-te-arch-09
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 May 2021 14:38:55 -0000

On May 18, 2021 at 5:41:00 PM, Toerless Eckert wrote:



Just replying to a couple of things.

> > (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.

Simplicity is good, but being clear is better.  I would like to see a
list of the things in the BIER layer that are not replaced.  I
remember text about the differences -- think of something similar for
the things that don't change.

> > 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.

Sure, that works for me.

> > (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.

Does this mean that multiple BIFTs could exist in the same sub-domain,
some using only BIER and other only BIER-TE?  If so, then that should
be the clarification: they can coexist even in the same sub-domain as
long as the BIFTs are separate.

> 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.

Hmmm...that may be locally true: the local node "knows" how the
adjacencies look like and how they were populated, but the BIFR
doesn't.  Even if the controller programs the encapsulation at the
BIFR, the meaning of the BIFT-id field is not changing.  I think this
text raises more questions.

Also, the text above seems to have an implication on BIER: "When
BIER-TE is used...AND whether to use BIER or BIER-TE..."

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