From nobody Sat Jun 18 03:10:16 2022 Return-Path: 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 65C74C14F721; Sat, 18 Jun 2022 03:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 Nfdj0a9gqPwh; Sat, 18 Jun 2022 03:10:11 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB8AC14F74E; Sat, 18 Jun 2022 03:10:11 -0700 (PDT) Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LQBV93v0Gz67xMh; Sat, 18 Jun 2022 18:09:53 +0800 (CST) Received: from kwepemi500004.china.huawei.com (7.221.188.17) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 18 Jun 2022 12:10:07 +0200 Received: from dggpemm100009.china.huawei.com (7.185.36.113) by kwepemi500004.china.huawei.com (7.221.188.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 18 Jun 2022 18:10:05 +0800 Received: from dggpemm100009.china.huawei.com ([7.185.36.113]) by dggpemm100009.china.huawei.com ([7.185.36.113]) with mapi id 15.01.2375.024; Sat, 18 Jun 2022 18:10:04 +0800 From: duanfanghong To: "Jeffrey (Zhaohui) Zhang" , "EXT-zhang.zheng@zte.com.cn" , "bier@ietf.org" CC: "bier-chairs@ietf.org" Thread-Topic: =?iso-8859-1?Q?[Bier]__adoption_call_for=A0draft-zzhang-bier-multicast-as?= =?iso-8859-1?Q?-a-service?= Thread-Index: AQHYgl2ThSC40PNlnEiTfDsrQB6l8a1U4i/w Date: Sat, 18 Jun 2022 10:10:04 +0000 Message-ID: <7843352f4de2488c9376c841c0b33f74@huawei.com> References: <202206051818505313413@zte.com.cn> <000a3d2234b948248e42199b0c9667bd@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.128.119] Content-Type: multipart/alternative; boundary="_000_7843352f4de2488c9376c841c0b33f74huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Bier] =?iso-8859-1?q?adoption_call_for=A0draft-zzhang-bier-mult?= =?iso-8859-1?q?icast-as-a-service?= X-BeenThere: bier@ietf.org 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: Sat, 18 Jun 2022 10:10:15 -0000 --_000_7843352f4de2488c9376c841c0b33f74huaweicom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jeffrey, Please see Dfh1> below. Thanks. Fanghong From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=3D40juniper.net@dmarc.ietf.org= ] Sent: Friday, June 17, 2022 11:18 PM To: duanfanghong ; EXT-zhang.zheng@zte.com.cn ; bier@ietf.org Cc: bier-chairs@ietf.org Subject: RE: [Bier] adoption call for draft-zzhang-bier-multicast-as-a-serv= ice Hi Fanghong, Thanks for your comments. Please see zzh> below. -----Original Message----- From: BIER > On Behalf = Of duanfanghong Sent: Thursday, June 16, 2022 5:57 AM To: EXT-zhang.zheng@zte.com.cn >; bier@ietf.org Cc: bier-chairs@ietf.org Subject: Re: [Bier] adoption call for draft-zzhang-bier-multicast-as-a-serv= ice [External Email. Be cautious of content] I have read this draft and have following comments: 1. In this document, it introduced a RD domain sub-tlv to leak all the clie= nt BFR prefixes to provider's backbone. The solution doesn't follows the tr= aditional VPN architecture, and faces the scalable problems in the scenario= s with large scale VPNs. And the providers may also don't want to be aware = of the client BFR prefixes in backbone. Zzh> Only the client BFIR/BFER (not internal BFR) prefixes - those with a n= on-zero BFR-ID) need to be leaked into the provider's backbone, and *only i= f* the provider wants to provide transit BIER transportation that way (simi= lar to whether a provider want to use selective tunnels to transport MVPN t= raffic as the selective tunnels are state in provider network but specifica= lly for customer traffic). Dfh1> I think leaking the client BFR prefix to backbone is a violation of t= raditional VPN architecture regardless of the numbers of client prefixes to= be leaked, and should be further discussed in BESS, IDR and LSR... Dfh1> The procedure of leaking the client BFR prefix to backbone is not wit= h the same conception as MVPN selective tunnel procedures, in which the MVP= N selective procedure is with a distinct line between overlay (client multi= cast) and underlay (P-Tunnels established by P-tree signaling protocols wit= hout being aware of any information of the client network), while in your l= eaking procedure the backbone must be aware of the leaked client prefixes e= xactly. Dfh1> Because sub-TLVs is not a key field of IGP topology, considering the = scenario that two VPNs have a same client prefix to be leaked to the backbo= ne, I wonder whether your solution can work. Zzh> Consider that a client has 1000 BFIRs/BFERs (no matter how many BFRs i= t has) connected to a provider via 100 peering points, and client BIER traf= fic from one client BFIR needs to transit all 100 peering points (incoming = on one and outgoing on 99). The provider *has a choice* of distributing 100= 0 client BFIR/BFER prefixes into its network so that the replication inside= its network is efficient, or simply doing ingress replication - tunneling = BIER traffic from the incoming peering point to 99 outgoing peering point (= which does not involve the procedures in this document). 2. It was recommended in the draft that the RDs of all sites of a specific = user VPN should be same, I wonder whether the solution can work if the RDs = is distinct, which the author of this draft discussed with me in BESS maili= ng list for another draft and he insisted that the RDs is distinct in most = cases. Zzh> The draft says: *For simplicity*, all BFRs of the provider use the same RD that is specifically assigned for the customer. Zzh> Using different RDs certainly work - as long as there is a way to know= which routes are for which client (e.g., introducing a sub-tlv for "client= -id"). I can clarify that in the draft. However, using different RDs for BI= ER prefix routes does not have any advantages. Dfh1> Did you meant that, in the scenarios with same RD the BIER domain ID = is RD while in the scenarios with different RDs the BIER domain ID is "clie= nt-id" which could be assigned manually for each VPNs ? Zzh> The scenario is different from the BGP-MVPN one in the BESS mailing li= st discussion, where distinct RDs are REQUIRED for Single Forwarder Selecti= on and DESIRED otherwise. Dfh1> As I said in BESS mailing list, using distinct RDs is not a only way= for Single Forwarder Selection. It is just an optional scenarios of deploy= ment. Zzh> Jeffrey -----Original Message----- From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of zhang.zheng@zte.com.= cn Sent: Sunday, June 5, 2022 6:19 PM To: bier@ietf.org Cc: bier-chairs@ietf.org Subject: [Bier] adoption call for draft-zzhang-bier-multicast-as-a-service This is the 2-week WG adoption call for https://urldefense.com/v3/__https:= //datatracker.ietf.org/doc/draft-zzhang-bier-multicast-as-a-service/__;!!NE= t6yMaO-gk!GyU1JM8mKhn2BJgATtbLqG_6YNjYmuMuPT-xPNaQDAT2f_AKWVA_NoDQyOcwJQ8m3= zlPp2UWyxeqIomiyeulTKITwQ-JJ0c2$ 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) Juniper Business Use Only _______________________________________________ BIER mailing list BIER@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!= NEt6yMaO-gk!GyU1JM8mKhn2BJgATtbLqG_6YNjYmuMuPT-xPNaQDAT2f_AKWVA_NoDQyOcwJQ8= m3zlPp2UWyxeqIomiyeulTKITwWn_VJFy$ _______________________________________________ BIER mailing list BIER@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!= NEt6yMaO-gk!GyU1JM8mKhn2BJgATtbLqG_6YNjYmuMuPT-xPNaQDAT2f_AKWVA_NoDQyOcwJQ8= m3zlPp2UWyxeqIomiyeulTKITwWn_VJFy$ --_000_7843352f4de2488c9376c841c0b33f74huaweicom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jeff= rey,

&n= bsp;

Please = see Dfh1> below.

&n= bsp;

Thanks.=

Fanghon= g

 

 

From: = Jeffrey (Zhaohui) Zhang [mailto:zzhang=3D40juniper.net@dmarc.ietf.org]
Sent: Friday, June 17, 2022 11:18 PM
To: duanfanghong <duanfanghong@huawei.com>; EXT-zhang.zheng@zt= e.com.cn <zhang.zheng@zte.com.cn>; bier@ietf.org
Cc: bier-chairs@ietf.org
Subject: RE: [Bier] adoption call for draft-zzhang-bier-multica= st-as-a-service

 

Hi Fanghong,

 

Thanks for your comments. Please see= zzh> below.

&nbs= p;

-----Original Message-----
From: BIER <bier-bounces@ietf.o= rg> On Behalf Of duanfanghong
Sent: Thursday, June 16, 2022 5:57 AM
To: EXT-zhang.zheng@zte.com.c= n <zhang.zheng@zte.com.cn<= /a>>; bier@ietf.org
Cc: bier-chairs@ietf.org
Subject: Re: [Bier] adoption call for draft-zzhang-bier-multicast-as-a= -service

 

[External Email. Be cautious of cont= ent]

 

 

I have read this draft and have foll= owing comments:

 

1. In this document, it introduced a= RD domain sub-tlv to leak all the client BFR prefixes to provider's backbo= ne. The solution doesn't follows the traditional VPN architecture, and faces the scalable problems in the scenarios with la= rge scale VPNs. And the providers may also don't want to be aware of the cl= ient BFR prefixes in backbone.

&nbs= p;

Zzh> Only the client BFIR/BFER (n= ot internal BFR) prefixes - those with a non-zero BFR-ID) need to be leaked= into the provider's backbone, and *only if* the provider wants to provide transit BIER transportation that way (similar to whether = a provider want to use selective tunnels to transport MVPN traffic as the s= elective tunnels are state in provider network but specifically for custome= r traffic).

Dfh1>= ; I think leaking the client BFR prefix to backbone is a violation of tradi= tional VPN architecture regardless of the numbers of client prefixes to be = leaked, and should be further discussed in BESS, IDR and LSR…

Dfh1>= ; The procedure of leaking the client BFR prefix to backbone is not with th= e same conception as MVPN selective tunnel procedures, in which the MVPN se= lective procedure is with a distinct line between overlay (client multicast) and underlay (P-Tunnels established by = P-tree signaling protocols without being aware of any information of the cl= ient network), while in your leaking procedure the backbone must be aware o= f the leaked client prefixes exactly.

Dfh1>= ; Because sub-TLVs is not a key field of IGP topology, considering the scen= ario that two VPNs have a same client prefix to be leaked to the backbone, = I wonder whether your solution can work.

 

Zzh> Consider that a client has 1= 000 BFIRs/BFERs (no matter how many BFRs it has) connected to a provider vi= a 100 peering points, and client BIER traffic from one client BFIR needs to transit all 100 peering points (incoming on one a= nd outgoing on 99). The provider *has a choice* of distributing 1000 client= BFIR/BFER prefixes into its network so that the replication inside its net= work is efficient, or simply doing ingress replication - tunneling BIER traffic from the incoming peering poi= nt to 99 outgoing peering point (which does not involve the procedures in t= his document).

&nbs= p;

2. It was recommended in the draft t= hat the RDs of all sites of a specific user VPN should be same, I wonder wh= ether the solution can work if the RDs is distinct, which the author of this draft discussed with me in BESS mailing list for = another draft and he insisted that the RDs is distinct in most cases.<= /o:p>

&nbs= p;

Zzh> The draft says:

 

   *For simplicity*, all BFRs of

   the provider use the sa= me RD that is specifically assigned for the

   customer.

&nbs= p;

Zzh> Using different RDs certainl= y work - as long as there is a way to know which routes are for which clien= t (e.g., introducing a sub-tlv for "client-id"). I can clarify that in the draft. However, using different RDs for BIER prefi= x routes does not have any advantages.

Dfh1>= ; Did you meant that, in the scenar= ios with same RD the BI= ER domain ID is RD while in the scenarios with different RDs the BIER domain ID is “client-id” which could = be assigned manually for each VPNs ?

Zzh> The scenario is different fr= om the BGP-MVPN one in the BESS mailing list discussion, where distinct RDs= are REQUIRED for Single Forwarder Selection and DESIRED otherwise.

 Dfh1> As I said in BESS mailing list, using distin= ct RDs is not a only way for Single Forwarder Selection. It is just an optional scenarios of deployment.

 

Zzh> Jeffrey

&nbs= p;

-----Original Message-----

Sent: Sunday, June 5, 2022 6:19 PM

Subject: [Bier] adoption call for dr= aft-zzhang-bier-multicast-as-a-service

 

Please indicate your support or obje= ction.

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)


Juniper Business = Use Only

&nbs= p;

____________________________________= ___________

BIER mailing list<= /p>

&nbs= p;

____________________________________= ___________

BIER mailing list<= /p>

&nbs= p;

--_000_7843352f4de2488c9376c841c0b33f74huaweicom_--