Re: [Bier] A new comment about Wed, 21 September 2022 02:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5456DC14CE36 for <>; Tue, 20 Sep 2022 19:14: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 nbXKdtb-XqOS for <>; Tue, 20 Sep 2022 19:14: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 75E91C14CE26 for <>; Tue, 20 Sep 2022 19:14: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 4MXMRS6s8rz4xVnK; Wed, 21 Sep 2022 10:14:12 +0800 (CST)
Received: from ([]) by with SMTP id 28L2Dxxr048889; Wed, 21 Sep 2022 10:13:59 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Wed, 21 Sep 2022 10:13:59 +0800 (CST)
Date: Wed, 21 Sep 2022 10:13:59 +0800
X-Zmail-TransId: 2afb632a736712293a49
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-MAIL: 28L2Dxxr048889
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04- with ID 632A7374.000 by FangMail milter!
X-FangMail-Envelope: 1663726452/4MXMRS6s8rz4xVnK/632A7374.000/[]/<>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 632A7374.000/4MXMRS6s8rz4xVnK
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: Wed, 21 Sep 2022 02:14:19 -0000

Hi Jeffrey, 
These clarification looks good to me.
Thank you!
Best regards,

From: Jeffrey(Zhaohui)Zhang <>
To: 张征00007940;
Cc: <>;
Date: 2022年09月21日 09:38
Subject: RE: [Bier] A new comment about
Hi Sandy,
Thanks for your follow up - they're good comments that can be incorporated together with the suggestions that I was proposing.
The BIER-NH does not have to be mandatory. If it is not present, then it can be assumed that it is the BIER prefix itself.
Juniper Business Use Only
-----Original Message-----
From: <>
Sent: Friday, September 16, 2022 11:02 PM
To: Jeffrey (Zhaohui) Zhang <>
Subject: Re: [Bier] A new comment about
[External Email. Be cautious of content]
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 BF
 R-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;!!NEt6yMaO-gk!G1pQRVj-WJSN9_KmeVqpMHxp94H2FqWg2JUguN-cIqGqgA2ilipHawl9tlNwPNR9elbX_KUoF7StBwkX6ezV6f0$
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 packets.
The above also pointed out a solution based on TEA that is later specified in*section-2.1__;Iw!!NEt6yMaO-gk!G1pQRVj-WJSN9_KmeVqpMHxp94H2FqWg2JUguN-cIqGqgA2ilipHawl9tlNwPNR9elbX_KUoF7StBwkXLVjxTCM$  .
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;!!NEt6yMaO-gk!G1pQRVj-WJSN9_KmeVqpMHxp94H2FqWg2JUguN-cIqGqgA2ilipHawl9tlNwPNR9elbX_KUoF7StBwkXHpgtvAk$