idnits 2.17.1 draft-zzhang-bess-mcast-in-evpn-signaled-l3vpn-01.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 13, 2020) is 1284 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-bess-evpn-irb-mcast' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-prefix-advertisement' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements' is defined on line 263, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 290, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-irb-mcast-04 == Outdated reference: A later version (-04) exists of draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01 ** Downref: Normative reference to an Historic RFC: RFC 6037 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Z. Zhang 3 Internet-Draft W. Lin 4 Intended status: Standards Track Juniper Networks 5 Expires: April 16, 2021 J. Rabadan 6 Nokia 7 October 13, 2020 9 Multicast in L3VPNs Signaled by EVPN SAFI 10 draft-zzhang-bess-mcast-in-evpn-signaled-l3vpn-01 12 Abstract 14 [ietf-bess-evpn-prefix-advertisement] specifies an EVPN SAFI Type-5 15 route that can be used to signal L3VPNs. This document specifies 16 procedures for multicast in such an L3VPN. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 22 "OPTIONAL" in this document are to be interpreted as described in BCP 23 14 [RFC2119] [RFC8174] when, and only when, they appear in all 24 capitals, as shown here. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 16, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Optimized Inter-Subnet Multicast for EVPN . . . . . . . . 3 63 2.2. Using [RFC6514] Procedures . . . . . . . . . . . . . . . 4 64 2.3. Using [RFC6037] Procedures . . . . . . . . . . . . . . . 4 65 2.4. Adapted [RFC6514] Procedures . . . . . . . . . . . . . . 5 66 3. Specifications . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 5.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Terminology 75 It is expected that audience is familiar with EVPN and MVPN concepts 76 and terminologies. For convenience, the following terms are briefly 77 explained. 79 o PMSI: P-Multicast Service Interface - a conceptual interface for a 80 PE to send customer multicast traffic to all or some PEs in the 81 same VPN. 83 o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. 85 o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. 87 o Leaf A-D routes: For explicit leaf tracking purpose. Triggered by 88 S-PMSI A-D routes and targeted at triggering route's originator. 90 o IMET A-D route: Inclusive Multicast Ethernet Tag A-D route. The 91 EVPN equivalent of MVPN Intra-AS I-PMSI A-D route. 93 o SMET A-D route: Selective Multicast Ethernet Tag A-D route. The 94 EVPN equivalent of MVPN Leaf A-D route but unsolicited and 95 untargeted. 97 2. Introduction 99 Traditionally, an L3VPN is signaled with BGP "MPLS-labeled VPN 100 address" SAFI and uses MPLS as provider tunnel as specified in 101 [RFC4364>]. Multicast support in such an L3VPN is specified in 102 [RFC6513] and [RFC6514]. 104 [ietf-bess-evpn-prefix-advertisement] specifies another way of 105 signaling L3VPN via EVPN SAFI Type-5 routes for two reasons: 107 o VXLAN tunnels can be used, either for deployment scenarios where 108 MPLS is not desired or for the purpose of better ECMP hashing. 110 o In an environment where EVPN is already needed for L2VPN, an 111 operator may prefer just using an additional EVPN route type to 112 signal L3VPN routes, instead of using another SAFI. This is 113 especially the case when L3VPN is used to provide inter-DC 114 connection. 116 [ietf-bess-evpn-prefix-advertisement] does not define procedures for 117 multicast. This document provides three options for different 118 deployment scenarios. 120 2.1. Optimized Inter-Subnet Multicast for EVPN 122 If all multicast senders and receivers are in an EVPN domain 123 (including both intra-DC and inter-DC cases), the Optimized Inter- 124 Subnet Multicast (OISM) procedures defined in [ietf-bess-evpn-irb- 125 mcast] is the best and preferred option. The advantages are that no 126 new procedures are needed and Any Source Multicast (ASM) does not 127 need PIM Rendezvous Point (RP) procedures. 129 This does require that, if not all BDs are presented on every PE, 130 then a Supplemental Bridge Domain (SBD) needs to be configured on 131 every PE. Since the "Interface-less IP-VRF-to-IP-VRF Model" defined 132 in Section 4.4.1 of [ietf-bess-evpn-prefix-advertisement] does not 133 use SBD, for multicast purpose it is better to move away from that 134 model. 136 Additionally, in case of inter-DC, the SBD needs be stretched across 137 DCs even if regular BDs are not stretched. If the number of PEs in 138 all DCs becomes very large, segmentation procedures defined in [ietf- 139 bess-evpn-bum-procedures-update] and further enhanced in [zzhang- 140 bess-mvpn-evpn-cmcast-enhancements] can be used. Alternatively, MVPN 141 procedures defined in [RFC6514] can be used/adapted for an L3VPN 142 signaled by EVPN Type-5 routes, as described in the following two 143 sections. 145 2.2. Using [RFC6514] Procedures 147 If the OISM procedure cannot be used for any of the following 148 situations that use L3VPN signaled by EVPN Type-5 routes: 150 o There are senders/receivers not on a BD of an EVPN domain and OISM 151 cannot extend to connect them. 153 o Stretching SBD across a DCI is not desired as described in the 154 previous section. 156 o It's a pure L3VPN scenario, where EVPN does not add any value. 158 MVPN procedures defined in [RFC6514] (often referred to as BGP-MVPN) 159 can be used as is as long as: 161 o The MVPN procedures treat EVPN Type-5 routes the same as routes 162 signaled with "MPLS-labeled VPN address" when it comes to UMH 163 selection. 165 o The EVPN Type-5 routes to C-RP or C-src carry the VRF Route Import 166 Extended Community and Source AS Extended Extended Community. 168 In other words, the only difference is that the routes used for UMH 169 selection now includes those signaled via EVPN Type-5 routes, and 170 they MUST carry the two ECs mentioned above. The rest of [RFC6514] 171 procedures are unchanged. 173 The EVPN Type-2 signaled IP routes may be used as well, though from 174 MVPN point of view, they're no different from "local" routes 175 associated with IRB interfaces. 177 2.3. Using [RFC6037] Procedures 179 The historic RFC 6037 describes the legacy PIM-based MVPN (often 180 referred to as Rosen/PIM-MVPN). While the BGP-MVPN specified in 181 [RFC6514] is widely used and deemed more scalable and more versatile, 182 the legacy PIM/Rosen-MVPN is still used by some operators, and in 183 case of EVPN-signaled L3VPN, it can also be used, perhaps with little 184 implementation change, especially if PIM-ASM based Multicast 185 Distribution Tree (MDT, or provider tunnel) is appropriate or 186 desired. 188 It must be pointed out that, if PIM-SSM or other types of MDTs are 189 desired, or if Inter-AS MDTs are needed, [RFC6037] requires a MDT 190 SAFI to be used. In that case, the BGP-MVPN approach as discussed in 191 the previous section is recommended (since a new SAFI is needed 192 anyway even with PIM-MVPN in this case). 194 2.4. Adapted [RFC6514] Procedures 196 Notice that, an operator may have chosen to use EVPN Type-5 routes to 197 signal L3VPN because they wanted to avoid signaling another BGP SAFI. 198 Using [RFC6514] procedures as described in the previous section 199 defeats that purpose because a new MCAST-VPN SAFI has to be used. 201 That can be resolved by adapting the [RFC6514] procedures with EVPN 202 SAFI, as described below. 204 RFC6514 uses 7 route types and only the Source Active route does not 205 already have a corresponding EVPN route type: 207 MVPN EVPN 208 Type Name Type Name 209 ---- ---- ---- ---- 210 1 Intra-AS I-PMSI 3 IMET 211 2 Inter-AS I-PMSI 9 Per-Region I-PMSI 212 3 S-PMSI 10 S-PMSI 213 4 Leaf 11 Leaf 214 5 Source Active TBD Source Active (added in this spec) 215 6 (*,G) C-Multicast 6 SMET 216 7 (S,G) C-Multicast 7 SMET 218 As pointed out in [zzhang-bess-mvpn-evpn-cmcast-enhancements], the 219 MVPN Type-6/7 C-multicast routes don't have leaf tracking semantics 220 while EVPN SMET route has built-in leaf tracking semantics. Both 221 have pros and cons depending on the situation. This document will 222 specify when SMET routes used for MVPN do or do not need leaf 223 tracking semantics and the corresponding procedures. 225 Also as pointed out in [zzhang-bess-mvpn-evpn-cmcast-enhancements], 226 the MVPN Type-6/7 C-multicast routes are targeted while EVPN SMET 227 routes are not. This document specifies that the EVPN SMET routes 228 used for MVPN purpose will be targeted, except in a special case as 229 mentioned in [zzhang-bess-mvpn-evpn-cmcast-enhancements]. 231 With this, the MEG (MVPN/EVPN Gateway) [ietf-bess-evpn-irb-mcast] 232 follows the adapted MVPN procedures as specified in this document 233 instead of the [RFC6514] procedures on MVPN side. 235 Detailed procedures are specified in the following section. 237 3. Specifications 239 Details to be added. 241 4. Security Considerations 243 This document does not introduce new security risks. Whatever 244 security aspects that are applicable to [RFC7432], [RFC6513], 245 [RFC6514] and [ietf-bess-evpn-prefix-advertisement] apply here. 247 5. References 249 5.1. Normative References 251 [I-D.ietf-bess-evpn-irb-mcast] 252 Lin, W., Zhang, Z., Drake, J., Rosen, E., Rabadan, J., and 253 A. Sajassi, "EVPN Optimized Inter-Subnet Multicast (OISM) 254 Forwarding", draft-ietf-bess-evpn-irb-mcast-04 (work in 255 progress), October 2019. 257 [I-D.ietf-bess-evpn-prefix-advertisement] 258 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 259 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 260 bess-evpn-prefix-advertisement-11 (work in progress), May 261 2018. 263 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] 264 Zhang, Z., Kebler, R., Lin, W., and E. Rosen, "MVPN/EVPN 265 C-Multicast Routes Enhancements", draft-zzhang-bess-mvpn- 266 evpn-cmcast-enhancements-01 (work in progress), March 267 2019. 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, 271 DOI 10.17487/RFC2119, March 1997, 272 . 274 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 275 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 276 RFC 6037, DOI 10.17487/RFC6037, October 2010, 277 . 279 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 280 Encodings and Procedures for Multicast in MPLS/BGP IP 281 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 282 . 284 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 285 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 286 May 2017, . 288 5.2. Informative References 290 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 291 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 292 2006, . 294 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 295 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 296 2012, . 298 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 299 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 300 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 301 2015, . 303 Authors' Addresses 305 Zhaohui Zhang 306 Juniper Networks 308 EMail: zzhang@juniper.net 310 Wen Lin 311 Juniper Networks 313 EMail: wlin@juniper.net 315 Jorge Rabadan 316 Nokia 318 EMail: jorge.rabadan@nokia.com