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

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 <zzhang=40juniper.net@dmarc.ietf.org> wrote:
> 
> 
> Hi Aijun,
>  
> Thanks for you review and support.
>  
> Please see zzh> below.
>  
>  
> Juniper Business Use Only
> From: BIER <bier-bounces@ietf.org> On Behalf Of Aijun Wang
> Sent: Monday, June 13, 2022 11:51 PM
> To: EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>
> Cc: bier@ietf.org; bier-chairs@ietf.org
> 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”: https://datatracker.ietf.org/doc/html/draft-zzhang-bier-multicast-as-a-service-04#section-2.1
>  
>   “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, zhang.zheng@zte.com.cn wrote:
> 
> This is the 2-week WG adoption call  for 
> https://datatracker.ietf.org/doc/draft-zzhang-bier-multicast-as-a-service/
> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier