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

Aijun Wang <wangaijun@tsinghua.org.cn> Thu, 16 June 2022 04:05 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D620C14CF05; Wed, 15 Jun 2022 21:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.807
X-Spam-Level:
X-Spam-Status: No, score=-1.807 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiRjmiTWnzqL; Wed, 15 Jun 2022 21:05:27 -0700 (PDT)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426E3C14CF07; Wed, 15 Jun 2022 21:05:23 -0700 (PDT)
Received: from smtpclient.apple (unknown [221.223.97.163]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 440E11C009D; Thu, 16 Jun 2022 12:05:21 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-7C3D0A28-2D6C-49C3-80DE-7D73D6E0D281"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Thu, 16 Jun 2022 12:05:20 +0800
Message-Id: <20293D05-D148-4B54-81A8-9BE44E93FF68@tsinghua.org.cn>
References: <BL0PR05MB5652796DEA8819323E639322D4AC9@BL0PR05MB5652.namprd05.prod.outlook.com>
Cc: zhang.zheng@zte.com.cn, bier@ietf.org, bier-chairs@ietf.org
In-Reply-To: <BL0PR05MB5652796DEA8819323E639322D4AC9@BL0PR05MB5652.namprd05.prod.outlook.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>
X-Mailer: iPhone Mail (19F77)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVkaGh1JVk0dHk9MH05PHkIeTVUTARMWGhIXJB QOD1lXWRgSC1lBWUlJSlVJSUhVQkxVSk1IWVdZFhoPEhUdFFlBWU9LSFVKSktITk9VS1kG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PCo6Eyo4Az00F1ErHi4cKjFI FBwwCkhVSlVKTU5OSE5JSElKQ0hMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSUpVSUlIVUJMVUpNSFlXWQgBWUFJQk1LTTcG
X-HM-Tid: 0a816aafe502d993kuws440e11c009d
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/X8lBvzQ7N2jhyEsYPWij7v6OlVI>
Subject: Re: [Bier] adoption call for draft-zzhang-bier-multicast-as-a-service
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jun 2022 04:05:32 -0000

Hi, Jeffrey:

I think the statement “…. …and the one originated by itself need to be re-advertised. “ may be more better to be understood via changing to “… … and the one included in the TRA attributes need to be re-advertised”?

Aijun Wang
China Telecom

> On Jun 16, 2022, at 09:52, Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org> wrote:
> 
> 
> Hi Aijun,
>  
> Only BFIRs/BFERs (those need to encapsulate or decapsulate BIER headers) need to have BFR-IDs. Transit BFRs don’t need BFR-IDs.
>  
> Consider the following:
>  
>      BFER1  (customer BIER network) C-BFR1 --- P-BFR1 (provider BIER network) P-BFR2 --- C-BFR2 (customer BIER network) BFER2
>  
> P-BFR1/2 are border routers of the provider network. C-BFR1/2 are border routers of the customer network.
> C-BFR1 learns BFER1’s BIER prefix and readvertises via BGP to P-BFR1 using SAFI 1/2, who re-advertises into the provider network using the BIER SAFI (or IGP). P-BFR2 learns that and then re-advertises to C-BFR2 (using SAFI 1/2), with the TEA set to itself (so that C-BFR2 will send BIER traffic to P-BFR2 – as explained in https://datatracker.ietf.org/doc/html/draft-zzhang-bier-multicast-as-a-service-04.html#section-2.1).
> Now for C-BFR2 to know what BIER label to use to send to P-BFR2, P-BFR2 needs to advertise its own BIER prefix with BIER information.
>  
> C-BFR2 does not need to know about P-BFR1 or any other internal BFRs in the provider network.
>  
> That is why “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”. 
>  
> Jeffrey
>  
>  
> Juniper Business Use Only
> From: Aijun Wang <wangaijun@tsinghua.org.cn> 
> Sent: Tuesday, June 14, 2022 8:31 PM
> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> Cc: EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; 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, 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