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

Tony Przygienda <> Mon, 26 July 2021 22:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D8973A14D0; Mon, 26 Jul 2021 15:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 U2UCWxvedV6E; Mon, 26 Jul 2021 15:04:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FDEF3A153B; Mon, 26 Jul 2021 15:04:54 -0700 (PDT)
Received: by with SMTP id l18so13702588ioh.11; Mon, 26 Jul 2021 15:04:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0HK7trb7BC0j5x/OeGF1MG9yia+RAx1K0M5EArHD6Ss=; b=vQpPcIESI6l9ltVhxuJ9M3Lc+10P/y/SHVB0allE7wwFN86SNWEaWME2d1ZXZmaXPh Oktf8/cTIiMabUc81j9ucxvC0e5taBm8eFqymyZmZWZhdunaBJsA2r2Hzj0C9vxiPrEo rVwx9cXbssIfAaPqQq59iZrSJw+lBpf0vGb0v2b/jJhUi3qluQiB+wK6oB28omq6jceG 2JO7FM+/sk0Utw71bPqXFTbILgA6LZ5vufH3VmCvH8sMmbxUOZZwsFlrPy72RtWvvEmQ j1yZ8ynWSv7MzmpxRVsSvp2T5IpWTSCZYeoRmtD17fNk6MFOMeJfIVMWaOOjf5MRF3fE 8Vjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0HK7trb7BC0j5x/OeGF1MG9yia+RAx1K0M5EArHD6Ss=; b=ZfmFwOKOZolSgnhkIwp7iqwYh7m1pQuPkkYEC4sequ5YiaRCG6ZLlZbb+GuPoaXrbK WHlpXCaxbTKqq0bZG4+xsjMBHtTD8S4Or5Ejbu16niSP2c7vt0HbFhAB6bi/PMECsqXo t3hMe0fch97Khnvp/8CXllq8rxjtnjxpvDsWmCYWGYbW5SUlkGoNn1nV7KYvy26WjO7A Ts4f87ArLafOpdZcSFwtexpZ36fFNvIDSu2SKCdgdKScfaXnRbDPs+9tW16OaOPi5CLa tCEeipCrDp5e3tpcHEb196zG781w6ocFacpJfMSQRcNgKE0/zrDnFeftYnowEXTKwJy4 m8PQ==
X-Gm-Message-State: AOAM531ieibpz6QXnshpDlMKTLdnUz5nCZhxbV5MZujpEryHtdmkeVmg Pcuh3rYHSaK8I3FkC0P1IOckXH0OtrymaKbpo0QI/4yOV6Lv+RB4
X-Google-Smtp-Source: ABdhPJwcRr2CnzzDTJUCyPJUEHCkh8Y3Q7BJwD9CY13WN/6r/+8X8X7I608Aaj37R/er8gADySQWHWlx0hNCnNA5vBM=
X-Received: by 2002:a02:c491:: with SMTP id t17mr18363443jam.56.1627337093611; Mon, 26 Jul 2021 15:04:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tony Przygienda <>
Date: Tue, 27 Jul 2021 00:04:17 +0200
Message-ID: <>
To: Toerless Eckert <>
Cc: Alvaro Retana <>,, "Gengxuesong (Geng Xuesong)" <>, BIER WG Chairs <>, BIER WG <>
Content-Type: multipart/alternative; boundary="0000000000006505f205c80df16b"
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: Mon, 26 Jul 2021 22:05:01 -0000

given it's IETF weeks and I'm staying up to 3am every day it's a good
possibility to catch up on lots ietf threads/drafts ;-)


On Tue, May 18, 2021 at 11:41 PM Toerless Eckert <> wrote:

> On Fri, May 14, 2021 at 01:14:43PM -0700, Alvaro Retana wrote:
> ...
> >
> >      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.

yes, it's crucial to define the "separation" boundary in the architecture
document here.
"ships in the night" is too loose a term IMO, we need clear delineation, I
subdomain is a natural one (which Alvaro seems to have divined from the
document ;-).
So a BIER domain can mix TE and vanilla and
I don't see anything wrong with that, such things were one of the reasons
to do sub-domain, so we can do MT or flex-algo per sub-domain or completely
change the
semantics of the bitmask (well, as long it does packet replication in some
form ;-). I think we're in sync here.

> >   ยง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 as you know the wall you have to climb to justify a new encapsulation
in BIER or even bend bits
is famously high ;-)
So unless a use case is presented that cannot be met by the MPLS or
non-MPLS encaps the WG
has proven considerably prudent so far in this respect ;-)

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

nothing precludes BIER-TE from inventing a distributed protocol for TE IMO
do things like multicast RSVP-TE for BIER-TE AFAIS. At least
architecturally it's all fair game.

Given we're starting on adjournment to  8279 I think it would be a nice
example to
show how BIER-TE fits nicely into BIER architecture that properly decouples
L2 & L3 abstractions it relies on from the semantics of BIER (*sub)-domain
and its behavior
as abstract replication capable  L2.5 substrate.

-- tony