Re: [Bier] A new comment about Sat, 17 September 2022 03:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F695C15256B for <>; Fri, 16 Sep 2022 20:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.906
X-Spam-Status: No, score=-0.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.998, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LCkpFvndhRMW for <>; Fri, 16 Sep 2022 20:02:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6212AC14CE32 for <>; Fri, 16 Sep 2022 20:02:14 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4MTwhh17NWz8QrkZ; Sat, 17 Sep 2022 11:02:12 +0800 (CST)
Received: from ([]) by with SMTP id 28H328B9010042; Sat, 17 Sep 2022 11:02:08 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Sat, 17 Sep 2022 11:02:08 +0800 (CST)
Date: Sat, 17 Sep 2022 11:02:08 +0800
X-Zmail-TransId: 2afb632538b0503a4603
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-MAIL: 28H328B9010042
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04- with ID 632538B4.000 by FangMail milter!
X-FangMail-Envelope: 1663383732/4MTwhh17NWz8QrkZ/632538B4.000/[]/<>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 632538B4.000/4MTwhh17NWz8QrkZ
Archived-At: <>
Subject: Re: [Bier] A new comment about
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Sep 2022 03:02:19 -0000

Hi Jeffrey, 
Sorry for the late response, I just find this mail and I think this discussion makes sense. 
I'd like to summary the new proposal, could you please tell me if I understand right?
1. When BGP is used to advertise the info, it does not use TEA, but adds a sub-tlv to the BGP Attribute (an attribute newly added in the IDR draft), indicating BIER-NH;
2. Whether it is a BFER or an intermediate BFR, set BIER Attr (including BIER-NH) of itself when sending; (one question, is this BIER-NH sub-tlv a mandatory option? That is, it must be carried when BGP announces BIER Attribute?)
3. BFR does not advertise its own BFR-Prefix (or advertise optional), but directly forwards the BFR-Prefix that advertises BFER (by the way, BIER-NH is set in point 2); this method will advertise the BGP Prefix in multiple domains, but BGP itself has the characteristics of this cross-domain route propagation;
4. Point 3, BFR can also consider using aggregated routes when forwarding BFR-Prefixes of other domains. In this case, the label-range sub-tlv defined in the Prefix Distribute can be advertised;
5. If BFR does not want to forward prefixes of other domains, it can also advertise its own BFR-Prefix and carry the label-range sub-tlv defined in Prefix Distribute, and also set BIER-NH to Own.

From: Jeffrey(Zhaohui)Zhang <>
To: '' <>;
Date: 2022年08月02日 05:08
Subject: [Bier] A new comment about
Currently, the BIER-BGP draft does not handle the situation of BIER-incapable routers. This is pointed out in the multicast/bier-as-a-service draft:
The BGP signaling and a necessary enhancement can be explained using
the following example.  EBFR43 advertises its BIER prefix (a loopback
address) as /32 IPv4 or /128 IPv6 prefix in BGP with a BIER Path
Attribute (BPA) [RFC8279] [I-D.ietf-bier-idr-extensions].  ASBR431
receives it and re-advertises it (with BGP Next Hop changed to
itself) but does not do anything wrt BIER because it does not support
BIER.  Same happens on ASBR341.  When ASBR311 and ASBR351 receive it
from ASBR341, they create a BIFT entry corresponding to EBFR43's BFR-
ID.  The entry causes a BIER packet with corresponding bit set in its
BitString to be tunneled to EBFR43.  This cannot be based on BGP Next
Hop in the advertisement because the BGP Next Hop is ASBR341.  When
eventually EBFR11 receives the re-advertised route, it creates a BIFT
entry that causes corresponding packets to be tunneled to ASBR311
(but not to EBFR43 directly).  Now it is clear that this cannot be
based on either the BIER prefix itself or the BGP Next Hop.  The
solution is that the originating EBFR attaches a Tunnel Encap
Attribute (TEA) [RFC9012] with the tunnel destination set to itself,
and whenever a BFR re-advertises the route it changes the tunnel
destination to itself.  When a BFR creates the BIFT entry, it uses
the Tunnel Egress Endpoint in the TEA to find out where to tunnel
The above also pointed out a solution based on TEA that is later specified in
Now I realize that, with the above procedure, transit BFRs do *not* need to advertise BIER info with their own BIER prefix anymore. Anytime a BGP BFR re-advertise a BFER prefix, it only need to change the BIER Info to its own, instead of separately advertise its own BIER info with its own prefix.
Additionally, we don't need to use the TEA to specify the "tunnel" endpoint. We can simply add a sub-TLV in the BIER Info TLV to specify the tunnel endpoint (which is BFER itself when the BFER prefix is originated, and the re-advertising BGP BFR when it is re-advertised by a BGP BFR).
Juniper Business Use Only
BIER mailing list