idnits 2.17.1 draft-ietf-bess-bgp-multicast-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 : ---------------------------------------------------------------------------- == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A network currently running PIM can be incrementally transitioned to BGP based multicast. At any time, a router supporting BGP based multicast can use PIM with some neighbors (upstream or downstream) and BGP with some other neighbors. PIM and BGP MUST not be used simultaneously between two neighbors for multicast purpose, and routers connected to the same LAN MUST be transitioned during the same maintenance window. -- The document date (May 13, 2020) is 1438 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC7438' is mentioned on line 268, but not defined == Missing Reference: 'RFC5492' is mentioned on line 318, but not defined == Missing Reference: 'RFC4760' is mentioned on line 504, but not defined == Missing Reference: 'RFC4271' is mentioned on line 504, but not defined == Missing Reference: 'RFC7524' is mentioned on line 617, but not defined == Missing Reference: 'RFC6388' is mentioned on line 765, but not defined == Unused Reference: 'RFC2119' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'RFC5015' is defined on line 957, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-mvpn-pe-ce' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 986, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-15 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 == Outdated reference: A later version (-02) exists of draft-voyer-pim-sr-p2mp-policy-01 == Outdated reference: A later version (-02) exists of draft-wijnands-bier-mld-lan-election-01 Summary: 1 error (**), 0 flaws (~~), 19 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Z. Zhang 3 Internet-Draft L. Giuliano 4 Intended status: Standards Track Juniper Networks 5 Expires: November 14, 2020 K. Patel 6 Arrcus 7 I. Wijnands 8 M. Mishra 9 Cisco Systems 10 A. Gulko 11 Refinitiv 12 May 13, 2020 14 BGP Based Multicast 15 draft-ietf-bess-bgp-multicast-01 17 Abstract 19 This document specifies a BGP address family and related procedures 20 that allow BGP to be used for setting up multicast distribution 21 trees. This document also specifies procedures that enable BGP to be 22 used for multicast source discovery, and for showing interest in 23 receiving particular multicast flows. Taken together, these 24 procedures allow BGP to be used as a replacement for other multicast 25 routing protocols, such as PIM or mLDP. The BGP procedures specified 26 here are based on the BGP multicast procedures that were originally 27 designed for use by providers of Multicast Virtual Private Network 28 service. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC2119. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on November 14, 2020. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1.1. Native/unlabeled Multicast . . . . . . . . . . . . . 3 73 1.1.2. Labeled Multicast . . . . . . . . . . . . . . . . . . 4 74 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 75 1.2.1. (x,g) Multicast . . . . . . . . . . . . . . . . . . . 5 76 1.2.1.1. Source Discovery for ASM . . . . . . . . . . . . 5 77 1.2.1.2. ASM Shared-tree-only Mode . . . . . . . . . . . . 6 78 1.2.1.3. Integration with BGP-MVPN . . . . . . . . . . . . 7 79 1.2.2. BGP Inband Signaling for mLDP Tunnel . . . . . . . . 7 80 1.2.3. BGP Sessions . . . . . . . . . . . . . . . . . . . . 7 81 1.2.4. LAN and Parallel Links . . . . . . . . . . . . . . . 8 82 1.2.5. Transition . . . . . . . . . . . . . . . . . . . . . 9 83 1.2.6. Inter-region Multicast . . . . . . . . . . . . . . . 9 84 1.2.6.1. Same BGP Signaling Inline across a Region . . . . 10 85 1.2.6.2. Different Signaling Inline across a Region . . . 10 86 1.2.6.3. Overlay Signaling Over a Region . . . . . . . . . 10 87 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 11 88 2.1. BGP NLRIs and Attributes . . . . . . . . . . . . . . . . 11 89 2.1.1. S-PMSI A-D Route . . . . . . . . . . . . . . . . . . 12 90 2.1.2. Leaf A-D Route . . . . . . . . . . . . . . . . . . . 13 91 2.1.3. Source Active A-D Route . . . . . . . . . . . . . . . 14 92 2.1.4. S-PMSI A-D Route for C-multicast mLDP . . . . . . . . 14 93 2.1.5. Session Address Extended Community . . . . . . . . . 14 94 2.1.6. Multicast RPF Address Extended Community . . . . . . 15 95 2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 15 96 2.2.1. Source Discovery for ASM . . . . . . . . . . . . . . 15 97 2.2.2. Originating Tree Join Routes . . . . . . . . . . . . 15 98 2.2.2.1. (x,g) Multicast Tree . . . . . . . . . . . . . . 15 99 2.2.2.2. BGP Inband Signaling for mLDP Tunnel . . . . . . 16 100 2.2.3. Receiving Tree Join Routes . . . . . . . . . . . . . 17 101 2.2.4. Withdrawl of Tree Join Routes . . . . . . . . . . . . 17 102 2.2.5. LAN procedures for (x,g) Unidirectional Tree . . . . 17 103 2.2.5.1. Originating S-PMSI A-D Routes . . . . . . . . . . 17 104 2.2.5.2. Receiving S-PMSI A-D Routes . . . . . . . . . . . 18 105 2.2.6. Distributing Label for Upstream Traffic for 106 Bidirectional Tree/Tunnel . . . . . . . . . . . . . . 19 107 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 108 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 109 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 110 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 111 6.1. Normative References . . . . . . . . . . . . . . . . . . 20 112 6.2. Informative References . . . . . . . . . . . . . . . . . 21 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 115 1. Introduction 117 1.1. Motivation 119 This section provides some motivation for BGP signaling for native 120 and labeled multicast. One target deployment would be a Data Center 121 that requires multicast but uses BGP as its only routing protocol 122 [RFC7938]. In such a deployment, it would be desirable to support 123 multicast by extending the deployed routing protocol, without 124 requiring the deployment of tree building protocols such as PIM, 125 mLDP, RSVP-TE P2MP, and without requiring an IGP. 127 Additionally, compared to PIM, BGP based signaling has several 128 advantage as described in the following section, and may be desired 129 in non-DC deployment scenarios as well. 131 1.1.1. Native/unlabeled Multicast 133 Protocol Independent Multicast (PIM) has been the prevailing 134 multicast protocol for many years. Despite its success, it has two 135 drawbacks: 137 o The ASM model, which is prevalent, introduces complexity in the 138 following areas: source discovery procedures, need for Rendezvous 139 Points (RPs) and group-to-RP mappings, need to switch between RP- 140 rooted trees and source-rooted trees, etc. 142 o Periodical protocol state refreshes due to soft state nature. 144 PIM-SSM removes much of the complexity of PIM-ASM by moving source 145 discovery to the application layer. However, for various reasons, 146 many legacy applications and devices still rely upon network-based 147 source discovery. PIM-Port (PIM over Reliable Transport) solves the 148 soft state issue, though its deployment has also been limited for two 149 reasons: 151 o It does not remove the ASM complexities. 153 o In many of the scenarios where reliable transport is deemed 154 important, BGP-based multicast (e.g. BGP-MVPN) has been used 155 instead of PORT. 157 Partly because of the above mentioned problems, some Data Center 158 operators have been avoiding deploying multicast in their networks. 160 BGP-MVPN [RFC6514] uses BGP to signal VPN customer multicast state 161 over provider networks. It removes the above mentioned problems from 162 the SP environment, and the deployment experiences have been 163 encouraging. While RFC 6514 makes it possible for an SP to provide 164 MVPN service without running PIM on its backbone, that RFC still 165 assumes that PIM (or mLDP) runs on the PE-CE links. [draft-ietf-bess- 166 mvpn-pe-ce] adapts the concept of BGP-MVPN to PE-CE links so that the 167 use of PIM on the PE-CE links can be eliminated (though the PIM-ASM 168 complexities still remains in the customer network), and this 169 document extends it further to general topologies, so that they can 170 be run on any router, as a replacement for PIM or mLDP. 172 With that, PIM can be completely eliminated from the network. PIM 173 soft state is replaced by BGP hard state. For ASM, source specific 174 trees are set up directly after simpler source discovery (data driven 175 on FHRs and control driven elsewhere), all based on BGP. All the 176 complexities related to source discovery and shared/source tree 177 switch are also eliminated. Additionally, the trees can be setup 178 with MPLS labels, with just minor enhancements in the signaling. 180 1.1.2. Labeled Multicast 182 There could be two forms of labeled multicast signaled by BGP. The 183 first one is labeled (x,g) multicast where 'x' stands for either 's' 184 or '*'. Basically, it is for BGP-signaled multicast tree as 185 described in previous section but with labels. The second one is for 186 mLDP tunnels with BGP signaling in part or whole through a BGP 187 domain. 189 For both cases, BGP is used because other label distribution 190 mechanisms like mLDP may not be desired by some operators. For 191 example, a DC operator may prefer to have a BGP-only deployment. 193 1.2. Overview 195 1.2.1. (x,g) Multicast 197 PIM-like functionality is provided, using BGP-based join/prune 198 signaling and BGP-based source discovery for ASM. The BGP-based join 199 signaling supports both labeled multicast and IP multicast. 201 The same RPF procedures as in PIM are used for each router to 202 determine the RPF neighbor for a particular source or RPA (in case of 203 Bidirectional Tree). Except in the Bidirectional Tree case and a 204 special case described in Section 1.2.1.2, no (*,G) join is used - 205 LHR routers discover the sources for ASM and then join towards the 206 sources directly. Data driven mechanisms like PIM Assert is replaced 207 by control driven mechanisms (Section 1.2.4). 209 The joins are carried in BGP Updates with MCAST-TREE SAFI and S-PMSI/ 210 Leaf A-D routes defined in this document. The updates are targeted 211 at the upstream neighbor by use of Route Targets. There are three 212 benefits of using S-PMSI/Leaf routes for this purpose: a) when the 213 routes go through RRs, we have to distinguish different routes based 214 on upstream router and downstream router. This leads to Leaf routes. 215 b) for labeled bidirectional trees, we need to signal "upstream fec". 216 S-PMSI suits this very well. c) we may want to allow the option of 217 setting up trees or parts of a tree from the root/upstream towards 218 leaves/downstream and S-PMSI suits that very well. 220 If the BGP updates carry labels (via Tunnel Encapsulation Attribute 221 [I-D.ietf-idr-tunnel-encaps]), then (s,g) multicast traffic can use 222 the labels. This is very similar to mLDP Inband Signaling [RFC6826], 223 except that there are no corresponding "mLDP tunnels" for the PIM 224 trees. Similar to mLDP, labeled traffic on transit LANs are point to 225 point. Of course, traffic sent to receivers on a LAN by a LHR is 226 native multicast. 228 For labeled bidirectional (*,g) trees, downstream traffic (away from 229 the RPA) can be forwarded as in the (s,g) case. For upstream traffic 230 (towards RPA), the upstream neighbor needs to advertise a label for 231 its downstream neighbors. The same label that the upstream neighbor 232 advertises to its upstream is the same one that it advertises to its 233 downstreams, using an S-PMSI A-D route. 235 1.2.1.1. Source Discovery for ASM 237 This document does not support ASM via shared trees (aka RP Tree, or 238 RPT) with one exception discussed in the next section. Instead, 239 FHRs, LHRs, and optionally RRs work together to propagate/discover 240 source information via control plane and LHRs join source specific 241 Shortest Path Trees (SPT) directly. 243 A FHR originates Source Active A-D routes upon discovering sources 244 for particular flows and advertise them to its peers. It is desired 245 that the SA routes only reach LHRs that are interested in receiving 246 the traffic. To achieve that, the SA routes carry an IPv4 or IPv6 247 address specific Route Target. The Global Administrator field is set 248 the group address of the flow, and the Local Administrator field is 249 set to 0. An LHR advertises Route Target Membership routes, with the 250 Route Target field in the NLRI set according to the groups it wants 251 to receive traffic for, as how a FHR encode the Route Target in its 252 Source Active routes. The propagation of the SA routes is subject to 253 cooperative export filtering as specified in [RFC4684] and referred 254 to as RTC mechanism in this document. That way, the LHR only 255 receives Source Active routes for groups that it is interested in. 257 Typically, a set of RRs are used and they maintains all Source Active 258 routes but only distribute to interested LHRs on demand (upon 259 receiving corresponding Route Target Membership routes, which are 260 triggered on LHRs when they receive IGMP/MLD membership routes). The 261 rest of the document assumes that RRs are used, even though that is 262 not required. 264 1.2.1.2. ASM Shared-tree-only Mode 266 It may be desired that only a shared tree is used to distribute all 267 traffic for a particular ASM group from its RP to all LHRs, as 268 described in Section 4.1 "PIM Shared Tree Forwarding" of [RFC7438]. 269 This will significantly cut down the number of trees and works out 270 very well in certain deployment scenarios. For example, all the 271 sources could be connected to the RP, or clustered close to RP. In 272 the latter case, either the path from FHRs to the RP do not intersect 273 the shared tree so native forwarding can be used between the FHRs and 274 the RP, or other means outside of this document could be used to 275 forward traffic from FHRs to the RP. 277 For native forwarding from FHRs to the RP, SA routes may be used to 278 announce the sources so that the RP can join source specific trees to 279 pull traffic, but the group specific Route Target is not needed. The 280 LHRs do not advertise the group specific Route Target Membership 281 routes as they do not need the SA routes. 283 To establish the shared tree, (*,g) Leaf A-D routes are used as in 284 the bidirectional tree case, though no forwarding state is 285 established to forward traffic from downstream neighbors. 287 1.2.1.3. Integration with BGP-MVPN 289 For each VPN, the Source Active routes distribution in that VPN do 290 not have to involve PEs at all unless there are sources/receivers 291 directly connected to some PEs and they are independent of MVPN SA 292 routes. For example, FHRs and LHRs establish BGP sessions with RRs 293 of that particular VPN for the purpose of SA distribution. 295 After source discovery, BGP multicast signaling is done from LHRs 296 towards the sources. When the signaling reaches an egress PE, BGP- 297 MVPN signaling takes over, as if a PIM (s,g) join/prune was received 298 on the PE-CE interface. When the BGP-MVPN signaling reaches the 299 ingress PE, BGP multicast signaling as specified in this document 300 takes over, similar to how BGP-MVPN triggers PIM (s,g) join/prune on 301 PE-CE interfaces. 303 1.2.2. BGP Inband Signaling for mLDP Tunnel 305 Part of an (or the whole) mLDP tunnel can also be signaled via BGP 306 and seamlessly integrated with the rest of mLDP tunnel signaled 307 natively via mLDP. All the procedures are similar to mLDP except 308 that the signaling is done via BGP. The mLDP FEC is encoded as the 309 BGP NLRI, with MCAST-TREE SAFI and S-PMSI/Leaf A-D Routes for 310 C-multicast mLDP defined in this document. The Leaf A-D routes 311 correspond to mLDP Label Mapping messages, and the S-PMSI A-D routes 312 are used to signal upstream FEC for MP2MP mLDP tunnels, similar to 313 the bidirection (*,g) case. 315 1.2.3. BGP Sessions 317 In order for two BGP speakers to exchange MCAST-TREE NLRI, they must 318 use BGP Capabilities Advertisement [RFC5492] to ensure that they both 319 are capable of properly processing the MCAST-TREE NLRI. This is done 320 as specified in [RFC4760], by using a capability code 1 321 (multiprotocol BGP) with an AFI of IPv4 (1) or IPv6 (2) and a SAFI of 322 MCAST-TREE with a value to be assigned by IANA. 324 How the BGP peer sessions are provisioned, whether EBGP or IBGP, 325 whether statically, automatically (e.g., based on IGP neighbor 326 discovery), or programmably via an external controller, is outside 327 the scope of this document. 329 In case of IBGP, it could be that every router peering with Route 330 Reflectors, or hop by hop IBGP sessions could be used to exchange 331 MCAST-TREE NLRIs for joins. In the latter case, unless desired 332 otherwise for reasons outside of the scope of this document, the hop 333 by hop IBGP sessions SHOULD only be used to exchange MCAST-TREE 334 NLRIs. 336 When multihop BGP is used, a router advertises its local interface 337 addresses, for the same purposes that the Address List TLV in LDP 338 serves. This is achieved by advertising the interface address as 339 host prefixes with IPv4/v6 Address Specific ECs corresponding to the 340 router's local addresses used for its BGP sessions (Section 2.1.5). 342 Because the BGP Capability Advertisement is only between two peers, 343 when the sessions are only via RRs, a router needs another way to 344 determine if its neighbor is capable of signaling multicast via BGP. 345 The interface address advertisement can be used for that purpose - 346 the inclusion of a Session Address EC indicates that the BGP speaker 347 identified in the EC supports the C-Multicast NLRI. 349 FHRs and LHRs may also establish BGP sessions to some Route 350 Reflectors for source discovery purpose (Section 1.2.1.1). 352 With the traditional PIM, the FHRs and LHRs refer to the PIM DRs on 353 the source or receiver networks. With BGP based multicast, PIM may 354 not be running at all, and the FHRs and LHRs refer to the IGMP/MLD 355 queriers, or the DF elected per [I-D.wijnands-bier-mld-lan-election]. 356 Alternatively, if it is known that a network only has senders then no 357 IGMP/MLD or DF election is needed - any router may generate SA 358 routes. That will not cause any issue other than redundant SA routes 359 being originated. 361 1.2.4. LAN and Parallel Links 363 There could be parallel links between two BGP peers. A single multi- 364 hop session, whether IBGP or EBGP, between loopback addresses may be 365 used. Except for LAN interfaces in case of unlabeled (x,g) 366 unidirectional trees (note that transit LAN interface is not 367 supported for BGP signaled (*,g) bidirectional tree and for mLDP 368 tunnels, traffic on transit LAN is point to point between neighbors), 369 any link between the two peers can be automatically used by a 370 downstream peer to receive traffic from the upstream peer, and it is 371 for the upstream peer to decide which link to use. If one of the 372 links goes down, the upstream peer switches to a different link and 373 there is no change needed on the downstream peer. 375 For unlabeled (x,g) unidirectional trees, the upstream peer MAY 376 prefer LAN interfaces to send traffic, since multiple downstream 377 peers may be reached simultaneously, or it may make a decision based 378 on local policy, e.g., for load balancing purpose. Because different 379 downstream peers might choose different upstream peers for RPF, when 380 an upstream peer decides to use a LAN interface to send traffic, it 381 originates an S-PMSI A-D route indicating that one or more LAN 382 interface will be used. The route carries Route Targets specific to 383 the LANs so that all the peers on the LANs import the route. If more 384 than one router originate the route specifying the same LAN for the 385 same (s,g) or (*,g) flow, then assert procedure based on the S-PMSI 386 A-D routes happens and assert losers will stop sending traffic to the 387 LAN. 389 1.2.5. Transition 391 A network currently running PIM can be incrementally transitioned to 392 BGP based multicast. At any time, a router supporting BGP based 393 multicast can use PIM with some neighbors (upstream or downstream) 394 and BGP with some other neighbors. PIM and BGP MUST not be used 395 simultaneously between two neighbors for multicast purpose, and 396 routers connected to the same LAN MUST be transitioned during the 397 same maintenance window. 399 In case of PIM-SSM, any router can be transitioned at any time 400 (except on a LAN). It may receive source tree joins from a mixed set 401 of BGP and PIM downstream neighbors and send source tree joins to its 402 upstream neighbor using either PIM or BGP signaling. 404 In case of PIM-ASM, the RPs are first upgraded to support BGP based 405 multicast. They learn sources either via PIM procedures from PIM 406 FHRs, or via Source Active A-D routes from BGP FHRs. In the former 407 case, the RPs can originate proxy Source Active A-D routes. There 408 may be a mixed set of RPs/RRs - some capable of both traditional PIM 409 RP functionalities while some only redistribute SA routes. 411 Then any routers can be transitioned incrementally. A transitioned 412 LHR router will pull Source Active A-D routes from the RPs/RRs when 413 they receive IGMP/MLD (*,G) joins for ASM groups, and may send either 414 PIM (s,g) joins or BGP Source Tree Join routes. A transitioned 415 transit router may receive (*,g) PIM joins but only send source tree 416 joins after pulling Source Active A-D routes from RPs/RRs. 418 Similarly, a network currently running mLDP can be incrementally 419 transitioned to BGP signaling. Without the complication of ASM, any 420 router can be transitioned at any time, even without the restriction 421 of coordinated transition on a LAN. It may receive mixed mLDP label 422 mapping or BGP updates from different downstream neighbors, and may 423 exchange either mLDP label mapping or BGP updates with its upstream 424 neighbors, depending on if the neighbor is using BGP based signaling 425 or not. 427 1.2.6. Inter-region Multicast 429 An end-to-end multicast tree or P2MP tunnel may span multiple 430 regions, where a region could be an IGP area (or even a sub-area) or 431 an Autonomous System (AS). There are several situations to consider. 433 1.2.6.1. Same BGP Signaling Inline across a Region 435 With inline signaling, the multicast tree/tunnel is signaled through 436 the region and internal routers in the region maintain corresponding 437 per-tree/tunnel state. 439 If all routers in the region have route towards the source/root of 440 the tree/tunnel then there is nothing different from the intra-region 441 case. On the other hand, if internal routers do not have route 442 towards the source/root, e.g. BGP-LS is used as in Seamless MPLS, 443 the internal routers need to do RPF towards an upstream Regional 444 Border Router (RBR). To signal the RBR information to an internal 445 upstream router, the Leaf A-D Route carries a new BGP Extended 446 Community referred to as Multicast RPF Address EC, similar to PIM RPF 447 Vector [RFC5496] and mLDP Recursive FEC [RFC6512]. 449 1.2.6.2. Different Signaling Inline across a Region 451 Just like that part of a PIM multicast tree can be signaled as an 452 mLDP P2MP/MP2MP tunnel with mLDP Inband Signaling [RFC6826], BGP- 453 signaled (*/s, g) multicast tree can be signaled with mLDP Inband 454 Signaling or even with PIM across the region, and a BGP-signaled p2mp 455 tunnel can be signaled with mLDP across the region. A RBR will 456 stitch the upstream portion (e.g BGP-signaled) to downstream portion 457 (e.g mLDP-signaled). 459 Depending on whether internal routers have route towards the source/ 460 root, PIM RPF Vector or mLDP Recursive FEC may be used. 462 1.2.6.3. Overlay Signaling Over a Region 464 With overlay signaling, a downstream RBR signals via BGP to its 465 upstream RBR over the region (whether via a RR or not) and the 466 internal routers do not maintain the state of the (overlay) tree/ 467 tunnel. The upstream RBR tunnels packets to the downstream RBR, just 468 as in the intra-region case when two routers on the tree/tunnel are 469 not directly connected. For example, when BGP-LS is used as in 470 Seamless MPLS, a downstream RBR determines that the route towards the 471 source/root has a BGP Next Hop towards a BGP speaker capable of 472 multicast signaling via BGP as specified in this document, so it 473 signals to that BGP speaker (via a RR or not). 475 Suppose an upstream RBR receives the signaling for the same tree/ 476 tunnel from several downstream RBRs. It could use Ingress 477 Replication to replicate packets directly to those downstream RBRs, 478 or it could use underlay P2MP tunnels instead. 480 In the latter case, the upstream RBR advertises an S-PMSI A-D route 481 with a Provider Tunnel Attribute (PTA) specifying the underlay 482 tunnel. This is very much like the "mLDP Over Targeted Sessions" 483 [RFC7060] or BGP-MVPN [RFC6514]. If the mapping between overlay 484 tree/tunnel and underlay tunnel is one-to-one, the MPLS Label field 485 in the PTA is set to 0 or otherwise set to a Domain-wide Common Block 486 (DCB) label [I-D.ietf-bess-mvpn-evpn-aggregation-label] or an 487 upstream-assigned label corresponding to the overlay tree/tunnel. 489 The underlay tunnel, whether P2P to individual downstream RBRs or 490 P2MP to the set of downstream RBRs, can be of any type including 491 Segment Routing (SR) [RFC8402] policies [I-D.ietf-spring-segment- 492 routing-policy] [I-D.voyer-pim-sr-p2mp-policy]. 494 2. Specification 496 2.1. BGP NLRIs and Attributes 498 The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes 499 from multiple different "AFI/SAFIs". This document defines a new 500 SAFI known as a MCAST-TREE SAFI with a value to be assigned by the 501 IANA. This SAFI is used along with the AFI of IPv4 (1) or IPv6 (2). 503 The MCAST-TREE NLRI defined below is carried in the BGP UPDATE 504 messages [RFC4271] using the BGP multiprotocol extensions [RFC4760] 505 with a AFI of IPv4 (1) or IPv6 (2) assigned by IANA and a MCAST-TREE 506 SAFI with a value to be assigned by the IANA. 508 The Next hop field of MP_REACH_NLRI attribute SHALL be interpreted as 509 an IPv4 address whenever the length of the Next Hop address is 4 510 octets, and as an IPv6 address whenever the length of the Next Hop is 511 address is 16 octets. 513 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 514 with a maximum length of 12 octets for IPv4 AFI and 36 octets for 515 IPv6 AFI. The following is the format of the MCAST-TREE NLRI: 517 +-----------------------------------+ 518 | Route Type (1 octet) | 519 +-----------------------------------+ 520 | Length (1 octet) | 521 +-----------------------------------+ 522 | Route Type specific (variable) | 523 +-----------------------------------+ 525 The Route Type field defines encoding of the rest of the MCAST-TREE 526 NLRI. (Route Type specific MCAST-TREE NLRI). 528 The Length field indicates the length in octets of the Route Type 529 specific field of MCAST-TREE NLRI. 531 The following new route types are defined: 533 3 - S-PMSI A-D Route for (x,g) 534 4 - Leaf A-D Route 535 5 - Source Active A-D Route 536 0x43 - S-PMSI A-D Route for C-multicast mLDP 538 Except for the Source Active A-D routes, the routes are to be 539 consumed by targeted upstream/downstream neighbors, and are not 540 propagated further. This can be achieved by outbound filtering based 541 on the RTs that lead to the importation of the routes. 543 The Type-3/4 routes MAY carry a Tunnel Encapsulation Attribute (TEA) 544 [I-D.ietf-idr-tunnel-encaps]. The Type-0x43 route MUST carry a TEA. 545 When used for mLDP, the Type-4 route MUST carry a TEA. Only the MPLS 546 tunnel type for the TEA is considered. Others are outside the scope 547 of this document. 549 2.1.1. S-PMSI A-D Route 551 Similar to defined in RFC 6514, an S-PMSI A-D Route Type specific 552 MCAST-TREE NLRI consists of the following, though it does not have an 553 RD: 555 +-----------------------------------+ 556 | Multicast Source Length (1 octet) | 557 +-----------------------------------+ 558 | Multicast Source (variable) | 559 +-----------------------------------+ 560 | Multicast Group Length (1 octet) | 561 +-----------------------------------+ 562 | Multicast Group (variable) | 563 +-----------------------------------+ 564 | Upstream Router's IP Address | 565 +-----------------------------------+ 567 If the Multicast Source (or Group) field contains an IPv4 address, 568 then the value of the Multicast Source (or Group) Length field is 32. 569 If the Multicast Source (or Group) field contains an IPv6 address, 570 then the value of the Multicast Source (or Group) Length field is 571 128. 573 Usage of other values of the Multicast Source Length and Multicast 574 Group Length fields is outside the scope of this document. 576 There are two usages for S-PMSI A-D route. They're described in 577 Section 2.2.5 and Section 2.2.6 respectively. 579 2.1.2. Leaf A-D Route 581 Similar to the Leaf A-D route in [RFC6514], a MCAST-TREE Leaf A-D 582 route's route key includes the corresponding S-PMSI NLRI, plus the 583 Originating Router's IP Addr. The difference is that there is no RD. 585 +-----------------------------------+ 586 | S-PMSI NLRI | 587 +-----------------------------------+ 588 | Originating Router's IP Address | 589 +-----------------------------------+ 591 For example, the entire NLRI of a Leaf A-D route for (x,g) tree is as 592 following: 594 +- +-----------------------------------+ 595 | | Route Type - 4 (Leaf A-D) | 596 | +-----------------------------------+ 597 | | Length (1 octet) | 598 | +- +-----------------------------------+ --+ 599 | | | Route Type - 3 (S-PMSI A-D) | | 600 L | L | +-----------------------------------+ | S 601 E | E | | Length (1 octet) | | | 602 A | A | +-----------------------------------+ | P 603 F | F | | Multicast Source Length (1 octet) | | M 604 | | +-----------------------------------+ | S 605 N | R | | Multicast Source (variable) | | I 606 L | O | +-----------------------------------+ | 607 R | U | | Multicast Group Length (1 octet) | | N 608 I | T | +-----------------------------------+ | L 609 | E | | Multicast Group (variable) | | R 610 | | +-----------------------------------+ | I 611 | K | | Upstream Router's IP Address | | 612 | E | +-----------------------------------+ --+ 613 | Y | | Originating Router's IP Address | 614 +- +- +-----------------------------------+ 616 Even though the MCAST-TREE Leaf A-D route is unsolicited, unlike the 617 Leaf A-D route for GTM in [RFC7524], it is encoded as if a 618 corresponding S-PMSI A-D route had been received. 620 When used for signaling mLDP tunnels, even though the Leaf A-D route 621 is unsolicited, unlike the "Route-type 0x44 Leaf A-D route for 622 C-multicast mLDP" as in [RFC7441], it is Route-type 4 and encoded as 623 if a corresponding S-PMSI A-D route had been received. 625 2.1.3. Source Active A-D Route 627 Similar to defined in RFC 6514, a Source Active A-D Route Type 628 specific MCAST NLRI consists of the following: 630 +-----------------------------------+ 631 | Multicast Source Length (1 octet) | 632 +-----------------------------------+ 633 | Multicast Source (variable) | 634 +-----------------------------------+ 635 | Multicast Group Length (1 octet) | 636 +-----------------------------------+ 637 | Multicast Group (variable) | 638 +-----------------------------------+ 640 The definition of the source/length and group/length fields are the 641 same as in the S-PMSI A-D routes. 643 Usage of Source Active A-D routes is described in Section 1.2.1.1. 645 2.1.4. S-PMSI A-D Route for C-multicast mLDP 647 The route is used to signal upstream FEC for an MP2MP mLDP tunnel. 648 The route key include the mLDP FEC and the Upstream Router's IP 649 Address field. The encoding is similar to the same route in 650 [RFC7441], though there is no RD. 652 2.1.5. Session Address Extended Community 654 For two BGP speakers to determine if they are directly connected, 655 each will advertise their local interface addresses, with an Session 656 Address Extended Community. This is an IPv4/IPv6 Address Specific EC 657 with the Global Admin Field set to the local address used for its 658 multihop sessions and the Local Admin Field set to the prefix length 659 corresponding to the interface's network mask. 661 For example, if a router has two interfaces with address 662 10.10.10.1/24 and 10.12.0.1/16 respectively (notice the different 663 network mask), and a loopback address 11.11.11.1/32 that is used for 664 BGP sessions, then it will advertise prefix 10.10.10.1/32 with a 665 Session Address EC 11.11.11.1:24 and 10.12.0.1/32 with a Session 666 Address EC 11.11.11.1:16. If it also uses another loopback address 667 11.11.11.11/32 for other BGP sessions, then the routes will 668 additionally carry Session Address EC 11.11.11.11:24 and 669 11.11.11.11:16 respectively. 671 This achieves what the Address List TLV in LDP Address Messages 672 achieves, and can also be used to indicate that a router supports the 673 BGP multicast signaling procedures specified in this document. 675 Only those interface addresses that will be used as resolved nexthops 676 in the RIB need to be advertised with the Session Address EC. For 677 example, the RPF lookup may say that the resolved nexthop address is 678 A1, so the router needs to find out the corresponding BGP speaker 679 with address A1 through the (interface address, session address) 680 mapping built according to the interface address NLRI with the 681 Session Address EC. For comparison with LDP, this is done via the 682 (interface address, session address) mapping that is built by the LDP 683 Address Messages. 685 2.1.6. Multicast RPF Address Extended Community 687 This is an IP or IPv6 Address Specific EC with the Global Admin Field 688 set to the address of the upstream RBR and the Local Admin Field set 689 to 0. 691 2.2. Procedures 693 2.2.1. Source Discovery for ASM 695 When a FHR first receives a multicast packet addressed to an ASM 696 group, it originates a Source Active route. It carries a IP/IPv6 697 Address Specific RT, with the Global Admin Field set to the group 698 address and the Local Admin Field set to 0. The route is advertised 699 to its peers, who will re-advertise further based on the RTC 700 mechanisms. Note that typically the route is advertised only to the 701 RRs. 703 The FHRs withdraws the Source Active route after a certain amount of 704 time since it last received a packet of an (s,g) flow. The amount of 705 time to wait is a local matter. 707 2.2.2. Originating Tree Join Routes 709 Note that in this document, tree join routes are S-PMSI/Leaf A-D 710 routes. 712 2.2.2.1. (x,g) Multicast Tree 714 When a router learns from IGMP/MLD or a downstream PIM/BGP peer that 715 it needs to join a particular (s,g) tree, it determines the RPF 716 nexthop address wrt the source, following the same RPF procedures as 717 defined for PIM. It further finds the BGP router that advertised the 718 nexthop address as one of its local addresses. 720 If the RPF neighbor supports MCAST-TREE SAFI, this router originates 721 a Leaf A-D route. Although it is unsolicited, it is constructed as 722 if there was a corresponding S-PMSI A-D route. The Upstream Router's 723 IP Address field is set to the RPF neighbor's session address (learnt 724 via the EC attached to the host route for the RPF nexthop address). 725 An Address Specific RT corresponding to the session address is 726 attached to the route, with the Global Administrative Field set to 727 the session address and the local administrative field set to 0. 729 Similarly, when a router learns that it needs to join a bi- 730 directional tree for a particular group, it determines the RPF 731 neighbor wrt the RPA. If the neighbor supports MCAST-TREE SAFI, it 732 originates a Leaf A-D Route and advertises the route to the RPF 733 neighbor (in case of EBGP or hop-by-hop IBGP), or one or more RRs. 735 When a router first learns that it needs to receive traffic for an 736 ASM group, either because of a local (*,g) IGMP/MLD report or a 737 downstream PIM (*,g) join, it originates a RTC route with the NLRI's 738 AS field set to its AS number and the Route Target field set to an 739 address based RT, with the Global Administrator field set to group 740 address and the Local Administrator field set to 0. The route is 741 advertised to its peers (most practically some RRs), so that the 742 router can receive matching Source Active A-D routes. Upon the 743 receiving of the Source Active A-D routes, the router originates Leaf 744 A-D routes as described above, as long as it still needs to receive 745 traffic for the flows (i.e., the corresponding IGMP/MLD membership 746 exists or join from downstream PIM/BGP neighbor exists). 748 When a Leaf A-D route is originated by this router, it sets up 749 corresponding forwarding state such that the expected incoming 750 interface list includes all non-LAN interfaces directly connecting to 751 the upstream neighbor. LAN interfaces are added upon receiving 752 corresponding S-PMSI A-D route (Section 2.2.5.2). If the upstream 753 neighbor is not directly connected, tunnels may be used - details to 754 be included in future revisions. 756 When the upstream neighbor changes, the previously advertised Leaf 757 A-D route is withdrawn. If there is a new upstream neighbor, a new 758 Leaf A-D route is originated, corresponding to the new neighbor. 759 Because NLRIs are different for the old and new Leaf A-D routes, 760 make-before-break as well as MoFRR [RFC7431] can be achieved. 762 2.2.2.2. BGP Inband Signaling for mLDP Tunnel 764 The same mLDP procedures as defined in [RFC6388] are followed, except 765 that where a label mapping message is sent in [RFC6388], a Leaf A-D 766 route is sent if the the upstream neighbor supports BGP based 767 signaling. 769 2.2.3. Receiving Tree Join Routes 771 A router (auto-)configures Import RTs matching itself so that it can 772 import tree join routes from their peers. Note that in this 773 document, tree join routes are S-PMSI/Leaf A-D routes. 775 When a router receives a tree join route and imports it, it 776 determines if it needs to originate its own corresponding route and 777 advertise further upstream wrt the source/RPA or mLDP tunnel root. 778 If this router is the FHR or is on the RPL or is the tunnel root, 779 then it does not need to. Otherwise the procedures in Section 2.2.2 780 are followed. 782 Additionally, the router sets up its corresponding forwarding state 783 such that traffic will be sent to the downstream neighbor, and 784 received from the downstream neighbor in case of bidirectional tree/ 785 tunnel. If the downstream neighbor is not directly connected, 786 tunnels may be used - details to be included in future revisions. 788 2.2.4. Withdrawl of Tree Join Routes 790 For a particular tree or tunnel, if a downstream neighbor withdraws 791 its Leaf A-D route, the neighbor is removed from the corresponding 792 forwarding state. If all downstream neighbors withdraw their tree 793 join routes and this router no longer has local receivers, it 794 withdraws the tree join routes that it previously originated. 796 As mentioned earlier, when the upstream neighbor changes, the 797 previously advertised Leaf A-D route is also withdrawn. The 798 corresponding incoming interfaces are also removed from the 799 corresponding forwarding state. 801 2.2.5. LAN procedures for (x,g) Unidirectional Tree 803 For a unidirectional (x,g) multicast tree, if there is a LAN 804 interface connecting to the downstream neighbor, it MAY be preferred 805 over non-LAN interfaces, but an S-PMSI A-D route MUST be originated 806 to facilitate the analog of the Assert process (Section 2.2.5.1). 808 2.2.5.1. Originating S-PMSI A-D Routes 810 If this router chooses to use a LAN interface to send traffic to its 811 neighbors for a particular (s,g) or (*,g) flow, it MUST announce that 812 by originating a corresponding S-PMSI A-D route. The Tunnel Type in 813 the PMSI Tunnel Attribute (PTA) is set to 0 (no tunnel information 814 Present). The LAN interface is identified by an IP address specific 815 RT, with the Global Administrative Field set to the LAN interface's 816 address prefix and the Local Administrative Field set to the prefix 817 length. The RT also serves the purpose of restricting the importing 818 of the route by all routers on the LAN. An operator MUST ensure that 819 RTs encoded as above are not used for other purposes. Practically 820 that should not be unreasonable. 822 If multiple LAN interfaces are to be used (to reach different sets of 823 neighbors), then the route will include multiple RTs, one for each 824 used LAN interface as described above. 826 The S-PMSI A-D routes may also be used to announce tunnels that could 827 be used to send traffic to downstream neighbors that are not directly 828 connected. Details may be added in future revisions. 830 2.2.5.2. Receiving S-PMSI A-D Routes 832 A router (auto-)configures an Import RT for each of its LAN 833 interfaces over which BGP is used for multicast signaling. The 834 construction of the RT is described in the previous section. 836 When a router R1 imports an S-PMSI A-D route for flow (x,g) from 837 router R2, R1 checks to see if it also originating an S-PMSI A-D 838 route with the same NLRI except the Upstream Router's IP Address 839 field. When a router R1 originates an S-PMSI A-D route, it checks to 840 see if it also has installed an S-PMSI A-D route, from some other 841 router R2, with the same NLRI except the Upstream Router's IP Address 842 field. In either case, R1 checks to see if the two routes have an RT 843 in common and the RT is encoded as in Section 2.2.5.1. If so, then 844 there is a LAN attached to both R1 and R2, and both routers are 845 prepared to send (S,G) traffic onto that LAN. This kicks off the 846 assert procedure to elect a winner - the one with the highest 847 Upstream Router's IP Address in the NLRI wins. An assert loser will 848 not include the corresponding LAN interface in its outgoing interface 849 list, but it keeps the S-PMSI A-D route that it originates. 851 If this router does not have a matching S-PMSI route of its own with 852 some common RTs, and the originator of the received S-PMSI route is a 853 chosen upstream neighbor for the corresponding flow, then this router 854 updates its forwarding state to include the LAN interface in the 855 incoming interface list. When the last S-PMSI route with a RT 856 matching the LAN is withdrawn later, the LAN interface is removed 857 from the incoming interface list. 859 Note that a downstream router on the LAN does not participate in the 860 assert procedure. It adds/keeps the LAN interface in the expected 861 incoming interfaces as long as its chosen upstream peer originates 862 the S-PMSI AD route. It does not switch to the assert winner as its 863 upstream. An assert loser MAY keep sending joins upstream based on 864 local policy even if it has no other downstream neighbors (this could 865 be used for fast switch over in case the assert winner would fail). 867 2.2.6. Distributing Label for Upstream Traffic for Bidirectional Tree/ 868 Tunnel 870 For MP2MP mLDP tunnels or labeled (*,g) bidirectional trees, an 871 upstream router needs to advertise a label to all its downstream 872 neighbors so that the downstream neighbors can send traffic to 873 itself. 875 For MP2MP mLDP tunnels, the same procedures for mLDP are followed 876 except that instead of MP2MP-U Label Mapping messages, S-PMSI A-D 877 Routes for C-Multicast mLDP are used. 879 For labeled (*,g) bidirectional trees, for a Leaf A-D route received 880 from a downstream neighbor, a corresponding S-PMSI A-D route is sent 881 back to the downstream router. 883 In both cases, a single S-PMSI A-D route is originated for each tree 884 from this router, but with multiple RTs (one for each downstream 885 neighbor on the tree). A TEA specifies a label allocated by the 886 upstream router for its downstream neighbors to send traffic with. 887 Note that this is still a "downstream allocated" label (the upstream 888 router is "downstream" from traffic direction point of view). 890 The S-PMSI routes do not carry a PTA, unless a P2MP tunnel is used to 891 reach downstream neighbors. Such use case is out of scope of this 892 document for now and may be specified in the future. 894 3. IANA Considerations 896 This document requests IANA to assign a new BGP SAFI value for the 897 MCAST-TREE SAFI. 899 This document requests IANA to create a new "BGP MCAST-TREE Route 900 Types" registry, referencing this document. The following initial 901 values are defined: 903 0~2 - Reserved 904 3 - S-PMSI A-D Route for (x,g) 905 4 - Leaf A-D Route 906 5 - Source Active A-D Route 907 0x43 - S-PMSI A-D Route for C-multicast mLDP 909 This document requests IANA to assign two Sub-type values from 910 Transitive IPv4-Address-Specific Extended Community Sub-types 911 Registry for Session Address EC and Multicast RPF Address EC 912 respectively. 914 This document requests IANA to assign two Type values from Transitive 915 IPv6-Address-Specific Extended Community Types Registry for Session 916 Address EC and Multicast RPF Address EC respectively. 918 4. Security Considerations 920 This document does not introduce new security risks. 922 5. Acknowledgements 924 The authors thank Marco Rodrigues for his initial idea/ask of using 925 BGP for multicast signaling beyond MVPN. We thank Eric Rosen for his 926 questions, suggestions, and help finding solutions to some issues. 927 We also thank Luay Jalil and James Uttaro for their comments and 928 support for the work. 930 6. References 932 6.1. Normative References 934 [I-D.ietf-idr-tunnel-encaps] 935 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 936 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 937 (work in progress), December 2019. 939 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 940 Requirement Levels", BCP 14, RFC 2119, 941 DOI 10.17487/RFC2119, March 1997, 942 . 944 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 945 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 946 Protocol Specification (Revised)", RFC 4601, 947 DOI 10.17487/RFC4601, August 2006, 948 . 950 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 951 R., Patel, K., and J. Guichard, "Constrained Route 952 Distribution for Border Gateway Protocol/MultiProtocol 953 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 954 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 955 November 2006, . 957 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 958 "Bidirectional Protocol Independent Multicast (BIDIR- 959 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 960 . 962 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 963 Encodings and Procedures for Multicast in MPLS/BGP IP 964 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 965 . 967 [RFC7441] Wijnands, IJ., Rosen, E., and U. Joorde, "Encoding 968 Multipoint LDP (mLDP) Forwarding Equivalence Classes 969 (FECs) in the NLRI of BGP MCAST-VPN Routes", RFC 7441, 970 DOI 10.17487/RFC7441, January 2015, 971 . 973 6.2. Informative References 975 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 976 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 977 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 978 ietf-bess-mvpn-evpn-aggregation-label-03 (work in 979 progress), October 2019. 981 [I-D.ietf-bess-mvpn-pe-ce] 982 Patel, K., Rosen, E., and Y. Rekhter, "BGP as an MVPN PE- 983 CE Protocol", draft-ietf-bess-mvpn-pe-ce-01 (work in 984 progress), October 2015. 986 [I-D.ietf-spring-segment-routing-policy] 987 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 988 P. Mattes, "Segment Routing Policy Architecture", draft- 989 ietf-spring-segment-routing-policy-06 (work in progress), 990 December 2019. 992 [I-D.voyer-pim-sr-p2mp-policy] 993 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 994 Zhang, "Segment Routing Point-to-Multipoint Policy", 995 draft-voyer-pim-sr-p2mp-policy-01 (work in progress), 996 April 2020. 998 [I-D.wijnands-bier-mld-lan-election] 999 Wijnands, I., Pfister, P., and Z. Zhang, "Generic 1000 Multicast Router Election on LAN's", draft-wijnands-bier- 1001 mld-lan-election-01 (work in progress), July 2016. 1003 [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path 1004 Forwarding (RPF) Vector TLV", RFC 5496, 1005 DOI 10.17487/RFC5496, March 2009, 1006 . 1008 [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, 1009 "Using Multipoint LDP When the Backbone Has No Route to 1010 the Root", RFC 6512, DOI 10.17487/RFC6512, February 2012, 1011 . 1013 [RFC6826] Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M. 1014 Napierala, "Multipoint LDP In-Band Signaling for Point-to- 1015 Multipoint and Multipoint-to-Multipoint Label Switched 1016 Paths", RFC 6826, DOI 10.17487/RFC6826, January 2013, 1017 . 1019 [RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP 1020 Multipoint Extensions on Targeted LDP Sessions", RFC 7060, 1021 DOI 10.17487/RFC7060, November 2013, 1022 . 1024 [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. 1025 Decraene, "Multicast-Only Fast Reroute", RFC 7431, 1026 DOI 10.17487/RFC7431, August 2015, 1027 . 1029 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 1030 BGP for Routing in Large-Scale Data Centers", RFC 7938, 1031 DOI 10.17487/RFC7938, August 2016, 1032 . 1034 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1035 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1036 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1037 July 2018, . 1039 Authors' Addresses 1041 Zhaohui Zhang 1042 Juniper Networks 1044 EMail: zzhang@juniper.net 1046 Lenny Giuliano 1047 Juniper Networks 1049 EMail: lenny@juniper.net 1050 Keyur Patel 1051 Arrcus 1053 EMail: keyur@arrcus.com 1055 IJsbrand Wijnands 1056 Cisco Systems 1058 EMail: ice@cisco.com 1060 Mankamana Mishra 1061 Cisco Systems 1063 EMail: mankamis@cisco.com 1065 Arkadiy Gulko 1066 Refinitiv 1068 EMail: arkadiy.gulko@refinitiv.com