Re: [Bier] adoption call for draft-zzhang-bier-multicast-as-a-service

Aijun Wang <> Wed, 15 June 2022 00:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47E81C15AAEB; Tue, 14 Jun 2022 17:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.805
X-Spam-Status: No, score=-6.805 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K_tnYaAkV0Vc; Tue, 14 Jun 2022 17:31:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DADDC15AAEA; Tue, 14 Jun 2022 17:31:31 -0700 (PDT)
Received: from (unknown []) by (Hmail) with ESMTPA id E9D491C0239; Wed, 15 Jun 2022 08:31:28 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-4A03A490-7601-4F52-B4EB-E1C2946DFD64"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <>
Mime-Version: 1.0 (1.0)
Date: Wed, 15 Jun 2022 08:31:28 +0800
Message-Id: <>
References: <>
In-Reply-To: <>
To: "Jeffrey (Zhaohui) Zhang" <>
X-Mailer: iPhone Mail (19F77)
X-HM-Tid: 0a8164c5bac0d993kuwse9d491c0239
Archived-At: <>
Subject: Re: [Bier] adoption call for draft-zzhang-bier-multicast-as-a-service
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, 15 Jun 2022 00:31:37 -0000

Hi, Jeffrey:
Thanks for your explanation.
Adding the corresponding part will be helpful for the reader. And regarding to the following description:

> Zzh> I should add (to the draft) that, when a provider edge re-advertises BIER SAFI routes to its customers, only the ones with BFR-IDs (i.e. these are customer BFERs), and the one originated by itself need to be re-advertised. The provider’s internal BFRs do not need to be advertised to the customers.

Are the above statement contradictory?  Is there any provider’s internal BFR has no BFR-ID? It is still confused that what and how the provider edge router advertise the selected prefixes to the customer—-besides of the customer BFERs, there should be some BFRs within the provider itself? 

Aijun Wang
China Telecom

> On Jun 14, 2022, at 22:45, Jeffrey (Zhaohui) Zhang <> wrote:
> Hi Aijun,
> Thanks for you review and support.
> Please see zzh> below.
> Juniper Business Use Only
> From: BIER <> On Behalf Of Aijun Wang
> Sent: Monday, June 13, 2022 11:51 PM
> To: <>
> Cc:;
> Subject: Re: [Bier] adoption call for draft-zzhang-bier-multicast-as-a-service
> [External Email. Be cautious of content]
> Hi, 
> I support its adoption and think it provides the solutions that the customers can use to deploy their multicast services based on BIER technology.
> Can the authors make some clarification for the description in section 2.1 “BGP Procedures”:
>   “If a provider provides independent BAAS services to multiple
>    customers, when its BFR receives BIER prefixes from a customer it
>    MUST re-advetise with a new BIER SAFI.  For simplicity, all BFRs of
>    the provider use the same RD that is specifically assigned for the
>    customer.  When a BFR re-advertises BIER prefixes to a customer, it
>    MUST re-advertise with SAFI 1 or 2.”
> Why the BIER SAFI is not used when a BFR re-advertise BIER prefixes to a customer?
> Zzh> Those multiple customers may have overlapping sub-domain-id and bfr-id. As mentioned below:
> 1.3.1.  Providing Independent BAAS To Multiple Customers
>    Now consider that the ISP also provides BAAS for another CDN.  Each
>    of the two CDNs has its own BIER domain, with its own BFR-ID or even
>    sub-domain ID assignment that could conflict between the two CDNs.
>    For example, both have BFR-ID 100 and sub-domain ID 0 assigned but
>    they are totally independent of each other.  For an BFR in the ISP to
>    support this, with BGP signaling it needs to advertise its own BFR
>    prefix multiple times, each time with a different RD that is mapped
>    to the corresponding CDN.  A new SAFI BIER (to be allocated by IANA)
>    is used.
> Zzh> The last two sentences explain why a new SAFI is needed for the provider to advertise its own BIER prefixes multiple times (with different RDs) for those different customers. When it receives BIER prefixes from its customers, it is regular SAF 1/2 not BIER SAFI and it needs to re-advertise via BIER SAFI with corresponding RDs (to match its own advertisements for the customers), and when it re-advertise customer BIER prefixes back to customers, it needs to go back SAFI 1/2 w/o RD – just like regular VPN case (when you re-advertise customer routes into core you use VPN-IP with RD and when you re-advertise routes learned from core to customer you use IP w/o RD).
> Zzh> I should add (to the draft) that, when a provider edge re-advertises BIER SAFI routes to its customers, only the ones with BFR-IDs (i.e. these are customer BFERs), and the one originated by itself need to be re-advertised. The provider’s internal BFRs do not need to be advertised to the customers.
> And for the IANA consideration part, why the OSPFv3 corresponding part is missed?
> Zzh> Thanks for spotting the oversight.
> Zzh> Thanks.
> Zzh> Jeffrey
> Aijun Wang
> China Telecom
> On Jun 5, 2022, at 18:19, wrote:
> This is the 2-week WG adoption call  for 
> Please indicate your support or objection.
> Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft.
> Thanks, 
> Sandy (As WG secretary, on behalf of Greg/Tony)
> _______________________________________________
> BIER mailing list
> _______________________________________________
> BIER mailing list