idnits 2.17.1 draft-wang-bess-mvpn-upstream-df-selection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5798]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (23 October 2021) is 916 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Wang 3 Internet-Draft F. Duan 4 Intended status: Informational Huawei Technologies 5 Expires: 26 April 2022 23 October 2021 7 Multicast VPN Upstream Designated Forwarder Selection 8 draft-wang-bess-mvpn-upstream-df-selection-00 10 Abstract 12 This document defines Multicast Virtual Private Network (VPN) 13 extensions and procedures that allow fast failover for upstream 14 failures by allowing upstream Provider Edges (PEs) to determine a 15 single forwarder for a VPN multicast flow, without the downstream 16 PEs' duplication prevention. The fast failover is accomplished by 17 using Virtual Router Redundancy Protocol (VRRP) [RFC5798] or similar 18 technologies for the upstream PEs to determine a single desinated 19 fowarder. Also, this document introduces a new BGP Extended 20 Community called "Upstream Forwarder Selection", carried by BGP VPN 21 route so that the upstream PEs can inform downstream PEs the election 22 behavior. The downstream PEs, accordingly, send C-multicast routes 23 to both the primary and standby upstream PEs and forward the 24 multicast flow comming from both sides to the CEs. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 30 "OPTIONAL" in this document are to be interpreted as described in BCP 31 14 [RFC2119] [RFC8174] when, and only when, they appear in all 32 capitals, as shown here. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 26 April 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Upstream Designated Forwarder Selection . . . . . . . . . . . 3 69 3.1. Upstream Designated Forwarder Selection by VRRP . . . . . 4 70 3.2. Other Feasible Selection Technologies . . . . . . . . . . 4 71 4. Upstream Forwarder Selection Extended Community . . . . . . . 4 72 5. Downstream PE Behavior . . . . . . . . . . . . . . . . . . . 5 73 5.1. Standby C-multicast Route Advertisment . . . . . . . . . 5 74 5.2. Anycast Reverse Path Forwarding Checking . . . . . . . . 5 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 78 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 MVPN [RFC6513] and [RFC6514] defines the MVPN architecture and MVPN 84 protocol specification which include the basic procedures for 85 selecting the Upstream Multicast Hop. Further [RFC9026] defines some 86 extension that allow fast failover for upstream failures by allowing 87 downstream PEs to consider the status of Provider-Tunnels (P-tunnels) 88 when selecting the Upstream PE for a VPN multicast flow. However, 89 there are some problems when deploying the "hot root standby" 90 mechanism described in [RFC9026]. 92 First, all the ingress PEs, regardless of the primary or standby 93 role, forward (C-S,C-G) flow to other PEs though a P-tunnel, forcing 94 the egress PEs to discard all but one, which will cause the steady 95 traffic redundancy throughout the backbone network. 97 Second, an efficient and accurate method for the downstream PEs to 98 determine the "status" of a P-tunnel is required, which is somewhat 99 complicated in some cases, as mentioned in Section 3.1.8 of [RFC9026] 101 This document proposes a different "warm root standby" procedure 102 mentioned in Section 4.2 of [RFC9026]. The procedures include a) an 103 upstream designated forwarder election between multi homing ingress 104 PEs, and b) the downstream PEs' advertising Primary and Standby BGP 105 C-multicast route and accepting traffic from any of both sides. 107 Section 3 describes procedures allowing multi homing ingress PEs to 108 determine "locally" a single forwarder to avoid duplicate packets 109 sending through the backbone, without the egress PEs' primary or 110 standby UMH selection. 112 Section 4 describes an optional BGP Extended Community called 113 "Upstream Forwarder Selection", which is carried by BGP VPN routes 114 (SAFI 128 or 129), to inform the downstream PEs the selection 115 behavior describes in Section 3. 117 Section 5 describes the downstream PEs' behavior in this case. The 118 downstream PEs advertise C-multicast Source Tree Join route to both 119 the primary and secondary Upstream PEs (carrying, as Route Target 120 extended communities, the values of the VRF Route Import Extended 121 Community of each VPN route from each Upstream PE). The Upstream 122 Forwarder Selection Extended Community indicates that the packet 123 duplication prevention will be accomplished by the upstream PEs and 124 that any of the traffic from both the primary and secondary upstream 125 PEs would be acceptable to be forwarded to the CEs. 127 2. Terminology 129 Readers of this document are assumed to be familiar with the 130 terminology and concepts of the documents listed as Normative 131 References. 133 3. Upstream Designated Forwarder Selection 135 Section 9.1.2 of [RFC6513] describes a "single forwarder selection" 136 to ensure that duplicate packets not sending through the backbone. 137 This document proposes a deployment of VRRP or some similar 138 technology to enable dual or multi homing ingress PEs to determine a 139 designated forwarder. 141 3.1. Upstream Designated Forwarder Selection by VRRP 143 VRRP specifies an election protocol that dynamically assigns 144 responsibility for a virtual router to one of the VRRP routers on a 145 LAN. The VRRP router controlling the IPv4 or IPv6 address(es) 146 associated with a virtual router is called the Master, and it 147 forwards packets sent to these IPv4 or IPv6 addresses. Similarly, 148 the role of the VRRP routers associated with a virtual router can 149 also be that of the upstream PEs in MVPN dual homing upstream PEs 150 deployment. 152 Virtual Router -- pair of dual homing upstream PEs 154 Virtual Router Master -- the primary upstream PE 156 Virtual Router Backup -- the standby upstream PE 158 The method of mapping the role of a VRRP router to that of a MVPN 159 upstream PE is more likely an administrative measure and could be 160 implemented as configurable policies. Both the primary and standby 161 PEs install VRF PIM state corresponding to BGP Source Tree Join route 162 and send C-Join messages to the CE toward C-S. Whereas only the 163 primary upstream PE (Virtual Router Master according to VRRP) 164 forwards (C-S,C-G) flow to downstream PEs through a P-tunnel. 166 3.2. Other Feasible Selection Technologies 168 VRRP is just an example of the feasible choices for the dual homing 169 upstream PEs' single forwarder selection. Other private 170 implementations or similar designated forwarder selection 171 technologies could also be optional for further study. However, a 172 feasible technology should has the ability of being deployed per VRF 173 and being associated with one Multicast VPN instance. 175 4. Upstream Forwarder Selection Extended Community 177 This document defines a new BGP Extended Community called "Upstream 178 Forwarder Selection". 180 The Upstream Forwarder Selection is an IP-address-specific Extended 181 Community, of an extended type, and is transitive across AS 182 boundaries [RFC4360]. 184 An upstream PE constructs Upstream Forwarder Selection as follows, 185 regardless of the role of the selection result: 187 The Global Administrator field of the Upstream Forwarder Selection 188 SHOULD be set to a virtual IP address (or similar identity) of the 189 upstream PEs (such as the VRRP Virtual IP address when using 190 VRRP), which is identical between primary and standby PEs. 192 The Local Administrator field of the Upstream Forwarder Selection 193 SHOULD be set to a master or backup status determined by the 194 election which is different between primary and standby PEs. 196 Similar with the carrying of the VRF Route Import Extended Community 197 imposed in Section 7 of [RFC6514], the multi homing PEs MUST also 198 include in the BGP Updates message that carries the (unicast) VPN 199 route the Upstream Forwarder Selection Extended Community that has 200 the value of DF election result associated with this VRF. 202 5. Downstream PE Behavior 204 5.1. Standby C-multicast Route Advertisment 206 The Standby BGP C-multicast route advertisement described in 207 Section 4 of [RFC9026] is still necessary. One downstream PE needs 208 to determine a secondary UMH, originates and sends C-multicast routes 209 with RTs that identify both the Primary and Standby Upstream PEs. 210 However, because of the duplication prevention being accomplished by 211 the upstream DF selection described above, carrying the new Standby 212 PE BGP Communities with C-multicast routes is no longer a 213 indispensable requirement. 215 5.2. Anycast Reverse Path Forwarding Checking 217 Multicast VPN specifications [RFC6513] impose that a downstream PE 218 only forwards to CEs the packets coming from the expected Upstream PE 219 (Section 9.1.1 of [RFC6513]). 221 When performing the UMH selection, if a route in the set of VPN-IP 222 eligible UMH routes carries the Upstream Forwarder Selection Extended 223 Community, the Upstream PE determined from the route should be 224 considered a potentially valid Upstream PE. In most cases, there 225 should be two of that routes for one (C-S,C-G) flow, indicateing the 226 primary and standby upstream PEs. As a result, the downstream PE 227 accepts the (C-S,C-G) flow from any of both sides and forward it to 228 CEs. It is a kind of "anycast" reverse path forwarding (RPF) 229 checking. Eventually, it is the upstream single forwarder selection 230 mechanism that ensures the duplicate packets not passing through the 231 backbone network, as described in Section 3. 233 6. Security Considerations 235 This document introduces no new security considerations beyond those 236 already specified in [RFC6513] and [RFC6514]. 238 7. IANA Considerations 240 This document contains no actions for IANA. 242 8. Acknowledgements 244 The authors wish to thank Jingrong Xie, for his reviews, comments and 245 suggestions. 247 9. Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 255 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 256 February 2006, . 258 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 259 Version 3 for IPv4 and IPv6", RFC 5798, 260 DOI 10.17487/RFC5798, March 2010, 261 . 263 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 264 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 265 2012, . 267 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 268 Encodings and Procedures for Multicast in MPLS/BGP IP 269 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 270 . 272 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 273 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 274 May 2017, . 276 [RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed., 277 "Multicast VPN Fast Upstream Failover", RFC 9026, 278 DOI 10.17487/RFC9026, April 2021, 279 . 281 Authors' Addresses 283 Heng Wang 284 Huawei Technologies 286 Email: wangheng21@huawei.com 288 Fanghong Duan 289 Huawei Technologies 291 Email: duanfanghong@huawei.com