idnits 2.17.00 (12 Aug 2021) /tmp/idnits57258/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-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 are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-bess-evpn-igmp-mld-proxy], [RFC6513], [RFC6514]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC6513, but the abstract doesn't seem to directly say this. It does mention RFC6513 though, so this could be OK. -- The draft header indicates that this document updates RFC6514, but the abstract doesn't seem to directly say this. It does mention RFC6514 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6513, updated by this document, for RFC5378 checks: 2005-06-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 11, 2019) is 1160 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) == Missing Reference: 'RFC7432' is mentioned on line 120, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-05 == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-02 == Outdated reference: A later version (-08) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-02 == Outdated reference: draft-ietf-bier-mvpn has been published as RFC 8556 == Outdated reference: A later version (-06) exists of draft-ietf-bess-evpn-irb-mcast-02 == Outdated reference: draft-ietf-bess-mvpn-fast-failover has been published as RFC 9026 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Z. Zhang 3 Internet-Draft R. Kebler 4 Updates: 6513, 6514 (if approved) W. Lin 5 Intended status: Standards Track Juniper Networks 6 Expires: September 12, 2019 E. Rosen 7 March 11, 2019 9 MVPN/EVPN C-Multicast Routes Enhancements 10 draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01 12 Abstract 14 [RFC6513] and [RFC6514] specify procedures for originating, 15 propagating, and processing "C-multicast routes". However, there are 16 a number of MVPN use cases that are not properly or optimally handled 17 by those procedures. This document describes those use cases, and 18 specifies the additional procedures needed to handle them. Some of 19 the additional procedures are also applicable to EVPN SMET routes [I- 20 D.ietf-bess-evpn-igmp-mld-proxy]. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 12, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. MVPN C-Bidir Support with VPN Backbone being RPL . . . . 4 65 1.2.1. C-multicast Routes for the MVPN-RPL Method of C-BIDIR 66 support . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.2.2. Optional use of MVPN-RPL RD with mLDP/PIM Provider 68 Tunnels . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.2.3. MVPN C-ASM Support without CE Routers . . . . . . . . 6 70 1.3. Inter-AS Propagation of MVPN C-Multicast Routes . . . . . 6 71 1.4. MVPN Inter-AS Upstream PE Selection . . . . . . . . . . . 8 72 1.5. EVPN Selective Multicast Ethernet Tag (SMET) Routes . . . 9 73 1.6. Provider Tunnel Segmentation with Explicit-Tracking 74 C-Multicast Routes . . . . . . . . . . . . . . . . . . . 11 75 1.6.1. Conventional Tunnel Segmentation . . . . . . . . . . 11 76 1.6.2. Selective Tunnel Segmentation with Untargeted 77 Explicit-Tracking C-multicast Routes . . . . . . . . 11 78 2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 12 79 2.1. MVPN C-Bidir Support with VPN Backbone being RPL . . . . 12 80 2.1.1. Constructing C-Multicast Share Tree Join route . . . 12 81 2.1.2. Setting Up the MVPN-RPL . . . . . . . . . . . . . . . 13 82 2.2. Inter-AS Propagation of MVPN C-Multicast Routes . . . . . 14 83 2.2.1. Procedures in Section 11.2 of [RFC6514] . . . . . . . 14 84 2.2.2. Ordinary BGP Propagation Procedures . . . . . . . . . 15 85 2.3. Inter-AS Upstream PE Selection . . . . . . . . . . . . . 15 86 2.4. Duplication Prevention on the Same Inclusive Inter-AS 87 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 2.4.1. Using PE Distinguisher Labels . . . . . . . . . . . . 16 89 2.4.2. Ingress ASBR Filtering Out Duplications . . . . . . . 16 90 2.5. Provider Tunnel Segmentation with Explicit-Tracking 91 C-Multicast Routes . . . . . . . . . . . . . . . . . . . 17 92 2.5.1. Egress PEs and RBRs . . . . . . . . . . . . . . . . . 17 93 2.5.2. Transit RBRs . . . . . . . . . . . . . . . . . . . . 19 94 2.5.3. Ingress RBRs . . . . . . . . . . . . . . . . . . . . 19 95 2.5.4. Setting Up Forwarding State on RBRs . . . . . . . . . 20 96 2.5.5. Other Types of Tunnels . . . . . . . . . . . . . . . 20 97 3. Security Considerations . . . . . . . . . . . . . . . . . . . 21 98 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 99 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 5.1. Normative References . . . . . . . . . . . . . . . . . . 21 101 5.2. Informative References . . . . . . . . . . . . . . . . . 22 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 104 1. Introduction 106 [RFC6513] and [RFC6514] specify procedures for originating, 107 propagating, and processing "C-multicast routes". However, there are 108 a number of MVPN use cases that are not properly or optimally handled 109 by those procedures. This document describes those use cases, and 110 specifies the additional procedures needed to handle them. 112 Some of the additional procedures are also applicable to EVPN SMET 113 routes [I-D.ietf-bess-evpn-igmp-mld-proxy]; this is discussed in 114 Section 1.5. 116 1.1. Terminology 118 This document uses terminology from MVPN and EVPN. It is expected 119 that the audience is familiar with the concepts and procedures 120 defined in [RFC6513], [RFC6514], [RFC7524], [RFC7432], [I-D.ietf- 121 bess-evpn-bum-procedure-updates], and [I-D.ietf-bess-evpn-igmp-mld- 122 proxy]. Some terms are listed below for references. 124 o PMSI: P-Multicast Service Interface - a conceptual interface for a 125 PE to send customer multicast traffic to all or some PEs in the 126 same VPN. 128 o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. 130 o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. 132 o C-G-BIDIR: A bidirectional multicast group address (i.e., a group 133 address whose IP multicast distribution tree is built by BIDIR- 134 PIM) in customer address space. 136 o RBR: Regional Border Router. A provider tunnel could be 137 segmented, with one segment in each region. A region could be an 138 AS, an IGP area, or even a subarea. 140 1.2. MVPN C-Bidir Support with VPN Backbone being RPL 142 In BIDIR-PIM [RFC5015], every group is associated with a "Rendezvous 143 Point Link" (RPL). The RPL for a given group G is at the root of the 144 BIDIR-PIM distribution tree. Links of the distribution tree that 145 lead towards the RPL are considered to be "upstream" links, and links 146 that lead away from the RPL are considered to be "downstream" links. 147 Every node on the distribution tree has one upstream link and zero or 148 more downstream links. 150 Data addressed to a BIDIR-PIM group may enter the distribution tree 151 at any node. The entry node sends the data on the upstream links and 152 the downstream links. A node that receives the data from a 153 downstream link sends it on its upstream link and on its other 154 downstream links. A node that receives the data from its upstream 155 link sends it on its downstream links. When a node that is attached 156 to the RPL receives data from a downstream link, it forwards the data 157 onto the RPL (as well as onto any other downstream links.) When node 158 attached to the RPL receives data from the RPL, it forwards the data 159 downstream. 161 The above is a simplified description, and ignores the fact that 162 every link except the RPL has a Designated Forwarder (DF). Only the 163 DF forwards traffic onto the link. However, the RPL has no DF; any 164 node can forward traffic onto the RPL. 166 1.2.1. C-multicast Routes for the MVPN-RPL Method of C-BIDIR support 168 Section 11.1 of [RFC6513] describes a method of providing MVPN 169 support for customers that use BIDIR-PIM. This is known as "MVPN 170 C-BIDIR support". In this method of C-BIDIR support, the VPN 171 backbone itself functions as the RPL. Thus this method is known as 172 the "MVPN-RPL" method. The RPL is actually an I-PMSI or S-PMSI. The 173 PE routers treat the I-PMSI or S-PMSI as their upstream link, and 174 treat their VRF interfaces as downstream links. 176 If the MVPN-RPL method of C-BIDIR support is being used in a 177 particular MVPN, all the PEs attached to that MVPN must be 178 provisioned to use this method. 180 In the context of a given VPN, a PE with interest in receiving a 181 particular C-BIDIR group (call it C-G-BIDIR) advertises this interest 182 to the other PEs by originating a C-multicast Shared Tree Join route. 183 When any PE receives traffic for the C-G-BIDIR on its PE-CE 184 interface, it sends the data to the MVPN-RPL if and only if it has 185 received corresponding (C-*,C-G-BIDIR) C-multicast Shared Tree Join 186 route. Other PEs receive the traffic on the MVPN-RPL and forward to 187 their downstream receivers. However, the procedure for constructing 188 the C-multicast Shared Tree Join route in this case is not fully 189 specified in [RFC6513] or [RFC6514]. The proper set of procedures 190 are specified in Section 2.1.1 of this document. 192 Compared to other C-Multicast routes specified in [RFC6514], these 193 are "untargeted" in that the RT allows all PEs in the same MVPN to 194 import them, while those other C-Multicast routes use a RT that 195 identifies a VRF on a particular Upstream Multicast Hop (UMH) PE. 197 If a PE wants to use selective tunnel to send traffic to only a 198 subset of the PEs on MVPN-RPL, i.e., those with downstream 199 (C-*,C-G-BIDIR) state, per [RFC6513] [RFC6514] the PE needs to 200 advertise a corresponding (C-*,C-G-BIDIR) S-PMSI A-D route, whose PTA 201 specifies the tunnel to be used. In case of RSVP-TE P2MP, Ingress 202 Replication (IR), or BIER tunnel, the Leaf Information Required (LIR) 203 bit in the S-PMSI route's PTA is set to solicit corresponding Leaf 204 A-D routes from those PEs with downstream (C-*,C-G-BIDIR) state. 205 Every PE that wants to use selective tunnel for the (C-*,C-G-BIDIR) 206 will advertise its own S-PMSI A-D route, each triggering a set of 207 corresponding Leaf A-D routes. 209 Notice that the (C-*,C-G-BIDIR) C-Multicast routes from different PEs 210 all have their own RDs so Route Reflectors (RRs) will reflect every 211 one of them, and they already serve explicit tracking purpose (the 212 BGP Next Hop identifies the originator of the route in non- 213 segmentation case) - there is no need to use Leaf A-D routes 214 triggered by the LIR bit in S-PMSI A-D routes. In case of RSVP-TE 215 P2MP tunnel, the S-PMSI A-D routes are still needed to announce the 216 tunnel but the LIR bit does not need to be set. In case of IR/BIER, 217 there is no need for S-PMSI A-D routes at all. 219 1.2.2. Optional use of MVPN-RPL RD with mLDP/PIM Provider Tunnels 221 When mLDP/PIM tunnels are used, there is no need for explicit 222 tracking as the leaves will simply send mLDP label Mapping or PIM 223 Join messages. As a result, it's unnecessary for a PE to retain each 224 C-Multicast route from each PE for the same C-G-BIDIR. If there is a 225 Route Reflector (RR) in use, and it is known apriori that all the 226 PEs/RRs/ASBRs involved in the propagation of the C-Multicast routes 227 support BGP ADD-PATH [RFC7911], then the PEs could use a common RD to 228 construct the C-Multicast routes. That way, the routes from 229 different PEs for the same C-G-BIDIR will be considered paths for the 230 same route and the RRs will reflect N paths to each PE. If N is 231 significantly smaller than the number of PEs that advertises the 232 routes, then the burden is significantly reduced for the PEs. 234 The reason for the need for ADD-PATH is shown with this example: both 235 PE1 and PE2 advertise the same (C-*,C-G-BIDIR) C-Multicast route and 236 the RR chooses the one from PE1 as the active path. Without ADD- 237 PATH, the RR won't reflect any (C-*,C-G-BIDIR) path back to PE1, 238 causing PE1 to think there is no other PE interested in receiving the 239 C-G-BIDIR traffic. With ADD-PATH, it is guaranteed that even the 240 originator of the active path will receive at least one other path. 241 For this reason, ADD-PATH is needed and N=2 is well enough. 243 1.2.3. MVPN C-ASM Support without CE Routers 245 Current MVPN specifications is based on the fact that CEs are routers 246 and in case of ASM one or more of the routers in customer address 247 space, which could be a CE, a PE's VRF, or another non-PE/CE router, 248 serves as RP. Traffic may be delivered on shared trees, switch to 249 source specific trees, or switch back to shared trees depending the 250 situation. There are two modes of MVPN to support ASM, all involving 251 (C-S,C-G) MVPN Source Active (SA) A-D routes, individual (C-S,C-G) 252 control/forwarding plane state and procedures that are not needed for 253 a special scenario where CEs are not routers but just hosts. 255 From a logical point of view, this special scenario is when a VPN 256 only involves customer networks directly connected to the PEs and no 257 customer routers are used.. A practical example is EVPN inter-subnet 258 multicast [I-D.ietf-bess-evpn-irb-mcast], when EVPN is used to 259 connect only servers and no customer routers are involved. In this 260 case, it does not make sense to introduce the RP concept into the 261 deployment and involve the MVPN SA procedures. Rather, this could be 262 modeled as C-Bidir with MVPN-RPL and all the above discussed 263 optimizations apply. 265 1.3. Inter-AS Propagation of MVPN C-Multicast Routes 267 Section 11.2 of [RFC6514] specifies the procedure used to propagate 268 C-multicast routes from one AS to another. However, there are a 269 number of problems with the procedures as specified in that RFC. 271 RFC6514 presumes that C-multicast routes are propagated through the 272 ASBRs. This is analogous to RFC 4364's "Inter-AS option b". 273 However, in some deployment scenarios, the C-multicast routes are 274 propagated through Route Reflectors, in a manner analogous to RFC 275 4364's "Inter-AS option c". Strictly speaking, RFC 6514 does not 276 allow this deployment scenario. This document updates RFC 6514 by 277 allowing this deployment scenario to be used in place of the 278 procedures of Section 11.2 of RFC 6514. 280 In some deployment scenarios, the propagation of C-multicast routes 281 is controlled by the "Route Target Constraint" procedures of 282 [RFC4684]. Strictly speaking, RFC 6514 does not allow this 283 deployment scenario. This document updates RFC 6514 by allowing this 284 deployment scenario to be used in place of the procedures of 285 Section 11.2 of RFC 6514. 287 Per [RFC6514], an MVPN C-Multicast route is targeted at a particular 288 PE, and its inter-as propagation towards the PE follows a series of 289 ASBRs (in the reverse order) on the propagation path of one of the 290 following: 292 o The Intra-AS I-PMSI A-D route from the targeted PE, if the 293 deployment is using non-segmented tunnels. In this scenario, the 294 IP address of the targeted PE is encoded into the four-octet 295 "Source AS" field (!) of the C-multicast route's NLRI. 297 o The Inter-AS I-PMSI A-D route for the AS that the targeted PE is 298 in, if the deployment is using segmented tunnel. In this 299 scenario, the AS number of the source PE is encoded into the 300 "Source AS" field of the C-multicast route's NLRI. 302 In both cases, the corresponding I-PMSI A-D route is found by looking 303 for an I-PMSI A-D route whose NLRI consists of the C-multicast 304 route's RD prepended to the contents of the C-multicast route's 305 "Source AS" field. If neither Inter-AS nor Intra-AS I-PMSI A-D route 306 is used, e.g. (C-*,C-*) S-PMSI A-D route is used, then the specified 307 procedure will not work. 309 It must be noted that the RFC 6514 Section 11.2 propagation 310 procedures cannot be applied to untargeted C-multicast routes, and 311 cannot be applied even to targeted C-multicast routes if the 312 infrastructure is based on IPv6 rather than IPv4. 314 This document updates RFC 6514 by declaring that the procedure of 315 Section 11.2 of that document is only applicable in the case that (1) 316 the C-multicast routes are being propagated through the ASBRs, AND 317 (2) the propagation of those routes is not under the control of the 318 Route Target Constraint procedures. It also updates the procedures 319 of Section 11.2 of [RFC6514] to allow it to work without relying on 320 I-PMSI A-D routes, whether IPv4 or IPv6 infrastructure is used. 322 This document also updates RFC 6514 by declaring that C-multicast 323 routes MAY be propagated using ordinary BGP propagation procedures, 324 which do not rely on the presence of I-PMSI A-D routes. For targeted 325 C-multicast routes, this will result in a less optimal propagation 326 path, but it does work in all cases. The Route Target Constraint 327 procedures can always be used to obtain a more optimal path. 329 The selection of the propagation procedure for C-multicast routes is 330 determined by provisioning. 332 In Section 1.2.1, the explicit tracking using C-multicast route 333 relies on that the route's next hop is not changed so that the next 334 hop can identify the originator. If the c-multicast routes are 335 propagated through ASBRs, the next hop will be changed. With tunnel 336 segmentation, this is not a problem (see Section 1.6) but if non- 337 segmented tunnels are used, either the C-multicast route propagation 338 must follow the Option C procedures and the next hop is not changed 339 by the RRs, or the routes must carry an EC to identify the 340 originator. Or, the RD of a C-multicast route can be used to locate 341 an I/S-PMSI route from the same PE, in which the Originator IP 342 Address can be found. 344 1.4. MVPN Inter-AS Upstream PE Selection 346 Consider the following scenario: 348 A multicast source is multi-homed to PE1 and PE2 in the same source 349 AS1. ASBR1 in AS1 connects to ASBR2 in another AS2. In AS2, egress 350 PE3 selects PE1 while egress PE4 selects PE2 as their upstream PE 351 respectively, because they use the "Installed UMH Route" as the 352 "Selected UMH Route" (as defined in Section 5.1.3 of [RFC6513]). 354 Suppose inter-as tunnel segmentation is used. Following 355 Section 11.1.3 of [RFC6514], PE3 and PE4 will construct their 356 C-multicast routes with the same NLRI key (in particular with the 357 same RD from the Inter-AS I-PMSI A-D route originated by ASBR1) but 358 with one different Route Target - PE3's C-multicast route carries the 359 RT corresponding to PE1's VRF while PE4's C-multicast route carries 360 the RT corresponding to PE2's VRF. ASBR2 will re-advertise only one 361 of the two C-multicast routes to ASBR1. Assuming it is the one with 362 a RT corresponding to PE1, then only PE1 will transmit corresponding 363 traffic. 365 If selective tunnels are used, PE4 that chooses PE2 as the upstream 366 PE will not join the selective tunnel advertised by PE1 so it will 367 not receive traffic. 369 With the new method for inter-as propagation of C-multicast routes 370 described in the previous section, this traffic blackholing problem 371 can be resolved if PE3 and PE4 construct their C-multicast routes 372 with different RDs, e.g. with the RD from the chosen UMH route 373 instead of the RD from the Inter-AS I-PMSI A-D route. That way, PE1 374 will receive the C-multicast route from PE3 and PE2 will receive the 375 C-multicast route from PE4. Both will transmit traffic but PE3 and 376 PE4 will only receive the traffic via the selective tunnel that they 377 join hence no duplication or blackholing. 379 Notice that this also removes the pre-requisite in Section 4.4 of 380 [I-D.ietf-bess-mvpn-fast-failover]. 382 However, there are still two problems. First, while there is no 383 duplication or blackholing issue when selective tunnels are used, two 384 copies of traffic are sent inter-AS, possibly through many common 385 paths before reaching the egress PEs (imagine that there are a string 386 of ASes between AS1 and AS2). This is not an efficient use of inter- 387 AS resources. 389 Choosing upstream PE based on installed UMH route allows different 390 egress PEs to choose different upstream PEs (typically the closest 391 upstream PE), so it is desired for certain intra-as deployment 392 scenarios but apparently it is not desired for PEs in other ASes to 393 choose different upstream PEs. This problem can actually be solved 394 if PEs always do "Single Forwarder Selection" (the default method 395 described in Section 5.1.3 of [RFC6513]) for sources in other ASes 396 while (if provisioned so) selecting upstream PE based on installed 397 UMH routes for sources in the local AS. 399 The second problem is that, when inclusive inter-as tunnels are used, 400 if both PE1 and PE2 send the same traffic, ASBR1 will inject 401 duplicate traffic into the same inter-as tunnel, while PE3 and PE4 402 has no way to distinguish the source PE of each copy. 404 There are two solutions to the second problem. The first solution is 405 that ASBRs advertise PE Distinguisher (PED) labels (Section 8 of 406 [RFC6514]) via a PED attribute attached to their Inter-AS I-PMSI A-D 407 routes, and push a label that identifies the ingress PE when it sends 408 a packet into the inclusive inter-AS tunnel, and an egress PE 409 discards traffic not from its chosen upstream PE. 411 The other solution is for the ingress ASBR to only accept traffic 412 from one ingress PE and forward into the inclusive inter-as tunnel. 413 This does not require egress PEs to discard traffic based on an 414 additional PED label, but does require the ingress ASBR to 415 participate upstream PE selection and do IP forwarding in a VRF for 416 the source VPN, so that it can choose the copy to accept and forward. 417 Because it may not have local receivers, it needs to receive 418 C-multicast routes from egress PEs who will receive corresponding 419 traffic from it, and import the routes into its local VRF. 421 1.5. EVPN Selective Multicast Ethernet Tag (SMET) Routes 423 [I-D.ietf-bess-evpn-igmp-mld-proxy] defines a new EVPN route type 424 known as an "SMET route". 426 The EVPN SMET routes are analogous to the MVPN C-muilticast routes, 427 in that both type of routes are used to disseminate the information 428 that a particular egress PE has interest in a particular multicast 429 C-flow or set of C-flows. 431 An EVPN SMET route contains, in its NLRI, the RD associated with the 432 VRF from which the SMET route was originated. In addition, it is 433 disseminated to all PEs of a given EVI. In this way, SMET routes are 434 analogous to the MVPN C-multicast routes that are used for C-BIDIR 435 support. 437 An EVPN SMET route contains, in its NLRI, the IP address of the 438 originating PE. In this way, they are analogous to the MVPN Leaf A-D 439 routes (They really combine the function of the MVPN C-multicast 440 routes and the MVPN Leaf A-D routes). Similarly, they are also 441 analogous to the C-multicast route for MVPN-RPL that carries an EC 442 that identifies the originating PE. 444 In EVPN, as in MVPN, explicit tracking is required when selective 445 tunnels are realized using IR, BIER, or RSVP-TE P2MP. The EVPN SMET 446 routes provide this explicit tracking, so in these cases EVPN does 447 not need explicit Leaf A-D routes. With IR/BIER, there is no need 448 for S-PMSI route either. However, when SMET routes are used with 449 segmented IR/BIER tunnels, more procedures are needed, just like the 450 C-multicast route in MVPN-RPL case (Section 1.6). For that reason, 451 given the similarity between SMET and C-Multicast routes, in this 452 document we will use the same term C-Multicast route for EVPN SMET 453 route as well. The two may be used interchangeably in case of EVPN. 455 If selective tunnels are set up using procedures that do not require 456 explicit tracking, e.g. mLDP or PIM, the following optimization could 457 be done, similar to MVPN-RPL with mLDP/PIM tunnels (Section 1.2.2): 459 o When constructing an SMET route, put 0 as the Originator Router 460 Address. 462 o When constructing an SMET route in the context of a given EVI, 463 have all PEs of that EVI set the RD field of the NLRI to the same 464 value (This is analogous to "MVPN-RPL RD" discussed in 465 Section 1.2.2). 467 o When a Route Reflector distributes the SMET routes, it uses BGP 468 ADD-PATH to distribute at least two "paths" for a given NLRI. 470 1.6. Provider Tunnel Segmentation with Explicit-Tracking C-Multicast 471 Routes 473 For the above MVPN-RPL and EVPN cases where C-multicast routes are 474 used for explicit tracking without requiring corresponding S-PMSI A-D 475 routes in case of IR/BIER selective tunnel, it works well when there 476 is no tunnel segmentation. With tunnel segmentation [RFC6514] 477 [RFC7524], [I-D.ietf-bess-evpn-bum-procedure-updates] additional 478 procedures are needed. 480 1.6.1. Conventional Tunnel Segmentation 482 Multicast forwarding needs to follow a rooted tree. With 483 segmentation, the tree is divided into segments, with each segment 484 rooted at either the ingress PE or a Regional Border Router (RBR). A 485 segment is contained in a region, which could be an AS, an area, or a 486 sub-area. The root of a segment only needs to track the leaves in 487 its region, which are PEs or RBRs in that region. With the 488 traditional PMSI/Leaf A-D procedures, an ingress PE/RBR sends out an 489 I/S-PMSI route, propagated by RBRs (segmentation points), who change 490 the tunnel identifier along the way to identify the tunnels for their 491 segments. The Leaf A-D routes from PEs are not propagated by the 492 RBRs. Rather, a RBR will proxy the Leaf AD routes it receives from 493 its downstream towards its upstream RBR or PE, following the I/S-PMSI 494 A-D routes received in the upstream region, as specified in [RFC6514] 495 [RFC7524] [I-D.ietf-bess-evpn-bum-procedure-updates]. 497 1.6.2. Selective Tunnel Segmentation with Untargeted Explicit-Tracking 498 C-multicast Routes 500 Without segmentation, the untargeted explicit-tracking C-Multicast 501 routes are sent to every PE, and each PE adds the originator of the 502 routes as leaves of the tunnel rooted at the PE. 504 With segmentation, untargeted explicit-tracking C-Multicast routes 505 are propagated through segmentation points towards all ingress PEs or 506 ASes and are merged along the way. This is like the traditional 507 PMSI/Leaf A-D procedures but with one difference. 509 With the traditional PMSI/Leaf A-D procedures, the propagation is 510 towards the originator of the PMSI A-D route and a single tree is 511 formed. With untargeted C-Multicast routes, multiple trees are 512 formed, each being rooted at the ingress PE (if per-region 513 aggregation [I-D.ietf-bess-evpn-bum-procedure-updates] is not used) 514 or ingress RBR (if per-region aggregation is used). The roots of 515 those trees are either the ingress PEs or the ingress RBRs, 516 identified by all the per-PE or per-region I-PMSI A-D routes. 518 To form those multiple trees without requiring S-PMSI A-D routes from 519 the ingress PEs/RBRs, this document proposes that the RBRs convert a 520 C-multicast route originated in its own region to Leaf A-D routes, as 521 if corresponding S-PMSI A-D routes had been received from ingress 522 PEs/RBRs. The details are provided in Section 2.2. 524 2. Specifications 526 This section provides detailed specifications for the optional 527 enhancements introduced above. 529 2.1. MVPN C-Bidir Support with VPN Backbone being RPL 531 2.1.1. Constructing C-Multicast Share Tree Join route 533 In the context of a particular VRF, a PE with downstream state for 534 the group C-G-BIDIR originates a C-multicast Shared Tree Join route, 535 referred to as "MVPN-RPL C-multicast Join", when the MVPN-RPL method 536 of C-BIDIR support is being used. 538 The fields of the route are set as follows: 540 o RD: See Section 2.1.1.2. 542 o Source AS: set to zero. 544 o Multicast Source Length: 4 or 16. 546 o Multicast Source: set to RPA. 548 o Multicast Group Length: 4 or 16. 550 o Multicast Group: BIDIR-PIM group address. 552 Note that the RD field, and the Route Targets that are attached to 553 the C-multicast route are different than what is specified in 554 [RFC6514]. See following two sections. 556 2.1.1.1. Setting the Route Targets 558 Per [RFC6514], when a PE originates a C-multicast route, it "targets" 559 the route to a specific one of the other PEs attached to the same 560 VPN. The IP address of the targeted PE is encoded into a Route 561 Target and attached to the C-mulitcast route. This ensures that the 562 C-multicast route is processed only by the PE to which it is 563 targeted. 565 However, C-multicast routes used by the MVPN-RPL method are not 566 targeted. Rather, they must be processed by all the other PEs 567 attached to the same MVPN. Thus we refer to these routes as 568 "untargeted". The Route Targets attached to these routes must be 569 such as to cause the routes to be propagated to all the other PEs of 570 the given MVPN. By default, these will be the same Route Targets 571 that are attached to the I-PMSI A-D routes of the MVPN. 573 2.1.1.2. Setting the Route Distinguisher 575 Per [RFC6514], the RD in a C-multicast Join Route is the RD of a VRF 576 on the PE to which the route is targeted. However, in an MVPN-RPL 577 C-multicast Join, the RD is set differently. 579 If PIM/mLDP provider tunnels are used, and it is known that all the 580 PEs/RRs/ASBRs involved in the propagation of C-multicast routes 581 support BGP ADD-PATH, the RD MAY be set to a value that is specially 582 configured to be used as the RD for MVPN-RPL in a given VPN. Call 583 this the "MVPN-RPL" RD for that VPN. In that case, all the 584 C-multicast Joins that are providing C-BIDIR support (for a given 585 VPN) using the MVPN-RPL method will have the same RD. This MVPN-RPL 586 RD of a given VPN MUST NOT be used for any other purpose, or by any 587 other VPN. See Section 1.2.2 for a discussion of when it may be 588 advantageous to use an MVPN-RPL RD. 590 For other provider tunnel types, or if the above mentioned MVPN-RPL 591 RD in case of PIM/mLDP tunnel is not feasible (e.g. BGP ADD-PATH is 592 not supported), the RD in the C-multicast route is that of the VRF 593 from which the route is originated. 595 For Global Table Multicast (GTM) using MVPN procedures [RFC7716], RFC 596 7716 specifies that MVPN routes use a special 0:0 RD. This document 597 specifies that GTM use non-0:0 RDs for C-Multicast routes for 598 C-Bidir, when the backbone is used as RPL and provider tunnels are 599 not set up by PIM/mLDP. 601 2.1.2. Setting Up the MVPN-RPL 603 By default, the I-PMSI or (C-*,C-BIDIR) S-PMSI plays the role of 604 MVPN-RPL. When (C-*,C-G-BIDIR) S-PMSI is used for a particular 605 C-G-BIDIR, the following procedures are followed, depending on the 606 type of provider tunnel used. 608 2.1.2.1. Ingress Replication or BIER 610 If Ingress Replication or BIER is used, there is no need for the 611 ingress PE to advertise (C-*,C-G-BIDIR) S-PMSI A-D route. The 612 ingress PE identifies the tunnel leaves to send traffic to by the 613 C-multicast routes it receives, because each such route has a 614 different RD and serves explicit tracking purpose. In case of IR, 615 the label in the Intra-AS I-PMSI A-D route or (C-*,C-*) S-PMSI A-D 616 route from a leaf is used to send traffic to the leaf. In case of 617 BIER, the label in the same route from the ingress PE is used to send 618 traffic. 620 2.1.2.2. RSVP-TE P2MP 622 With RSVP-TE P2MP tunnel, the ingress PE advertises (C-*,C-G-BIDIR) 623 S-PMSI A-D route without setting the LIR bit in the route's PTA. It 624 identifies the tunnel leaves from the C-multicast routes it receives. 626 2.1.2.3. PIM/mLDP 628 With PIM or mLDP P2MP provider tunnel, procedures in [RFC6514] are 629 followed. 631 2.2. Inter-AS Propagation of MVPN C-Multicast Routes 633 This specification allows two methods of Inter-AS propagation for 634 MVPN C-multicast routes. The choice of which method is used is by 635 provisioning. 637 2.2.1. Procedures in Section 11.2 of [RFC6514] 639 The procedures in Section 11.2 of [RFC6514] are extended with the 640 following. 642 The Source AS field in the NLRI of C-multicast route is set to the AS 643 number of the UMH PE if and only if segmented inter-AS tunnels and 644 per-AS aggregation (via Inter-AS I-PMSI A-D routes) are used. The 645 existing procedures are used as is in this case. 647 Otherwise, when an egress PE constructs a C-Multicast route and the 648 upstream PE is in a different AS from the local PE, it finds in its 649 VRF an Intra-AS I-PMSI A-D route or any S-PMSI A-D route from the 650 upstream PE (the Originating Router's IP Address field of that route 651 has the same value as the one carried in the VRF Route Import of the 652 (unicast) route to the address carried in the Multicast Source 653 field). The RD of the found I/S-PMSI A-D route is used as the RD of 654 the advertised C-multicast route. The Source AS field in the 655 C-multicast route is set to 0. If the Next Hop of the found I/S-PMSI 656 A-D route is an EBGP neighbor of the local PE, then the PE advertises 657 the C- multicast route to that neighbor. Otherwise the PE advertises 658 the C-multicast route into IBGP. 660 When an ASBR receives a C-multicast route with the Source AS field 661 set to 0, it uses the RD of the C-multicast route to locate an Intra- 662 AS I-PMSI A-D route or any S-PMSI A-D route, and propagate the 663 C-multicast route to the bgp neighbor from which the found I/S-PMSI 664 A-D route is learned. 666 2.2.2. Ordinary BGP Propagation Procedures 668 This document specifies that C-multicast routes MAY be propagated 669 using ordinary BGP propagation procedures, which do not rely on the 670 presence of any I/S-PMSI A-D routes. With this method, the 671 construction of C-Multicast A-D routes always follows the same 672 procedures, whether the source is in the same or different AS. 673 Specifically, the 3rd and 5th paragraphs of Section 11.1.3 of 674 [RFC6514] are quoted here: 676 ---------------------------------------------------------------------- 677 From the selected UMH route, the local PE extracts (a) the ASN of the 678 upstream PE (as carried in the Source AS Extended Community of the 679 route), and (b) the C-multicast Import RT of the VRF on the upstream 680 PE (the value of this C-multicast Import RT is the value of the VRF 681 Route Import Extended Community carried by the route). The Source AS 682 field in the C-multicast route is set to that AS. The Route Target 683 Extended Community of the C-multicast route is set to that 684 C-multicast Import RT. 686 ... 688 ... the RD of 689 the advertised MCAST-VPN NLRI is set to the RD of the VPN-IP route 690 that contains the address carried in the Multicast Source field. 691 ---------------------------------------------------------------------- 693 For targeted C-multicast routes, this will result in a less optimal 694 propagation path, but it does work in all cases. The Route Target 695 Constraint procedures can always be used to obtain a more optimal 696 path. 698 2.3. Inter-AS Upstream PE Selection 700 This document allows that, when selecting upstream PE for a source 701 not in the local AS, the Single Forwarder Selection method, i.e., the 702 default procedure in Section 5.1.3 of [RFC6513] is used, even if the 703 method of using the installed UMH route as the selected UMH route is 704 provisioned (to be used for sources in the local AS only). 706 2.4. Duplication Prevention on the Same Inclusive Inter-AS Tunnel 708 The procedures in this section are only applicable when inclusive 709 inter-AS tunnels advertised in Inter-AS I-PMSI A-D routes are used 710 and it is known that an ingress ASBR may receive duplicate traffic 711 from different ingress PEs in the same local AS. One of the 712 following two methods is provisioned consistently on all PEs and 713 ingress ASBRs of a VPN. 715 2.4.1. Using PE Distinguisher Labels 717 With this method, an ingress ASBR that may receive duplicate traffic 718 from different PEs and inject into the same inclusive inter-AS 719 tunnels use a PED label to identify the upstream PE of the traffic, 720 so that egress PEs can discard traffic not from their selected 721 upstream PE. 723 When an ASBR advertises an Inter-AS I-PMSI A-D route, it includes a 724 PE Distinguisher (PED) Labels attribute [RFC6514]. The attribute 725 lists one label for each PE in the corresponding AS, and the labels 726 are allocated from a Domain-wide Common Block (DCB, 727 [I-D.ietf-bess-mvpn-evpn-aggregation-label]). When an ingress ASBR 728 forwards traffic it receives from a local ingress PE, it needs to 729 push the label assigned to the ingress PE and advertised in the PED 730 attribute of corresponding Inter-AS I-PMSI A-D route. Because the 731 labels are assigned from the DCB, they do not need to be swapped 732 along the way. Downstream and upstream assigned labels could be used 733 as well, but that requires the ASBRs swap PED labels along the way 734 (in addition to tunnel label swapping) so they are not discussed 735 here. 737 Note that if intra-AS tunnel aggregation is used in the ingress AS, 738 the ingress PE SHOULD use the same PED label and the ingress ASBR 739 MUST NOT push the PED label again when forwarding traffic into the 740 inclusive inter-as tunnel. 742 2.4.2. Ingress ASBR Filtering Out Duplications 744 With this method, an ingress ASBR performs IP forwarding for traffic 745 that goes onto inclusive tunnels 746 [I-D.zzhang-bess-mvpn-evpn-segmented-forwarding] after discarding 747 traffic not from the upstream PE that it chooses. 749 The ingress ASBR MUST be provisioned with a VRF for each VPN with 750 local PEs, and with a C-multicast Import RT for the VRF. The Inter- 751 AS I-PMSI A-D route that it advertises for the VPN MUST carry a VRF 752 Route Import Extended Community (EC) that has the value of the 753 C-multicast Import RT for the VRF. This is similar to that a PE 754 includes a VRF Route Import EC in VPN-IP routes that it originates. 756 When an egress PE constructs a C-multicast routes, if the source is 757 in a different AS, the ingress ASBR that advertises the Inter-AS 758 I-PMSI A-D rotue installed by this egress PE is chosen as the 759 upstream PE. The RD and AS number in the Inter-AS I-PMSI A-D route 760 are used to construct the C-multicast route, and a C-multicast Import 761 RT (for importing the constructed C-multicast route into the ingress 762 ASBR's VRF) is included, with the value of this RT being the value of 763 the VRF Route Import EC carried by the Inter-AS I-PMSI A-D route. 765 When an ingress ASBR receives a C-multicast route and imports the 766 route into one of its local VRFs (because of the RT constructed as 767 above), it treats as if a PIM/IGMP join was received on the inter-AS 768 inclusive tunnel. It selects its own upstream PE and originates a 769 corresponding C-multicast route. Corresponding traffic received from 770 the selected upstream PE is then routed into the inter-AS inclusive 771 tunnel. 773 2.5. Provider Tunnel Segmentation with Explicit-Tracking C-Multicast 774 Routes 776 This section applies when IR/BIER are used for MVPN/EVPN selective 777 tunnels. 779 If per-region aggregation [I-D.ietf-bess-evpn-bum-procedure-updates] 780 is used, this document specifies that the per-region I-PMSI A-D route 781 MUST carry a VRF Route Import EC to identify the originator of the 782 per-region I-PMSI A-D route. Note that, while it borrows "VRF Route 783 Import EC" from the UMH routes, it is only used to identify the 784 originator. 786 If per-region aggregation is not used, this document specifies that 787 either per-PE I-PMSI or (C-*,C-*) S-PMSI A-D routes MUST be 788 originated by every PE. 790 2.5.1. Egress PEs and RBRs 792 An egress PE originates MVPN C-multicast routes for MVPN-RPL as 793 specified in previous sections of this document, or EVPN SMET routes 794 as specified in [I-D.ietf-bess-evpn-igmp-mld-proxy]. Recall that 795 EVPN SMET routes may also be referred to C-Multicast routes in this 796 document. 798 Explicit-tracking C-multicast routes must be processed by 799 segmentation points, which are referred to as RBRs. When a RBR 800 receives a C-multicast route from within its own region, and the 801 route does not carry a flag bit that indicates the route is converted 802 from a downstream Leaf A-D route (see descriptions below), it 803 converts the C-multicat route into one or more Leaf A-D routes, as if 804 it had received corresponding S-PMSI A-D routes. When a converted 805 Leaf A-D routes reaches the ingress region, the RBR converts it back 806 to C-multicast routes. 808 With per-region aggregation, the RBR in an egress region finds all 809 active per-region I-PMSI A-D route that the RBR has in the 810 corresponding VRF. For each of them, it makes up a (C-S,C-G) or 811 (C-*,C-G) S-PMSI A-D route as following. 813 o RD: set to the RD from the per-region I-PMSI A-D route. 815 o Source/Group length/address fields: set according to the received 816 C-multicast route. 818 o Originator's IP Address: set according to the VRF Route Import EC 819 in the per-region I-PMSI A-D route 821 o Ethernet Tag ID in case of EVPN: set according to the received 822 SMET route (which is also referred to as C-multicast route). 824 o Next Hop: set according to the per-region I-PMSI A-D route. 826 Without per-region aggregation, a RBR finds all active per-PE I-PMSI 827 or (C-*,C-*) S-PMSI A-D route in the VRF. For each of them it makes 828 up a (C-S,C-G) or (C-*,C-G) S-PMSI A-D route similar to the per- 829 region aggregation case. The only difference is that the 830 Originator's IP Address field is set to the same as in the per-PE 831 I-PMSI or (C-*,C-*) S-PMSI A-D route. 833 A corresponding Leaf A-D route is then generated and propagated to 834 the upstream identified by the BGP next hop in the made up S-PMSI A-D 835 route, following existing PMSI/Leaf A-D route procedures. 837 If the egress region uses Ingress Replication, the made up S-PMSI A-D 838 route is not propagated anywhere. If the egress region uses PIM or 839 RSVP-TE/mLDP P2MP tunnel, the S-PMSI A-D route is advertised into the 840 egress region to announce the tunnel to be used. If the egress 841 region uses BIER or aggregated RSVP-TE/mLDP P2MP tunnel, the S-PMSI 842 A-D route is also advertised into the egress region and carry an 843 upstream allocated label. The label may be at the per S-PMSI A-D 844 route level or at per VPN/BD level. In the former case, label 845 switching at the RBR can be used. In the latter case, IP lookup in 846 the corresponding VRF or BD is needed. 848 2.5.2. Transit RBRs 850 When an upstream RBR receives a (C-S,C-G) or (C-*,C-G) Leaf A-D 851 route, It locates the active per-PE/region I-PMSI or (C-*,C-*) S-PMSI 852 A-D route whose RD matches the received Leaf A-D route. If no such 853 route exists, the received Leaf A-D route is ignored until such a 854 route appears later. It also tries to locate a corresponding active 855 (C-S,C-G) or (C-*,C-G) S-PMSI A-D route, which could be a real one 856 received from an upstream PE/RBR, or could be a made up one triggered 857 by a Leaf A-D route from a different downstream. If such route 858 exists, existing PMSI/Leaf A-D route procedures are followed. 860 If no such corresponding active (C-S,C-G) or (C-*,C-G) S-PMSI A-D 861 route exists, and the located active I-PMSI or (C-*,C-*) S-PMSI A-D 862 route has a next hop different from the Originator IP Address in the 863 per-PE I-PMSI A-D route or (C-*,C-*) I-PMSI A-D route, or different 864 from the address in the VRF Route Import EC in the per-region I-PMSI 865 A-D route, the ingress region corresponding to the I-PMSI or 866 (C-*,C-*) S-PMSI A-D route has not been reached. The RBR then makes 867 up a (C-S,C-G) or (C-*,C-G) S-PMSI A-D route. as specified earlier, 868 and proxies Leaf A-D routes further up. Similarly, the S-PMSI A-D 869 route may be advertised into the transit region. 871 2.5.3. Ingress RBRs 873 If the BGP next hop in the located active I-PMSI or (C-*,C-*) S-PMSI 874 A-D route matches the Originator IP Address in the per-PE I/S-PMSI 875 A-D route or the IP address in the per-region I-PMSI A-D route's VRF 876 Route Import EC, it means the ingress region has been reached. If 877 the corresponding (C-S,C-G) or (C-*,C-G) S-PMSI A-D route is a made 878 up one and not actually advertised by an ingress PE/RBR, and the RBR 879 does not have corresponding local (C-S,C-G) or (C-*,C-G) state, it 880 reconverts the Leaf A-D route back to C-multicast route, with a CV 881 ("Converted") flag bit indicating that the route is not from local 882 state learned on PE-CE interface but from state learned further 883 downstream. The flag bit prevents other RBRs in this region to 884 trigger Leaf A-D routes from this converted C-multicast route. 886 The converted C-multicast route is constructed as following: 888 o RD: set to the RD of the RBR for the related IP/MAC VRF. 890 o Source/Group length/address fields: set according to the received 891 Leaf A-D route. 893 o Ethernet Tag ID in case of EVPN: set according to the received 894 Leaf A-D route. 896 o Next Hop: set to the RBR's local IP Address. 898 The RT of the converted C-multicast route is set to the RT used for 899 VRF but the route is only propagated to PEs/RBRs in the local region. 901 For EVPN SMET routes, the flag bit is part of the existing Flags 902 field in the NLRI: 904 0 1 2 3 4 5 6 7 905 +--+--+--+--+--+--+--+--+ 906 |reserved|CV|IE|v3|v2|v1| 907 +--+--+--+--+--+--+--+--+ 909 The IE/v3/v2/v1 are existing bits and the CV bit is the new bit to 910 indicate that this is converted from state learned from downstream. 912 For MVPN C-Multicast route, the CV bit is part of a new MVPN Flag EC, 913 to be specified in a future revision. 915 2.5.4. Setting Up Forwarding State on RBRs 917 As a RBR follows the PMSI/Leaf A-D route procedures (even though the 918 S-PMSI A-D route may be made up and not real), it sets up forwarding 919 state accordingly [RFC7988] [I-D.ietf-bier-mvpn]. If IR is used in 920 the upstream region, a downstream allocated label is advertised in 921 the PTA of the Leaf A-D route sent upstream. If BIER is used in a 922 region, the root RBR for the segment in that region MUST advertise an 923 S-PMSI A-D route, whether the route is actually received from 924 upstream or made up based on received C-multicast route or Leaf A-D 925 route, with the PTA's label field set to a label upstream-assigned by 926 the root RBR of the segment. This allows label switching by the RBR 927 instead of relying on (C-S,C-G) lookup based forwarding in the VRF. 929 2.5.5. Other Types of Tunnels 931 The inter-region segmented tunnel can consists of different types of 932 tunnels, like PIM/mLDP/RSVP-TE P2MP tunnels that require advertised 933 S-PMSI A-D routes. This is just like BIER case mentioned in the 934 above section. The only difference is that in BIER case it is the 935 upstream allocated label that needs to be advertised by the S-PMSI 936 A-D routes and in PIM/mLDP/RSVP-TE P2MP case it is the tunnel 937 identity and optionally the upstream allocated label that need to be 938 advertised by the S-PMSI A-D routes. 940 3. Security Considerations 942 This document does not seem to introduce new security risks, though 943 this may be revised after further review and scrutiny. 945 4. Acknowledgements 947 The authors thank Vinay Nallamothu and Kevin Wang for their comments 948 and suggestions. The authors also thank Vinod N. Kumar and 949 Sambasiva Rao for their suggestion of using the selected UMH route's 950 RD for C-multicast A-D even when the source is not in the same AS 951 (Section Section 2.2.2). 953 5. References 955 5.1. Normative References 957 [I-D.ietf-bess-evpn-bum-procedure-updates] 958 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 959 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 960 bess-evpn-bum-procedure-updates-05 (work in progress), 961 December 2018. 963 [I-D.ietf-bess-evpn-igmp-mld-proxy] 964 Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., 965 and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- 966 bess-evpn-igmp-mld-proxy-02 (work in progress), June 2018. 968 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 969 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 970 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 971 ietf-bess-mvpn-evpn-aggregation-label-02 (work in 972 progress), December 2018. 974 [I-D.ietf-bier-mvpn] 975 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 976 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 977 mvpn-11 (work in progress), March 2018. 979 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 980 Requirement Levels", BCP 14, RFC 2119, 981 DOI 10.17487/RFC2119, March 1997, 982 . 984 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 985 R., Patel, K., and J. Guichard, "Constrained Route 986 Distribution for Border Gateway Protocol/MultiProtocol 987 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 988 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 989 November 2006, . 991 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 992 "Bidirectional Protocol Independent Multicast (BIDIR- 993 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 994 . 996 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 997 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 998 2012, . 1000 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1001 Encodings and Procedures for Multicast in MPLS/BGP IP 1002 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1003 . 1005 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 1006 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 1007 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 1008 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 1009 . 1011 [RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K., 1012 and D. Pacella, "Global Table Multicast with BGP Multicast 1013 VPN (BGP-MVPN) Procedures", RFC 7716, 1014 DOI 10.17487/RFC7716, December 2015, 1015 . 1017 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 1018 "Advertisement of Multiple Paths in BGP", RFC 7911, 1019 DOI 10.17487/RFC7911, July 2016, 1020 . 1022 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 1023 Replication Tunnels in Multicast VPN", RFC 7988, 1024 DOI 10.17487/RFC7988, October 2016, 1025 . 1027 5.2. Informative References 1029 [I-D.ietf-bess-evpn-irb-mcast] 1030 Lin, W., Zhang, Z., Drake, J., Rosen, E., Rabadan, J., and 1031 A. Sajassi, "EVPN Optimized Inter-Subnet Multicast (OISM) 1032 Forwarding", draft-ietf-bess-evpn-irb-mcast-02 (work in 1033 progress), January 2019. 1035 [I-D.ietf-bess-mvpn-fast-failover] 1036 Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN fast 1037 upstream failover", draft-ietf-bess-mvpn-fast-failover-05 1038 (work in progress), February 2019. 1040 [I-D.zzhang-bess-mvpn-evpn-segmented-forwarding] 1041 Zhang, Z. and J. Xie, "MVPN/EVPN Segmentated Forwarding 1042 Options", draft-zzhang-bess-mvpn-evpn-segmented- 1043 forwarding-00 (work in progress), December 2018. 1045 Authors' Addresses 1047 Zhaohui Zhang 1048 Juniper Networks 1050 EMail: zzhang@juniper.net 1052 Robert Kebler 1053 Juniper Networks 1055 EMail: rkebler@juniper.net 1057 Wen Lin 1058 Juniper Networks 1060 EMail: wlin@juniper.net 1062 Eric Rosen 1064 EMail: erosen52@gmail.com