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

[duanfanghong <[e-mail]>]

Hi Jeffrey,

Please see Dfh1> below.

Thanks.
Fanghong


From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Friday, June 17, 2022 11:18 PM
To: duanfanghong <[e-mail]>; [e-mail] <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: [Bier] adoption call for draft-zzhang-bier-multicast-as-a-service

Hi Fanghong,

Thanks for your comments. Please see zzh> below.

-----Original Message-----
From: BIER <[e-mail]<mailto:[e-mail]>> On Behalf Of duanfanghong
Sent: Thursday, June 16, 2022 5:57 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Bier] adoption call for draft-zzhang-bier-multicast-as-a-service

[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 client BFR prefixes to provider's backbone. The solution doesn't follows the traditional VPN architecture, and faces the scalable problems in the scenarios 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 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 selective tunnels are state in provider network but specifically for customer traffic).
Dfh1> I think leaking the client BFR prefix to backbone is a violation of traditional 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 the same conception as MVPN selective tunnel procedures, in which the MVPN selective 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 client network), while in your leaking procedure the backbone must be aware of the leaked client prefixes exactly.
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 backbone, I wonder whether your solution can work.

Zzh> Consider that a client has 1000 BFIRs/BFERs (no matter how many BFRs it has) connected to a provider via 100 peering points, and client BIER traffic 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 1000 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 mailing 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 BIER 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 "client-id" which could be assigned manually for each VPNs ?
Zzh> The scenario is different from 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 distinct RDs is not a only way for Single Forwarder Selection. It is just an optional scenarios of deployment.

Zzh> Jeffrey

-----Original Message-----
From: BIER [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Sunday, June 5, 2022 6:19 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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/__;!!NEt6yMaO-gk!GyU1JM8mKhn2BJgATtbLqG_6YNjYmuMuPT-xPNaQDAT2f_AKWVA_NoDQyOcwJQ8m3zlPp2UWyxeqIomiyeulTKITwQ-JJ0c2$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-bier-multicast-as-a-service/__;!!NEt6yMaO-gk!GyU1JM8mKhn2BJgATtbLqG_6YNjYmuMuPT-xPNaQDAT2f_AKWVA_NoDQyOcwJQ8m3zlPp2UWyxeqIomiyeulTKITwQ-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
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!GyU1JM8mKhn2BJgATtbLqG_6YNjYmuMuPT-xPNaQDAT2f_AKWVA_NoDQyOcwJQ8m3zlPp2UWyxeqIomiyeulTKITwWn_VJFy$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!GyU1JM8mKhn2BJgATtbLqG_6YNjYmuMuPT-xPNaQDAT2f_AKWVA_NoDQyOcwJQ8m3zlPp2UWyxeqIomiyeulTKITwWn_VJFy$>

_______________________________________________
BIER mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!GyU1JM8mKhn2BJgATtbLqG_6YNjYmuMuPT-xPNaQDAT2f_AKWVA_NoDQyOcwJQ8m3zlPp2UWyxeqIomiyeulTKITwWn_VJFy$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!GyU1JM8mKhn2BJgATtbLqG_6YNjYmuMuPT-xPNaQDAT2f_AKWVA_NoDQyOcwJQ8m3zlPp2UWyxeqIomiyeulTKITwWn_VJFy$>