Hi Heng, Please see <VK> below,
From: Wangheng (MCAST, P&S) <wanghen...@huawei.com> Date: Monday, July 25, 2022 at 5:32 AM To: Vinod Kumar Nagaraj <vinku...@juniper.net>, bess@ietf.org <bess@ietf.org>, duanfanghong <duanfangh...@huawei.com> Subject: RE: [bess] draft-wang-bess-mvpn-upstream-df-selection-01.txt [External Email. Be cautious of content] Hi Vinod Kumar, Thanks for your questions. Please see WH below. From: Vinod Kumar Nagaraj [mailto:vinku...@juniper.net] Sent: Monday, July 25, 2022 6:10 PM To: bess@ietf.org; Wangheng (MCAST, P&S) <wanghen...@huawei.com>; duanfanghong <duanfangh...@huawei.com> Subject: [bess] draft-wang-bess-mvpn-upstream-df-selection-01.txt Hi Heng/Fanghong, I had few queries as below w.r.t draft-wang-bess-mvpn-upstream-df-selection-01, 1. Abstract The downstream PEs, accordingly, send C-multicast routes to both the primary and standby upstream PEs and forward the multicast flow comming from both sides to the CEs. Please edit the last part of sentence as ‘forward the multicast flow coming from either side to the CEs.’ WH: Ok, we will rephrase the description. <VK> Thank you. 2. Introduction says that there are problems with hot root standby procedures in RFC 9026 - Duplicate traffic in Core and monitoring P-tunnel status via BFD. Then it goes on to say that the current draft proposes a different ‘warm root standby’ mechanism. So this draft does not address problems with hot root standby’ procedures ? Only proposing alternate way of doing ‘warm root standby’ ? WH: Yes, we consider that the problems in the ‘hot’ method do not exist in the ‘warm’ one, however, the ‘warm’ convergence performance is not as good as ‘hot’. So our main purpose is to improve the ‘warm’ procedure to gain a better convergence performance. <VK> This draft is only talking about alternate warm standby procedures to what is captured in RFC 9026. Can you please remove the text on hot standby procedures as we are not enhancing or modifying hot standby procedures in this draft? 3. multi homing ingress PEs to determine "locally" a single forwarder to avoid duplicate packets sending through the backbone, without the egress PEs' primary or standby UMH selection. The above snippet from Introduction is not completely correct. Egress PE is sending C-multicast join to both Primary and Backup Upstream PEs, which means UMH selection is happening on Egress PEs. Please re-phrase. WH: Yes, egress PEs do perform UMH selection and send C-multicast join to both sides, but an egress PE do not need to decide which one is primary or standby, it just consider all the ingress PEs equal. We will rephrase the description to clarify the procedure. <VK> Thank you. 4. Draft proposes A) upstream DF election between multi-homing ingress PEs. B) Downstream PEs advertising Primary and Standby C-multicast routes and accepting traffic from either of the upstream PEs. How does an implementation detect an Upstream MVPN PE ? It’s only on receiving a BGP C-multicast route from remote/downstream PE, that an implementation can detect the PE as Upstream. There is time involved in detecting upstream PE, detecting multi-homed upstream PEs and kickstarting upstream DF election. Multicast convergence would take a hit. WH: The Upstream PEs detection for a given (C-S, C-G) flow could be implemented by some administrative measure such as configuration or deployment, which do not depend on receiving C-multicast routes from other PEs. <VK> This would mean config change each time upstream status of a PE changes ( source attached/detached ). 5. Warm standby solution in RFC 9026 does not forward Duplicate traffic into Core. Traffic from CE would hit Standby Upstream PE, but the Standby PE wouldn’t put the traffic into the core/PMSI. I am not able to see the gain these alternate procedures bring when compared to warm standby procedures in RFC 9026. RFC 9026 Hot root standby procedures forward redundant copies into the core to ensure fast failover ( sub second multicast convergence in the event of any failures in upstream path ). For optimal multicast convergence , hot root standby procedures need to be turned on. Do the procedures proposed in this draft guarantee optimal multicast convergence like hot root standby procedures ? WH: The main warm standby procedure difference between RFC9026 and this draft is that the ‘selection action’ is performed by Downstream PEs or by Upstream PEs. If the selection is performed by a downstream PE, Indeed the convergence performance is not as good as hot root standby. But if the selection is performed by a upstream PEs, it could be more likely to reach a same level. <VK> Are you trying to compare warm standby procedures in this draft with hot standby procedures in RFC 9026 in terms of convergence ? I believe we are comparing / talking about warm standby procedures in this draft with warm standby procedures in RFC 9026. Failover time in both of these warm standby procedures look identical. If you can elaborate failover procedures that would help to understand the gain better Regards, Vinod Kumar. Juniper Business Use Only Juniper Business Use Only
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
