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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Fanghong,

Please see zzh1> below.



Juniper Business Use Only
From: duanfanghong <duanfanghong=[e-mail]>
Sent: Saturday, June 18, 2022 6:10 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail] <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: [Bier] adoption call for draft-zzhang-bier-multicast-as-a-service

[External Email. Be cautious of content]

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]<mailto:[e-mail]>>; [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

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...

Zzh1> Note that the client BFR prefixes are *not* in VPNs and are not expected to be overlapping, and they are leaked into provider network under the control of the provider. The use of RD (as part of the NLRI in case of BGP and as part of the BIER info TLV in case of IGP) is just so that overlapping sub-domains and BFR-IDs can be distinguished.

Zzh1> Of course, as signaling extensions needs to be reviewed by relevant WGs as the draft progresses.
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.

Zzh1> I was mainly referring to the fact that underlay has state corresponding to the overlay in both cases.

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.

Zzh1> I will clarify that it is not VPN and there is no overlapping address. On the other hand, I have a solution being worked out even for VPN case. Will share once it solidifies.

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 ?
Zzh1> RD itself does not have any semantics and it is for "Route Distinguishment" and nothing else when we talk about route propagation/handling. A solution can choose to use RDs to distinguish other things as well (e.g., mapping RDs to clients). Indeed, we either use the same RD on all PEs so that it can implicitly identify clients or have explicit client-id sub-TLV, and in both cases consistent assignment is needed across the PEs. This consistent assignment (I would not say manual because in theory one may design a way to auto-derive or somehow orchestrate the assignment) is no different from that RTs for VPNs need consistent assignments (but remember VPN is not used here - VPN is mentioned just as an analogy).

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.
Zzh1> We can continue that discussion in BESS; but I want to point out that there is a difference between SFS itself (this is before c-multicast route is generated) and distinguishing c-multicast routes.
Zzh1> Jeffrey

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$>