idnits 2.17.00 (12 Aug 2021) /tmp/idnits56210/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-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.) ** The abstract seems to contain references ([I-D.sajassi-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 (July 8, 2016) is 2143 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 114, but not defined == Outdated reference: draft-ietf-bess-ir has been published as RFC 7988 == Outdated reference: draft-ietf-bier-mvpn has been published as RFC 8556 == Outdated reference: draft-ietf-idr-add-paths has been published as RFC 7911 == Outdated reference: A later version (-01) exists of draft-sajassi-bess-evpn-igmp-mld-proxy-00 ** Downref: Normative reference to an Informational RFC: RFC 7116 == Outdated reference: A later version (-04) exists of draft-lin-bess-evpn-irb-mcast-02 Summary: 3 errors (**), 0 flaws (~~), 7 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 E. Rosen 6 Expires: January 9, 2017 Juniper Networks 7 July 8, 2016 9 MVPN/EVPN C-Multicast Routes Enhancements 10 draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-00 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.sajassi-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 http://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 January 9, 2017. 45 Copyright Notice 47 Copyright (c) 2016 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 (http://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 . . . . 3 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. EVPN Selective Multicast Ethernet Tag (SMET) Routes . . . 8 72 1.5. Provider Tunnel Segmentation with Explicit-Tracking 73 C-Multicast Routes . . . . . . . . . . . . . . . . . . . 9 74 1.5.1. Conventional Tunnel Segmentation . . . . . . . . . . 9 75 1.5.2. Selective Tunnel Segmentation with Untargeted 76 Explicit-Tracking C-multicast Routes . . . . . . . . 9 77 2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 10 78 2.1. MVPN C-Bidir Support with VPN Backbone being RPL . . . . 10 79 2.1.1. Constructing C-Multicast Share Tree Join route . . . 10 80 2.1.2. Setting Up the MVPN-RPL . . . . . . . . . . . . . . . 12 81 2.2. Inter-AS Propagation of MVPN C-Multicast Routes . . . . . 12 82 2.2.1. Procedures in Section 11.2 of [RFC6514] . . . . . . . 12 83 2.2.2. Ordinary BGP Propagation Procedures . . . . . . . . . 13 84 2.3. Provider Tunnel Segmentation with Explicit-Tracking 85 C-Multicast Routes . . . . . . . . . . . . . . . . . . . 13 86 2.3.1. Egress PEs and RBRs . . . . . . . . . . . . . . . . . 14 87 2.3.2. Transit RBRs . . . . . . . . . . . . . . . . . . . . 15 88 2.3.3. Ingress RBRs . . . . . . . . . . . . . . . . . . . . 15 89 2.3.4. Setting Up Forwarding State on RBRs . . . . . . . . . 16 90 2.3.5. Other Types of Tunnels . . . . . . . . . . . . . . . 16 91 3. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 93 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 5.1. Normative References . . . . . . . . . . . . . . . . . . 17 95 5.2. Informative References . . . . . . . . . . . . . . . . . 18 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 98 1. Introduction 100 [RFC6513] and [RFC6514] specify procedures for originating, 101 propagating, and processing "C-multicast routes". However, there are 102 a number of MVPN use cases that are not properly or optimally handled 103 by those procedures. This document describes those use cases, and 104 specifies the additional procedures needed to handle them. 106 Some of the additional procedures are also applicable to EVPN SMET 107 routes [I-D.sajassi-bess-evpn-igmp-mld-proxy]; this is discussed in 108 Section 1.4. 110 1.1. Terminology 112 This document uses terminology from MVPN and EVPN. It is expected 113 that the audience is familiar with the concepts and procedures 114 defined in [RFC6513], [RFC6514], [RFC7524], [RFC7432], [I-D.zzhang- 115 bess-evpn-bum-procedure-updates], and [I-D.sajassi-bess-evpn-igmp- 116 mld-proxy]. Some terms are listed below for references. 118 o PMSI: P-Multicast Service Interface - a conceptual interface for a 119 PE to send customer multicast traffic to all or some PEs in the 120 same VPN. 122 o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. 124 o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. 126 o C-G-BIDIR: A bidirectional multicast group address (i.e., a group 127 address whose IP multicast distribution tree is built by BIDIR- 128 PIM) in customer address space. 130 o RBR: Regional Border Router. A provider tunnel could be 131 segmented, with one segment in each region. A region could be an 132 AS, an IGP area, or even a subarea. 134 1.2. MVPN C-Bidir Support with VPN Backbone being RPL 136 In BIDIR-PIM [RFC5015], every group is associated with a "Rendezvous 137 Point Link" (RPL). The RPL for a given group G is at the root of the 138 BIDIR-PIM distribution tree. Links of the distribution tree that 139 lead towards the RPL are considered to be "upstream" links, and links 140 that lead away from the RPL are considered to be "downstream" links. 142 Every node on the distribution tree has one upstream link and zero or 143 more downstream links. 145 Data addressed to a BIDIR-PIM group may enter the distribution tree 146 at any node. The entry node sends the data on the upstream links and 147 the downstream links. A node that receives the data from a 148 downstream link sends it on its upstream link and on its other 149 downstream links. A node that receives the data from its upstream 150 link sends it on its downstream links. When a node that is attached 151 to the RPL receives data from a downstream link, it forwards the data 152 onto the RPL (as well as onto any other downstream links.) When node 153 attached to the RPL receives data from the RPL, it forwards the data 154 downstream. 156 The above is a simplified description, and ignores the fact that 157 every link except the RPL has a Designated Forwarder (DF). Only the 158 DF forwards traffic onto the link. However, the RPL has no DF; any 159 node can forward traffic onto the RPL. 161 1.2.1. C-multicast Routes for the MVPN-RPL Method of C-BIDIR support 163 Section 11.1 of [RFC6513] describes a method of providing MVPN 164 support for customers that use BIDIR-PIM. This is known as "MVPN 165 C-BIDIR support". In this method of C-BIDIR support, the VPN 166 backbone itself functions as the RPL. Thus this method is known as 167 the "MVPN-RPL" method. The RPL is actually an I-PMSI or S-PMSI. The 168 PE routers treat the I-PMSI or S-PMSI as their upstream link, and 169 treat their VRF interfaces as downstream links. 171 If the MVPN-RPL method of C-BIDIR support is being used in a 172 particlar MVPN, all the PEs attached to that MVPN must be provisioned 173 to use this method. 175 In the context of a given VPN, a PE with interest in receiving a 176 particular C-BIDIR group (call it C-G-BIDIR) advertises this interest 177 to the other PEs by originating a C-multicast Shared Tree Join route. 178 When any PE receives traffic for the C-G-BIDIR on its PE-CE 179 interface, it sends the data to the MVPN-RPL if and only if it has 180 received corresponding (C-*,C-G-BIDIR) C-multicast Shared Tree Join 181 route. Other PEs receive the traffic on the MVPN-RPL and forward to 182 their downstream receviers. However, the procedure for constructing 183 the C-multicast Shared Tree Join route in this case is not fully 184 specified in [RFC6513] or [RFC6514]. The proper set of procedures 185 are specified in Section 2.1.1 of this document. 187 Compared to other C-Multicast routes specificed in [RFC6514], these 188 are "untargeted" in that the RT allows all PEs in the same MVPN to 189 import them, while those other C-Multicast routes use a RT that 190 identifies a VRF on a particular Upstream Multicast Hop (UMH) PE. 192 If a PE wants to use selective tunnel to send traffic to only a 193 subset of the PEs on MVPN-RPL, i.e., those with downstream 194 (C-*,C-G-BIDIR) state, per [RFC6513] [RFC6514] the PE needs to 195 advertise a corresponding (C-*,C-G-BIDIR) S-PMSI A-D route, whose PTA 196 specifies the tunnel to be used. In case of RSVP-TE P2MP, Ingress 197 Replication (IR), or BIER tunnel, the Leaf Information Required (LIR) 198 bit in the S-PMSI route's PTA is set to solicit corresponding Leaf 199 A-D routes from those PEs with downstream (C-*,C-G-BIDIR) state. 200 Every PE that wants to use selective tunnel for the (C-*,C-G-BIDIR) 201 will advertise its own S-PMSI A-D route, each triggering a set of 202 corresponding Leaf A-D routes. 204 Notice that the (C-*,C-G-BIDIR) C-Multicast routes from different PEs 205 all have their own RDs so Route Reflectors (RRs) will reflect every 206 one of them, and they already serve explicit tracking purpose (the 207 BGP Next Hop identifies the originator of the route in non- 208 segmentation case) - there is no need to use Leaf A-D routes 209 triggered by the LIR bit in S-PMSI A-D routes. In case of RSVP-TE 210 P2MP tunnel, the S-PMSI A-D routes are still needed to announce the 211 tunnel but the LIR bit does not need to be set. In case of IR/BIER, 212 there is no need for S-PMSI A-D routes at all. 214 1.2.2. Optional use of MVPN-RPL RD with mLDP/PIM Provider Tunnels 216 When mLDP/PIM tunnels are used, there is no need for explicit 217 tracking as the leaves will simply send mLDP label Mapping or PIM 218 Join messages. As a result, it's unnecessary for a PE to retain each 219 C-Multicast route from each PE for the same C-G-BIDIR. If there is a 220 Route Reflector (RR) in use, and it is known apriori that all the 221 PEs/RRs/ASBRs involved in the propagation of the C-Multicast routes 222 support BGP ADD-PATH [I-D.ietf-idr-add-paths], then the PEs could use 223 a common RD to contruct the C-Multicast routes. That way, the routes 224 from different PEs for the same C-G-BIDIR will be considered paths 225 for the same route and the RRs will reflect N paths to each PE. If N 226 is significantly smaller than the number of PEs that advertises the 227 routes, then the burden is significantly reduced for the PEs. 229 The reason for the need for ADD-PATH is shown with this example: both 230 PE1 and PE2 advertise the same (C-*,C-G-BIDIR) C-Multicast route and 231 the RR chooses the one from PE1 as the active path. Without ADD- 232 PATH, the RR won't reflect any (C-*,C-G-BIDIR) path back to PE1, 233 causing PE1 to think there is no other PE interested in receiving the 234 C-G-BIDIR traffic. With ADD-PATH, it is guaranteed that even the 235 originator of the active path will receive at least one other path. 236 For this reason, ADD-PATH is needed and N=2 is well enough. 238 1.2.3. MVPN C-ASM Support without CE Routers 240 Current MVPN specifications is based on the fact that CEs are routers 241 and in case of ASM one or more of the routers in customer address 242 space, which could be a CE, a PE's VRF, or another non-PE/CE router, 243 serves as RP. Traffic may be delivered on shared trees, switch to 244 source specific trees, or switch back to shared trees depending the 245 situation. There are two modes of MVPN to support ASM, all involving 246 (C-S,C-G) MVPN Source Active (SA) A-D routes, individial (C-S,C-G) 247 control/forwarding plane state and procedures that are not needed for 248 a special scenario where CEs are not routers but just hosts. 250 From a logical point of view, this special scenario is when a VPN 251 only involves customer networks directly connected to the PEs and no 252 customer routers are used.. A practical example is EVPN inter-subnet 253 multicast [I-D.lin-bess-evpn-irb-mcast], when EVPN is used to connect 254 only servers and no customer routers are involved. In this case, it 255 does not make sense to introduce the RP concept into the deployment 256 and involve the MVPN SA procedures. Rather, this could be modeled as 257 C-Bidir with MVPN-RPL and all the above discussed optimizations 258 apply. 260 1.3. Inter-AS Propagation of MVPN C-Multicast Routes 262 Section 11.2 of [RFC6514] specifies the procedure used to propagate 263 C-multicast routes from one AS to another. However, there are a 264 number of problems with the procedures as specified in that RFC. 266 RFC6514 presumes that C-multicast routes are propagated through the 267 ASBRs. This is analogous to RFC 4364's "Inter-AS option b". 268 However, in some deployment scenarios, the C-multicast routes are 269 propagated through Route Reflectors, in a manner analogous to RFC 270 4364's "Inter-AS option c". Strictly speaking, RFC 6514 does not 271 allow this deployment scenario. This document updates RFC 6514 by 272 allowing this deployment scenario to be used in place of the 273 procedures of Section 11.2 of RFC 6514. 275 In some deployment scenarios, the propagation of C-multicast routes 276 is controlled by the "Route Target Constraint" procedures of 277 [RFC4684]. Strictly speaking, RFC 6514 does not allow this 278 deployment scenario. This document updates RFC 6514 by allowing this 279 deployment scenario to be used in place of the procedures of 280 Section 11.2 of RFC 6514. 282 Per [RFC6514], an MVPN C-Multicast route is targeted at a particular 283 PE, and its inter-as propagation towards the PE follows a series of 284 ASBRs (in the reverse order) on the propagation path of one of the 285 following: 287 o The Intra-AS I-PMSI A-D route from the targeted PE, if the 288 deployment is using non-segmented tunnels. In this scenario, the 289 IP address of the targeted PE is encoded into the four-octet 290 "Source AS" field (!) of the C-multicast route's NLRI. 292 o The Inter-AS I-PMSI A-D route for the AS that the targeted PE is 293 in, if the deployment is using segmented tunnel. In this 294 scenario, the AS number of the source PE is encoded into the 295 "Source AS" field of the C-multicast route's NLRI. 297 In both cases, the corresponding I-PMSI A-D route is found by looking 298 for an I-PMSI A-D route whose NLRI consists of the C-multicast 299 route's RD prepended to the contents of the C-multicast route's 300 "Source AS" field. If neither Inter-AS nor Intra-AS I-PMSI A-D route 301 is used, e.g. (C-*,C-*) S-PMSI A-D route is used, then the specified 302 procedure will not work. 304 It must be noted that the RFC 6514 Section 11.2 propagation 305 procedures cannot be applied to untargeted C-multicast routes, and 306 cannot be applied even to targeted C-multicast routes if the 307 infrastructure is based on IPv6 rather than IPv4. 309 This document updates RFC 6514 by declaring that the procedure of 310 Section 11.2 of that document is only applicable in the case that (1) 311 the C-multicast routes are being propagated through the ASBRs, AND 312 (2) the propagation of those routes is not under the control of the 313 Route Target Constraint procedures. It also updates the procedures 314 of Section 11.2 of [RFC6514] to allow it to work without relying on 315 I-PMSI A-D routes, whether IPv4 or IPv6 infrastructure is used. 317 This document also updates RFC 6514 by declaring that C-multicast 318 routes MAY be propagated using ordinary BGP propagation procedures, 319 which do not rely on the presence of I-PMSI A-D routes. For targeted 320 C-multicast routes, this will result in a less optimal propagation 321 path, but it does work in all cases. The Route Target Constraint 322 procedures can always be used to obtain a more optimal path. 324 The selection of the propagation procedure for C-multicast routes is 325 determined by provisioning. 327 In Section 1.2.1, the explicit tracking using C-multicast route 328 relies on that the route's next hop is not changed so that the next 329 hop can identify the originator. If the c-multicast routes are 330 propagated through ASBRs, the next hop will be changed. With tunnel 331 segmentation, this is not a problem (see Section 1.5) but if non- 332 segmented tunnels are used, either the C-multicast route propagation 333 must follow the Optoin C procedures and the next hop is not changed 334 by the RRs, or the routes must carry an EC to identify the 335 originator. Or, the RD of a C-multicast route can be used to locate 336 an I/S-PMSI route from the same PE, in which the Originator IP 337 Address can be found. 339 1.4. EVPN Selective Multicast Ethernet Tag (SMET) Routes 341 [I-D.sajassi-bess-evpn-igmp-mld-proxy] defines a new EVPN route type 342 known as an "SMET route". 344 The EVPN SMET routes are analogous to the MVPN C-muilticast routes, 345 in that both type of routes are used to disseminate the information 346 that a particular egress PE has interest in a particular multicast 347 C-flow or set of C-flows. 349 An EVPN SMET route contains, in its NLRI, the RD associated with the 350 VRF from which the SMET route was originated. In addition, it is 351 disseminated to all PEs of a given EVI. In this way, SMET routes are 352 analogous to the MVPN C-multicast routes that are used for C-BIDIR 353 support. 355 An EVPN SMET route contains, in its NLRI, the IP address of the 356 originating PE. In this way, they are analogous to the MVPN Leaf A-D 357 routes (They really combine the function of the MVPN C-multicast 358 routes and the MVPN Leaf A-D routes). Similarly, they are also 359 analogous to the C-multicast route for MVPN-RPL that carries an EC 360 that identifies the originating PE. 362 In EVPN, as in MVPN, explicit tracking is required when selective 363 tunnels are realized using IR, BIER, or RSVP-TE P2MP. The EVPN SMET 364 routes provide this explicit tracking, so in these cases EVPN does 365 not need explicit Leaf A-D routes. With IR/BIER, there is no need 366 for S-PMSI route either. However, when SMET routes are used with 367 segmented IR/BIER tunnels, more procedures are needed, just like the 368 C-multicast route in MVPN-RPL case (Section 1.5). For that reason, 369 given the similarity between SMET and C-Multicast routes, in this 370 document we will use the same term C-Multicast route for EVPN SMET 371 route as well. The two may be used interchably in case of EVPN. 373 If selective tunnels are set up using procedures that do not require 374 explicit tracking, e.g. mLDP or PIM, the following optimization could 375 be done, similar to MVPN-RPL with mLDP/PIM tunnels (Section 1.2.2): 377 o When constructing an SMET route, put 0 as the Originator Router 378 Address. 380 o When constructing an SMET route in the context of a given EVI, 381 have all PEs of that EVI set the RD field of the NLRI to the same 382 value (This is analogous to "MVPN-RPL RD" discussed in 383 Section 1.2.2). 385 o When a Route Reflector distributes the SMET routes, it uses BGP 386 ADD-PATH to distribute at least two "paths" for a given NLRI. 388 1.5. Provider Tunnel Segmentation with Explicit-Tracking C-Multicast 389 Routes 391 For the above MVPN-RPL and EVPN cases where C-multicast routes are 392 used for explicit tracking without requiring corresponding S-PMSI A-D 393 routes in case of IR/BIER selective tunnel, it works well when there 394 is no tunnel segmentation. With tunnel segmentation [RFC6514] 395 [RFC7524], [I-D.zzhang-bess-evpn-bum-procedure-updates] additional 396 procedures are needed. 398 1.5.1. Conventional Tunnel Segmentation 400 Multicast forwarding needs to follow a rooted tree. With 401 segmentation, the tree is devided into segments, with each segment 402 rooted at either the ingress PE or a Regional Border Router (RBR). A 403 segment is contained in a region, which could be an AS, an area, or a 404 sub-area. The root of a segment only needs to track the leaves in 405 its region, which are PEs or RBRs in that region. With the 406 traditional PMSI/Leaf A-D procedures, an ingress PE/RBR sends out an 407 I/S-PMSI route, propagated by RBRs (segmentation points), who change 408 the tunnel identifier along the way to identify the tunnels for their 409 segments. The Leaf A-D routes from PEs are not propagated by the 410 RBRs. Rather, a RBR will proxy the Leaf AD routes it receives from 411 its downstream towards its upstream RBR or PE, following the I/S-PMSI 412 A-D routes received in the upstream region, as specified in [RFC6514] 413 [RFC7524] [I-D.zzhang-bess-evpn-bum-procedure-updates]. 415 1.5.2. Selective Tunnel Segmentation with Untargeted Explicit-Tracking 416 C-multicast Routes 418 Without segmentation, the untargeted explicit-tracking C-Multicast 419 routes are sent to every PE, and each PE adds the originator of the 420 routes as leaves of the tunnel rooted at the PE. 422 With segmentation, untargeted explicit-tracking C-Multicast routes 423 are propagated throught segmentation points towards all ingress PEs 424 or ASes and are merged along the way. This is like the traditional 425 PMSI/Leaf A-D procedures but with one difference. 427 With the traditional PMSI/Leaf A-D procedures, the propagation is 428 towards the originator of the PMSI A-D route and a single tree is 429 formed. With untargeted C-Multicast routes, multiple trees are 430 formed, each being rooted at the ingress PE (if per-region 431 aggregation [I-D.zzhang-bess-evpn-bum-procedure-updates] is not used) 432 or ingress RBR (if per-region aggregation is used). The roots of 433 those trees are either the ingress PEs or the ingress RBRs, 434 identified by all the per-PE or per-region I-PMSI A-D routes. 436 To form those multiple trees without requiring S-PMSI A-D routes from 437 the ingress PEs/RBRs, this document proposes that the RBRs convert a 438 C-multicast route originated in its own region to Leaf A-D routes, as 439 if corresponding S-PMSI A-D routes had been received from ingress 440 PEs/RBRs. The details are provided in Section 2.2. 442 2. Specifications 444 This section provides detailed specifications for the optional 445 enhancements introduced above. 447 2.1. MVPN C-Bidir Support with VPN Backbone being RPL 449 2.1.1. Constructing C-Multicast Share Tree Join route 451 In the context of a particular VRF, a PE with downstream state for 452 the group C-G-BIDIR originates a C-multicast Shared Tree Join route, 453 referred to as "MVPN-RPL C-multicast Join", when the MVPN-RPL method 454 of C-BIDIR support is being used. 456 The fields of the route are set as follows: 458 o RD: See Section 2.1.1.2. 460 o Source AS: set to zero. 462 o Multicast Source Length: 4 or 16. 464 o Multicast Source: set to RPA. 466 o Multicast Group Length: 4 or 16. 468 o Multicast Group: BIDIR-PIM group address. 470 Note that the RD field, and the Route Targets that are attached to 471 the C-multicast route are different than what is specified in 472 [RFC6514]. See following two sections. 474 2.1.1.1. Setting the Route Targets 476 Per [RFC6514], when a PE originates a C-multicast route, it "targets" 477 the route to a specific one of the other PEs attached to the same 478 VPN. The IP address of the targeted PE is encoded into a Route 479 Target and attached to the C-mulitcast route. This ensures that the 480 C-multicast route is processed only by the PE to which it is 481 targeted. 483 However, C-multicast routes used by the MVPN-RPL method are not 484 targeted. Rather, they must be processed by all the other PEs 485 attached to the same MVPN. Thus we refer to these routes as 486 "untargeted". The Route Targets attached to these routes must be 487 such as to cause the routes to be propagated to all the other PEs of 488 the given MVPN. By default, these will be the same Route Targets 489 that are attached to the I-PMSI A-D routes of the MVPN. 491 2.1.1.2. Setting the Route Distinguisher 493 Per [RFC6514], the RD in a C-multicast Join Route is the RD of a VRF 494 on the PE to which the route is targeted. However, in an MVPN-RPL 495 C-multicast Join, the RD is set differently. 497 If PIM/mLDP provider tunnels are used, and it is known that all the 498 PEs/RRs/ASBRs involved in the propagation of C-multicast routes 499 support BGP ADD-PATH, the RD MAY be set to a value that is specially 500 configured to be used as the RD for MVPN-RPL in a given VPN. Call 501 this the "MVPN-RPL" RD for that VPN. In that case, all the 502 C-multicast Joins that are providing C-BIDIR support (for a given 503 VPN) using the MVPN-RPL method will have the same RD. This MVPN-RPL 504 RD of a given VPN MUST NOT be used for any other purpose, or by any 505 other VPN. See Section 1.2.2 for a discussion of when it may be 506 advantageous to use an MVPN-RPL RD. 508 For other provider tunnel types, or if the above mentioned MVPN-RPL 509 RD in case of PIM/mLDP tunnel is not feasible (e.g. BGP ADD-PATH is 510 not supported), the RD in the C-multicast route is that of the VRF 511 from which the route is originated. 513 For Global Table Multicast (GTM) using MVPN procedures [RFC7116], RFC 514 7116 specifies that MVPN routes use a special 0:0 RD. This document 515 specifies that GTM use non-0:0 RDs for C-Multicast routes for 516 C-Bidir, when the backbone is used as RPL and provider tunnels are 517 not set up by PIM/mLDP. 519 2.1.2. Setting Up the MVPN-RPL 521 By default, the I-PMSI or (C-*,C-BIDIR) S-PMSI plays the role of 522 MVPN-RPL. When (C-*,C-G-BIDIR) S-PMSI is used for a particular 523 C-G-BIDIR, the following procedures are followed, depending on the 524 type of provider tunnel used. 526 2.1.2.1. Ingress Replication or BIER 528 If Ingress Replication or BIER is used, there is no need for the 529 ingress PE to advertise (C-*,C-G-BIDIR) S-PMSI A-D route. The 530 ingress PE identifies the tunnel leaves to send traffic to by the 531 C-multicast routes it receives, because each such route has a 532 different RD and serves explicit tracking purpose. In case of IR, 533 the label in the Intra-AS I-PMSI A-D route or (C-*,C-*) S-PMSI A-D 534 route from a leaf is used to send traffic to the leaf. In case of 535 BIER, the label in the same route from the ingress PE is used to send 536 traffic. 538 2.1.2.2. RSVP-TE P2MP 540 With RSVP-TE P2MP tunnel, the ingress PE advertises (C-*,C-G-BIDIR) 541 S-PMSI A-D route without setting the LIR bit in the route's PTA. It 542 identifies the tunnel leaves from the C-multicast routes it receives. 544 2.1.2.3. PIM/mLDP 546 With PIM or mLDP P2MP provider tunnel, procedures in [RFC6514] are 547 followed. 549 2.2. Inter-AS Propagation of MVPN C-Multicast Routes 551 This specification allows two methods of Inter-AS propagation for 552 MVPN C-multicast routes. The choice of which method is used is by 553 provisioning. 555 2.2.1. Procedures in Section 11.2 of [RFC6514] 557 The procedures in Section 11.2 of [RFC6514] are extended with the 558 following. 560 The Source AS field in the NLRI of C-multicast route is set to the AS 561 number of the UMH PE if and only if segmented inter-AS tunnels and 562 per-AS aggregation (via Inter-AS I-PMSI A-D routes) are used. The 563 existing procedures are used as is in this case. 565 Otherwise, when an egress PE constructs a C-Multicast route and the 566 upstream PE is in a different AS from the local PE, it finds in its 567 VRF an Intra-AS I-PMSI A-D route or any S-PMSI A-D route from the 568 upstream PE (the Originating Router's IP Address field of that route 569 has the same value as the one carried in the VRF Route Import of the 570 (unicast) route to the address carried in the Multicast Source 571 field). The RD of the found I/S-PMSI A-D route is used as the RD of 572 the advertised C-multicast route. The Source AS field in the 573 C-multicast route is set to 0. If the Next Hop of the found I/S-PMSI 574 A-D route is an EBGP neighbor of the local PE, then the PE advertises 575 the C- multicast route to that neighbor. Otherwise the PE advertises 576 the C-multicast route into IBGP. 578 When an ASBR receives a C-multicast route with the Source AS field 579 set to 0, it uses the RD of the C-multicast route to locate an Intra- 580 AS I-PMSI A-D route or any S-PMSI A-D route, and propagate the 581 C-multicast route to the bgp neighbor from which the found I/S-PMSI 582 A-D route is learned. 584 2.2.2. Ordinary BGP Propagation Procedures 586 This document specifies that C-multicast routes MAY be propagated 587 using ordinary BGP propagation procedures, which do not rely on the 588 presence of any I/S-PMSI A-D routes. With this method, the Source AS 589 field in the C-Multicast route SHOULD be set to 0. For targeted 590 C-multicast routes, this will result in a less optimal propagation 591 path, but it does work in all cases. The Route Target Constraint 592 procedures can always be used to obtain a more optimal path. 594 2.3. Provider Tunnel Segmentation with Explicit-Tracking C-Multicast 595 Routes 597 This section applies when IR/BIER are used for MVPN/EVPN selective 598 tunnels. 600 If per-region aggregation 601 [I-D.zzhang-bess-evpn-bum-procedure-updates] is used, this document 602 specifies that the per-region I-PMSI A-D route MUST carry a VRF Route 603 Import EC to identif the originator of the per-region I-PMSI A-D 604 route. Note that, while it borrows "VRF Route Import EC" from the 605 UMH routes, it is only used to identify the originator. 607 If per-region aggregation is not used, this document specifies that 608 either per-PE I-PMSI or (C-*,C-*) S-PMSI A-D routes MUST be 609 originated by every PE. 611 2.3.1. Egress PEs and RBRs 613 An egress PE originates MVPN C-multicast routes for MVPN-RPL as 614 specified in previous sections of this document, or EVPN SMET routes 615 as specified in [I-D.sajassi-bess-evpn-igmp-mld-proxy]. Recall that 616 EVPN SMET routes may also be referred to C-Multicast routes in this 617 document. 619 Explicit-tracking C-multicast routes must be processed by 620 segmentation points, which are referred to as RBRs. When a RBR 621 receives a C-multicast route from within its own region, and the 622 route does not carry a flag bit that indicates the route is converted 623 from a downstream Leaf A-D route (see descriptions below), it 624 converts the C-multicat route into one or more Leaf A-D routes, as if 625 it had received corresponding S-PMSI A-D routes. When a converted 626 Leaf A-D routes reaches the ingress region, the RBR converts it back 627 to C-multicast routes. 629 With per-region aggregation, the RBR in an egress region finds all 630 active per-region I-PMSI A-D route that the RBR has in the 631 corresponding VRF. For each of them, it makes up a (C-S,C-G) or 632 (C-*,C-G) S-PMSI A-D route as following. 634 o RD: set to the RD from the per-region I-PMSI A-D route. 636 o Source/Group length/address fields: set according to the received 637 C-multicast route. 639 o Originator's IP Address: set according to the VRF Route Import EC 640 in the per-region I-PMSI A-D route 642 o Ethernet Tag ID in case of EVPN: set according to the received 643 SMET route (which is also referred to as C-multicast route). 645 o Next Hop: set according to the per-region I-PMSI A-D route. 647 Without per-region aggregation, a RBR finds all active per-PE I-PMSI 648 or (C-*,C-*) S-PMSI A-D route in the VRF. For each of them it makes 649 up a (C-S,C-G) or (C-*,C-G) S-PMSI A-D route similar to the per- 650 region aggregation case. The only difference is that the 651 Originator's IP Address field is set to the same as in the per-PE 652 I-PMSI or (C-*,C-*) S-PMSI A-D route. 654 The made up S-PMSI A-D route is for local use only, and not 655 propagated anywhere. A corresponding Leaf A-D route is then 656 generated and propagated to the upstream identified by the BGP next 657 hop in the made up S-PMSI A-D route, following existing PMSI/Leaf A-D 658 route procedures. 660 2.3.2. Transit RBRs 662 When an upstream RBR receives a (C-S,C-G) or (C-*,C-G) Leaf A-D 663 route, It locates the active per-PE/region I-PMSI or (C-*,C-*) S-PMSI 664 A-D route whose RD matches the received Leaf A-D route. If no such 665 route exists, the received Leaf A-D route is ignored until such a 666 route appears later. It also tries to locate a corresponding active 667 (C-S,C-G) or (C-*,C-G) S-PMSI A-D route, which could be a real one 668 received from an upstream PE/RBR, or could be a made up one triggered 669 by a Leaf A-D route from a different downstream. If such route 670 exists, existing PMSI/Leaf A-D route procedures are followed. 672 If no such corresponding active (C-S,C-G) or (C-*,C-G) S-PMSI A-D 673 route exists, and the located active I-PMSI or (C-*,C-*) S-PMSI A-D 674 route has a next hop different from the Originator IP Address in the 675 per-PE I-PMSI A-D route or (C-*,C-*) I-PMSI A-D route, or different 676 from the address in the VRF Route Import EC in the per-region I-PMSI 677 A-D route, the ingress region corresponding to the I-PMSI or 678 (C-*,C-*) S-PMSI A-D route has not been reached. The RBR then makes 679 up a (C-S,C-G) or (C-*,C-G) S-PMSI A-D route. as specified earlier, 680 and proxies Leaf A-D routes further up. 682 2.3.3. Ingress RBRs 684 If the BGP next hop in the located active I-PMSI or (C-*,C-*) S-PMSI 685 A-D route matches the Originator IP Address in the per-PE I/S-PMSI 686 A-D route or the IP address in the per-region I-PMSI A-D route's VRF 687 Route Import EC, it means the ingress region has been reached. If 688 the corresponding (C-S,C-G) or (C-*,C-G) S-PMSI A-D route is a made 689 up one and not actually advertised by an ingress PE/RBR, the RBR 690 reconverts the Leaf A-D route back to C-multicast route, with a CV 691 ("Converted") flag bit indicating that the route is not from local 692 state learned on PE-CE interface but from state learned further 693 downstream. The flag bit prevents other RBRs in this region to 694 trigger Leaf A-D routes from this converted C-multicast route. 696 The converted C-multicast route is constructed as following: 698 o RD: set to the RD of the RBR for the related IP/MAC VRF. 700 o Source/Group length/address fields: set according to the received 701 Leaf A-D route. 703 o Ethernet Tag ID in case of EVPN: set according to the received 704 Leaf A-D route. 706 o Next Hop: set to the RBR's local IP Address. 708 The RT of the converted C-multicast route is set to the RT used for 709 VRF but the route is only propagated to PEs/RBRs in the local region. 711 For EVPN SMET routes, the flag bit is part of the existing Flags 712 field in the NLRI: 714 0 1 2 3 4 5 6 7 715 +--+--+--+--+--+--+--+--+ 716 |reserved|CV|IE|v3|v2|v1| 717 +--+--+--+--+--+--+--+--+ 719 The IE/v3/v2/v1 are existing bits and the CV bit is the new bit to 720 indicate that this is converted from state learned from downstream. 722 For MVPN C-Multicast route, the CV bit is part of a new MVPN Flag EC, 723 to be specified in a future revision. 725 2.3.4. Setting Up Forwarding State on RBRs 727 As a RBR follows the PMSI/Leaf A-D route procedures (even though the 728 S-PMSI A-D route may be made up and not real), it sets up forwarding 729 state accordingly [I-D.ietf-bess-ir] [I-D.ietf-bier-mvpn]. If IR is 730 used in the upstream region, a downstream allocated label is 731 advertised in the PTA of the Leaf A-D route sent upstream. If BIER 732 is used in a region, the root RBR for the segment in that region MUST 733 advertise an S-PMSI A-D route, whether the route is actually received 734 from upstream or made up based on received C-multicast route or Leaf 735 A-D route, with the PTA's label field set to a label upstream- 736 allocated by the root RBR of the segment. This allows label 737 switching by the RBR instead of relying on (C-S,C-G) lookup based 738 forwarding in the VRF. 740 2.3.5. Other Types of Tunnels 742 The inter-region segmented tunnel can consists of different types of 743 tunnels, like PIM/mLDP/RSVP-TE P2MP tunnels that require advertised 744 S-PMSI A-D routes. This is just like BIER case mentioned in the 745 above section. The only difference is that in BIER case it is the 746 upstream allocated label that needs to be advertised by the S-PMSI 747 A-D routes and in PIM/mLDP/RSVP-TE P2MP case it is the tunnel 748 identity and optionaly the upstream allocated label that need to be 749 advertised by the S-PMSI A-D routes. 751 3. Security Considerations 753 This document does not seem to introduce new security risks, though 754 this may be revised after further review and scrutiny. 756 4. Acknowledgements 758 The authors thank Vinay Nallamothu and Kevin Wang for their comments 759 and suggestions. 761 5. References 763 5.1. Normative References 765 [I-D.ietf-bess-ir] 766 Rosen, E., Subramanian, K., and Z. Zhang, "Ingress 767 Replication Tunnels in Multicast VPN", draft-ietf-bess- 768 ir-03 (work in progress), April 2016. 770 [I-D.ietf-bier-mvpn] 771 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 772 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 773 mvpn-03 (work in progress), June 2016. 775 [I-D.ietf-idr-add-paths] 776 Walton, D., Retana, A., Chen, E., and J. Scudder, 777 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 778 add-paths-15 (work in progress), May 2016. 780 [I-D.sajassi-bess-evpn-igmp-mld-proxy] 781 Sajassi, A., Patel, K., Thoria, S., Yeung, D., Drake, J., 782 and W. Lin, "IGMP and MLD Proxy for EVPN", draft-sajassi- 783 bess-evpn-igmp-mld-proxy-00 (work in progress), October 784 2015. 786 [I-D.zzhang-bess-evpn-bum-procedure-updates] 787 Zhang, Z., Lin, W., Rabadan, J., and K. Patel, "Updates on 788 EVPN BUM Procedures", draft-zzhang-bess-evpn-bum- 789 procedure-updates-03 (work in progress), April 2016. 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, 793 DOI 10.17487/RFC2119, March 1997, 794 . 796 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 797 R., Patel, K., and J. Guichard, "Constrained Route 798 Distribution for Border Gateway Protocol/MultiProtocol 799 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 800 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 801 November 2006, . 803 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 804 "Bidirectional Protocol Independent Multicast (BIDIR- 805 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 806 . 808 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 809 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 810 2012, . 812 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 813 Encodings and Procedures for Multicast in MPLS/BGP IP 814 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 815 . 817 [RFC7116] Scott, K. and M. Blanchet, "Licklider Transmission 818 Protocol (LTP), Compressed Bundle Header Encoding (CBHE), 819 and Bundle Protocol IANA Registries", RFC 7116, 820 DOI 10.17487/RFC7116, February 2014, 821 . 823 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 824 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 825 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 826 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 827 . 829 5.2. Informative References 831 [I-D.lin-bess-evpn-irb-mcast] 832 Lin, W., Zhang, Z., Drake, J., and J. Rabadan, "EVPN 833 Inter-subnet Multicast Forwarding", draft-lin-bess-evpn- 834 irb-mcast-02 (work in progress), March 2016. 836 Authors' Addresses 838 Zhaohui Zhang 839 Juniper Networks 841 EMail: zzhang@juniper.net 843 Robert Kebler 844 Juniper Networks 846 EMail: rkebler@juniper.net 847 Wen Lin 848 Juniper Networks 850 EMail: wlin@juniper.net 852 Eric Rosen 853 Juniper Networks 855 EMail: erosen@juniper.net