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

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<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-zzhang-bier-multicast-as-a-service-04*section-2.1__;Iw!!NEt6yMaO-gk!ERYbnBni0Qf4qGsC1Rmi0S7a798KRdXxbt7VX9MyohdNzV-D27RZZlv4jLGaBesUGibeLYz8uEFTf7K1i5xwWbAn$>

  “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<https://datatracker.ietf.org/doc/html/draft-zzhang-bier-multicast-as-a-service-04#section-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<mailto: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<mailto:BIER@ietf.org>
https://www.ietf.org/mailman/listinfo/bier