idnits 2.17.1 draft-zzhang-bess-mcast-in-evpn-signaled-l3vpn-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 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 (July 8, 2019) is 1747 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 232, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-prefix-advertisement' is defined on line 238, but no explicit reference was found in the text == Unused Reference: 'I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 266, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-irb-mcast-02 == Outdated reference: A later version (-04) exists of draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01 Summary: 2 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: January 9, 2020 J. Rabadan 6 Nokia 7 July 8, 2019 9 Multicast in L3VPNs Signaled by EVPN SAFI 10 draft-zzhang-bess-mcast-in-evpn-signaled-l3vpn-00 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 January 9, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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. Adapted [RFC6514] Procedures . . . . . . . . . . . . . . 4 65 3. Specifications . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 5.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Terminology 74 It is expected that audience is familiar with EVPN and MVPN concepts 75 and terminologies. For convenience, the following terms are briefly 76 explained. 78 o PMSI: P-Multicast Service Interface - a conceptual interface for a 79 PE to send customer multicast traffic to all or some PEs in the 80 same VPN. 82 o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. 84 o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. 86 o Leaf A-D routes: For explicit leaf tracking purpose. Triggered by 87 S-PMSI A-D routes and targeted at triggering route's originator. 89 o IMET A-D route: Inclusive Multicast Ethernet Tag A-D route. The 90 EVPN equivalent of MVPN Intra-AS I-PMSI A-D route. 92 o SMET A-D route: Selective Multicast Ethernet Tag A-D route. The 93 EVPN equivalent of MVPN Leaf A-D route but unsolicited and 94 untargeted. 96 2. Introduction 98 Traditionally, an L3VPN is signaled with BGP "MPLS-labeled VPN 99 address" SAFI and uses MPLS as provider tunnel as specified in 100 [RFC4364>]. Multicast support in such an L3VPN is specified in 101 [RFC6513] and [RFC6514]. 103 [ietf-bess-evpn-prefix-advertisement] specifies another way of 104 signaling L3VPN via EVPN SAFI Type-5 routes for two reasons: 106 o VXLAN tunnels can be used, either for deployment scenarios where 107 MPLS is not desired or for the purpose of better ECMP hashing. 109 o In an environment where EVPN is already needed for L2VPN, an 110 operator may prefer just using an additional EVPN route type to 111 signal L3VPN routes, instead of using another SAFI. This is 112 especially the case when L3VPN is used to provide inter-DC 113 connection. 115 [ietf-bess-evpn-prefix-advertisement] does not define procedures for 116 multicast. This document provides three options for different 117 deployment scenarios. 119 2.1. Optimized Inter-Subnet Multicast for EVPN 121 If all multicast senders and receivers are in an EVPN domain 122 (including both intra-DC and inter-DC cases), the Optimized Inter- 123 Subnet Multicast (OISM) procedures defined in [ietf-bess-evpn-irb- 124 mcast] is the best and preferred option. The advantages are that no 125 new procedures are needed and Any Source Multicast (ASM) does not 126 need PIM Rendezvous Point (RP) procedures. 128 This does require that, if not all BDs are presented on every PE, 129 then a Supplemental Bridge Domain (SBD) needs to be configured on 130 every PE. Since the "Interface-less IP-VRF-to-IP-VRF Model" defined 131 in Section 4.4.1 of [ietf-bess-evpn-prefix-advertisement] does not 132 use SBD, for multicast purpose it is better to move away from that 133 model. 135 Additionally, in case of inter-DC, the SBD needs be stretched across 136 DCs even if regular BDs are not stretched. If the number of PEs in 137 all DCs becomes very large, segmentation procedures defined in [ietf- 138 bess-evpn-bum-procedures-update] and further enhanced in [zzhang- 139 bess-mvpn-evpn-cmcast-enhancements] can be used. Alternatively, MVPN 140 procedures defined in [RFC6514] can be used/adapted for an L3VPN 141 signaled by EVPN Type-5 routes, as described in the following two 142 sections. 144 2.2. Using [RFC6514] Procedures 146 If the OISM procedure cannot be used for any of the following 147 situations that use L3VPN signaled by EVPN Type-5 routes: 149 o There are senders/receivers not on a BD of an EVPN domain and OISM 150 cannot extend to connect them. 152 o Stretching SBD across a DCI is not desired as described in the 153 previous section. 155 o It's a pure L3VPN scenario, where EVPN does not add any value. 157 MVPN procedures defined in [RFC6514] can be used as is as long as: 159 o The MVPN procedures treat EVPN Type-5 routes the same as routes 160 signaled with "MPLS-labeled VPN address" when it comes to UMH 161 selection. 163 o The EVPN Type-5 routes to C-RP or C-src carry the VRF Route Import 164 Extended Community and Source AS Extended Extended Community. 166 In other words, the only difference is that the routes used for UMH 167 selecion now includes those signaled via EVPN Type-5 routes, and they 168 MUST carry the two ECs mentioned above. The rest of [RFC6514] 169 procedures are unchanged. 171 The EVPN Type-2 signaled IP routes may be used as well, though from 172 MVPN point of view, they're no different from "local" routes 173 associated with IRB interfaces. 175 2.3. Adapted [RFC6514] Procedures 177 Notice that, an operator may have chosen to use EVPN Type-5 routes to 178 signal L3VPN because they wanted to avoid signaling another BGP SAFI. 179 Using [RFC6514] procedures as described in the previous section 180 defeats that purpose because a new MCAST-VPN SAFI has to be used. 182 That can be resolved by adapting the [RFC6514] procedures with EVPN 183 SAFI, as described below. 185 RFC6514 uses 7 route types and only the Source Active route does not 186 already have a corresponding EVPN route type: 188 MVPN EVPN 189 Type Name Type Name 190 ---- ---- ---- ---- 191 1 Intra-AS I-PMSI 3 IMET 192 2 Inter-AS I-PMSI 9 Per-Region I-PMSI 193 3 S-PMSI 10 S-PMSI 194 4 Leaf 11 Leaf 195 5 Source Active TBD Source Active (added in this spec) 196 6 (*,G) C-Multicast 6 SMET 197 7 (S,G) C-Multicast 7 SMET 199 As pointed out in [zzhang-bess-mvpn-evpn-cmcast-enhancements], the 200 MVPN Type-6/7 C-multicast routes don't have leaf tracking semantics 201 while EVPN SMET route has built-in leaf tracking semantics. Both 202 have pros and cons depending on the situation. This document will 203 specify when SMET routes used for MVPN do or do not need leaf 204 tracking semantics and the corresponding procedures. 206 Also as pointed out in [zzhang-bess-mvpn-evpn-cmcast-enhancements], 207 the MVPN Type-6/7 C-multicast routes are targeted while EVPN SMET 208 routes are not. This document specifies that the EVPN SMET routes 209 used for MVPN purpose will be targeted, except in a special case as 210 mentioned in [zzhang-bess-mvpn-evpn-cmcast-enhancements]. 212 With this, the MEG (MVPN/EVPN Gateway) [ietf-bess-evpn-irb-mcast] 213 follows the adaped MVPN procedures as specified in this document 214 instead of the [RFC6514] procedures on MVPN side. 216 Detailed procedures are specified in the following section. 218 3. Specifications 220 Details to be added. 222 4. Security Considerations 224 This document does not introduce new security risks. Whatever 225 security aspects that are applicable to [RFC7432], [RFC6513], 226 [RFC6514] and [ietf-bess-evpn-prefix-advertisement] apply here. 228 5. References 230 5.1. Normative References 232 [I-D.ietf-bess-evpn-irb-mcast] 233 Lin, W., Zhang, Z., Drake, J., Rosen, E., Rabadan, J., and 234 A. Sajassi, "EVPN Optimized Inter-Subnet Multicast (OISM) 235 Forwarding", draft-ietf-bess-evpn-irb-mcast-02 (work in 236 progress), January 2019. 238 [I-D.ietf-bess-evpn-prefix-advertisement] 239 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 240 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 241 bess-evpn-prefix-advertisement-11 (work in progress), May 242 2018. 244 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] 245 Zhang, Z., Kebler, R., Lin, W., and E. Rosen, "MVPN/EVPN 246 C-Multicast Routes Enhancements", draft-zzhang-bess-mvpn- 247 evpn-cmcast-enhancements-01 (work in progress), March 248 2019. 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 256 Encodings and Procedures for Multicast in MPLS/BGP IP 257 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 258 . 260 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 261 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 262 May 2017, . 264 5.2. Informative References 266 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 267 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 268 2006, . 270 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 271 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 272 2012, . 274 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 275 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 276 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 277 2015, . 279 Authors' Addresses 281 Zhaohui Zhang 282 Juniper Networks 284 EMail: zzhang@juniper.net 286 Wen Lin 287 Juniper Networks 289 EMail: wlin@juniper.net 291 Jorge Rabadan 292 Nokia 294 EMail: jorge.rabadan@nokia.com