Hi Siyu, For the following:
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- #6. ... According to the negotiation community, a distinct C-Multicast route for (C-S, C-G) is sent to each multi-homed root PE. Leaf PE installs all P-Tunnels rooted from the multi-homed PEs into the anycast RPF tunnel checklist of the corresponding multicast traffic (C-S, C-G). > Suggestion : This means, if there are four ingress PEs for the same flow, > all of them will receive the C-multicast route. With the RFC9026 procedure, > only two of them will, and the selection can still be based on (s,g). In summary, I don't see sufficient advantages of developing another solution now that RFC9026 have been implemented and deployed. >> Reply: In RFC9026, there can be one standby PE or multiple standby PEs. a) Multiple standby PEs in Section 3.1.6.2: 'If the site that contains C-S is connected to two or more PEs, a downstream PE will select one as its Primary Upstream PE, while others are considered to be Standby Upstream PEs'. b) One standby PE in Section 4: 'In the case where more than two PEs are connected to the C-S site, selection of the Standby PE can be performed using one of the methods of selecting a UMH.' In our draft, we will modify relevant descriptions so that only one PE will be selected as Standby PE. C-multicast route will only be sent to the selected Standby PE. The advantage of our approach over RFC9026 has been mentioned in #3. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- My understanding is from the following text: If a leaf PE decides to send C-Multicast routes to upstream PEs for a given (C-S, C-G), it follows the procedure described in [RFC6514] excepting that the RPF route of the c-root has an IDF negotiation --->community. According to the negotiation community, a distinct --->C-Multicast route for (C-S, C-G) is sent to each multi-homed root PE. ... b. To perform IDF election for each C-G of a specific multicast source C-S, each PE also builds an ordered list of the IP addresses of all the multi-homed PE nodes at first. The difference between this option and above is that the election of IDF occurs not upon receiving all UMH routes of the other multi- ---->homed PEs of the specfied C-S but upon receiving the C-multicast ---->join of the corresponding C-G. Assuming an ordered list of N elements, the PE with ordinal i is the IDF for a C-G when (C-G mod N) = i. The PE with ordinal j is the Standby IDF when j is (C-G mod (N-1)). The calculation of standby IDF uses the ordered IP addresses list without considering the existance of the elected IDF element. To perform (S,G) based selection, all root PEs must receive the C-mcast routes first. Thanks. Jeffrey Juniper Business Use Only -----Original Message----- From: Chensiyu (Susie) <chensiyu27=40huawei....@dmarc.ietf.org> Sent: Monday, February 13, 2023 7:11 AM To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; bess@ietf.org Cc: duanfanghong <duanfangh...@huawei.com> Subject: RE:RE: New Version Notification for draft-wang-bess-mvpn-upstream-df-selection-03.txt [External Email. Be cautious of content] Hi, Jeffrey Thank you very much for your feedback on our draft. We will update a new version of the draft later based on our discussions. Our replies to all suggestions are as follow. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- #1. For the "hot root standby" mechanism, all the ingress PEs, regardless of the primary or standby role, forward (C-S,C-G) flow to other PEs through a P-tunnel, forcing the egress PEs to discard all but one, which will cause the steady traffic redundancy throughout the backbone network. In the scenarios of enterprise networks crossing provider networks, the waste of bandwidth is a crucial issue causing the increasement of the OpEx of enterprise networks, and the "warm root standby" mechanism is expected to be a better solution. > Suggestion : The mentioning of Hot Root Standby (HRS) should be removed. It is specifically designed for scenarios where it is critical for egress PEs to receive but discard duplicates and BW consumption is not a concern. Where BW is a concern, the Warm Root Standby (WRS) can be used. This draft should only compare to WRS. >> Reply : We will modify the first paragraph of the Introduction Section in >> the new version. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- #2. However, there are some problems when deploying the "warm root standby" mechanism described in [RFC9026]. a. Upon the failure of primary ingress PE, the standby ingress PE needs to send PIM join hop by hop toward multicast source for each multicast flow and the time when the standby ingress PE switches to the primary role may be inconsistent with the time when the leaf PE determines to accept multicast traffic sent by the standby root, causing which the failover time can hardly reach the same level of "hot root standby" mechanism. > Suggestion : This point should be removed because it describes Cold Root > Standby. With WRS in RFC9026, traffic already arrives on both PEs. >> Reply : Agree. We will remove 'the standby ingress PE needs to send PIM join >> hop by hop toward multicast source'. Actually, upon the failure of primary ingress PE, the leaf PE is the one that needs to send the new C-multicast route towards the standby ingress PE without carrying the Standby PE BGP Community according to RFC9026. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- #3. b. There is no endogenous mechanism for standby ingress PEs to discover and detect the failure of primary ingress PEs, resulting in the uncertainty in deployment and implementation. > Question : What's the problem of relying on egress PEs detecting the failure > of primary PE? >>Reply: It takes longer switchover time. When the egress PE detects the >>failure of the ingress Primary PE, it will update all relevant C-multicast >>routes and send them to the standby ingress PE. For example, if there are 1000 (C-S, C-G)s, 1000 C-multicast routes will be updated and resent so that the standby PE can finally forward traffic. (The switchover time will be correspondingly longer than using ingress PE to detect and forward traffic directly.) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- #4. c. In [RFC9026], the standby ingress PE is determined by using "Standby PE Community" carried in the C-Multicast routes. The premise of this mechanism is that all leaf PEs choose the same primary and standby ingress PEs, which may not be met due to transient unicast routing inconsistencies, the inconsistencies of P-Tunnel status determined by each leaf PE or lack of support of the Standby PE community on leaf PE, causing that the "warm root standby" mechanism is not stable and returns to "hot root standby" mode because the standby ingress PE also sends multicast traffic to backbone when the condition is not satisfied. > Suggestion: The potential inconsistent choice among egress PEs is likely > because that the tunnel branches may be up to some egress PEs while down to > others. That is actually a good reason for different choices - we don't want some egress PEs to not be able to receive from the primary PE. Besides, MVPN handles that situation well (remember that each egress PE can choose its ingress PE - see the "Another procedure ..." paragraph in https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc6513.html*section-5.1.3__;Iw!!NEt6yMaO-gk!FtW1BVw8oYoBMSyMd7diuprMxPYWtW0v5hXWOV6_iLjmvanu21PyGt8Tf_jiDoTCpigUlSb2FdCKCi6Pa3H2gEfQatRzuR_U$ ). If it desired to avoid that, the tunnel status consideration can be skipped and you'll get consistency that your draft wants, but both are at the cost of some egress PE may not be able to receive traffic. >> Reply: Yes, we will think about appropriate solutions to solve this problem. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- #5. anycast RPF checking mechanism in dataplane > Suggestion : The word "anycast" is misleading. You should say that traffic > from any of the ingress PEs can be accepted. >> Reply: Agree. We will update it with a more appropriate word or just use the >> phrase of 'traffic from any of the ingress PEs can be accepted'. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- #6. ... According to the negotiation community, a distinct C-Multicast route for (C-S, C-G) is sent to each multi-homed root PE. Leaf PE installs all P-Tunnels rooted from the multi-homed PEs into the anycast RPF tunnel checklist of the corresponding multicast traffic (C-S, C-G). > Suggestion : This means, if there are four ingress PEs for the same flow, > all of them will receive the C-multicast route. With the RFC9026 procedure, > only two of them will, and the selection can still be based on (s,g). In summary, I don't see sufficient advantages of developing another solution now that RFC9026 have been implemented and deployed. >> Reply: In RFC9026, there can be one standby PE or multiple standby PEs. a) Multiple standby PEs in Section 3.1.6.2: 'If the site that contains C-S is connected to two or more PEs, a downstream PE will select one as its Primary Upstream PE, while others are considered to be Standby Upstream PEs'. b) One standby PE in Section 4: 'In the case where more than two PEs are connected to the C-S site, selection of the Standby PE can be performed using one of the methods of selecting a UMH.' In our draft, we will modify relevant descriptions so that only one PE will be selected as Standby PE. C-multicast route will only be sent to the selected Standby PE. The advantage of our approach over RFC9026 has been mentioned in #3. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- #7. For the scenarios of the same RD, this document introduces a new type of UMH route to be sent in MVPN SAFI, of which the NLRI key consists of the following fields: > Suggestion: Instead of advertising the UMH route with the MVPN SAFI, we might > as well advertise with the VPN-IP SAFI with RD/RT, and use RT to import into > the default instance. It does not need any signaling changes and depending on > implementation it may just work. We wrote a draft and circulated internally/ > externally back in July 2022, but I am surprised that it was not posted. I will forward you a copy for your review. With this, it not only solves MVPN problem, but can also be used for unicast. >> Reply: We are reading and understanding the draft and we will reply about >> it later. Thanks again for your contribution to this draft. We are looking forward to more feedback from you. Best wishes, Susie -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper....@dmarc.ietf.org] Sent: Wednesday, February 8, 2023 8:49 AM To: Chensiyu (Susie) <chensiy...@huawei.com>; bess@ietf.org Cc: duanfanghong <duanfangh...@huawei.com> Subject: RE: New Version Notification for draft-wang-bess-mvpn-upstream-df-selection-03.txt Hi Siyu, Please see comments below. For the "hot root standby" mechanism, all the ingress PEs, regardless of the primary or standby role, forward (C-S,C-G) flow to other PEs through a P-tunnel, forcing the egress PEs to discard all but one, which will cause the steady traffic redundancy throughout the backbone network. In the scenarios of enterprise networks crossing provider networks, the waste of bandwidth is a crucial issue causing the increasement of the OpEx of enterprise networks, and the "warm root standby" mechanism is expected to be a better solution. The mentioning of Hot Root Standby (HRS) should be removed. It is specifically designed for scenarios where it is critical for egress PEs to receive but discard duplicates and BW consumption is not a concern. Where BW is a concern, the Warm Root Standby (WRS) can be used. This draft should only compare to WRS. However, there are some problems when deploying the "warm root standby" mechanism described in [RFC9026]. a. Upon the failure of primary ingress PE, the standby ingress PE needs to send PIM join hop by hop toward multicast source for each multicast flow and the time when the standby ingress PE switches to the primary role may be inconsistent with the time when the leaf PE determines to accept multicast traffic sent by the standby root, causing which the failover time can hardly reach the same level of "hot root standby" mechanism. This point should be removed because it describes Cold Root Standby. With WRS in RFC9026, traffic already arrives on both PEs. b. There is no endogenous mechanism for standby ingress PEs to discover and detect the failure of primary ingress PEs, resulting in the uncertainty in deployment and implementation. What's the problem of relying on egress PEs detecting the failure of primary PE? c. In [RFC9026], the standby ingress PE is determined by using "Standby PE Community" carried in the C-Multicast routes. The premise of this mechanism is that all leaf PEs choose the same primary and standby ingress PEs, which may not be meeted due to transient unicast routing inconsistencies, the inconsistencies of P-Tunnel status determined by each leaf PE or lack of support of the Standby PE community on leaf PE, causing that the "warm root standby" mechanism is not stable and returns to "hot root standby" mode because the standby ingress PE also sends multicast traffic to backbone when the condition is not satisfied. The potential inconsistent choice among egress PEs is likely because that the tunnel branches may be up to some egress PEs while down to others. That is actually a good reason for different choices - we don't want some egress PEs to not be able to receive from the primary PE. Besides, MVPN handles that situation well (remember that each egress PE can choose its ingress PE - see the "Another procedure ..." paragraph in https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc6513.html*section-5.1.3__;Iw!!NEt6yMaO-gk!FtW1BVw8oYoBMSyMd7diuprMxPYWtW0v5hXWOV6_iLjmvanu21PyGt8Tf_jiDoTCpigUlSb2FdCKCi6Pa3H2gEfQatRzuR_U$ ). If it desired to avoid that, the tunnel status consideration can be skipped and you'll get consistency that your draft wants, but both are at the cost of some egress PE may not be able to receive traffic. d. The primary and standby role is fixed for each multicast flow, resulting in that ingress PEs cannot perform load balancing for multicast traffic. Only two ingress PEs are selected for all multicast stream from a specific multicast source, causing that the "warm root standby" mechanism cannot be used in the scenarios of client nework multihoming to more than two ingress PEs. I don't think that is true. The same Single Forward Selection rules in RFC6513, which can do load balancing (see 5.1.3 of RFC6513) among different (C-S,C-G) flows, can be used to choose both primary and secondary UMH (the secondary one can be chosen the same way after excluding the primary one). If RFC9026 is not clear about that, it can be clarified. anycast RPF checking mechanism in dataplane The word "anycast" is misleading. You should say that traffic from any of the ingress PEs can be accepted. ... According to the negotiation community, a distinct C-Multicast route for (C-S, C-G) is sent to each multi-homed root PE. Leaf PE installs all P-Tunnels rooted from the multi-homed PEs into the anycast RPF tunnel checklist of the corresponding multicast traffic (C-S, C-G). This means, if there are four ingress PEs for the same flow, all of them will receive the C-multicast route. With the RFC9026 procedure, only two of them will, and the selection can still be based on (s,g). In summary, I don't see sufficient advantages of developing another solution now that RFC9026 have been implemented and deployed. For the scenarios of the same RD, this document introduces a new type of UMH route to be sent in MVPN SAFI, of which the NLRI key consists of the following fields: Instead of advertising the UMH route with the MVPN SAFI, we might as well advertise with the VPN-IP SAFI with RD/RT, and use RT to import into the default instance. It does not need any signaling changes and depending on implementation it may just work. We wrote a draft and circulated internally/ externally back in July 2022, but I am surprised that it was not posted. I will forward you a copy for your review. With this, it not only solves MVPN problem, but can also be used for unicast. Thanks. Jeffrey Juniper Business Use Only -----Original Message----- From: BESS <bess-boun...@ietf.org> On Behalf Of Chensiyu (Susie) Sent: Monday, November 21, 2022 7:27 AM To: bess@ietf.org Cc: duanfanghong <duanfangh...@huawei.com> Subject: [bess] FW: New Version Notification for draft-wang-bess-mvpn-upstream-df-selection-03.txt [External Email. Be cautious of content] Hi all, A new version of the draft https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-bess-mvpn-upstream-df-selection/__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyAEwJo9O$ is published, in which the root PEs differentiation issue of UMH route and dual-root protection issue in Segmented Inter-AS Scenario are resolved. We are looking forward to more comments, it would be appreciated if you can give some valuable suggestions to help us evolve it further . Regards, Siyu Chen ------------------------------------------------------------------------------------------------------- A new version of I-D, draft-wang-bess-mvpn-upstream-df-selection-03.txt has been successfully submitted by Siyu Chen and posted to the IETF repository. Name: draft-wang-bess-mvpn-upstream-df-selection Revision: 03 Title: Multicast VPN Upstream Designated Forwarder Selection Document date: 2022-11-21 Group: Individual Submission Pages: 16 URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-wang-bess-mvpn-upstream-df-selection-03.txt__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyIh-akra$ Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-bess-mvpn-upstream-df-selection/__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyAEwJo9O$ Htmlized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-wang-bess-mvpn-upstream-df-selection__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyGr5TPdY$ Diff: https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-wang-bess-mvpn-upstream-df-selection-03__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyDj7YPMP$ Abstract: This document defines Multicast Virtual Private Network (VPN) extensions and procedures of designated forwarder election performed between ingress PEs, which is different from the one described in [RFC9026] in which the upstream designated fowarder determined by using the "Standby PE Community" carried in the C-Multicast routes. Based on the DF election, the failure detcetion point discovery mechanism between DF and standby DF is extended in MVPN procedures to achieve fast failover by using BFD session to track the status of detection point. To realize a stable "warm root standby", this document obsolete the P-Tunnel status determining procedure for downstream PEs in regular MVPN by introducing an anycast RPF checking mechanism in dataplane as an instead. The IETF Secretariat _______________________________________________ BESS mailing list BESS@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyIKMC0SE$ _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess