idnits 2.17.1 draft-zzhang-bess-bgp-multicast-controller-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 18, 2019) is 1620 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: 'RFC5331' is mentioned on line 242, but not defined == Unused Reference: 'RFC6513' is defined on line 524, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-14 == Outdated reference: A later version (-11) exists of draft-ietf-idr-wide-bgp-communities-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track R. Raszuk 5 Expires: May 21, 2020 Bloomberg LP 6 D. Pacella 7 Verizon 8 A. Gulko 9 Thomson Reuters 10 November 18, 2019 12 Controller Based BGP Multicast Signaling 13 draft-zzhang-bess-bgp-multicast-controller-02 15 Abstract 17 This document specifies a way that one or more centralized 18 controllers can use BGP to set up a multicast distribution tree in a 19 network. In the case of labeled tree, the labels are assigned by the 20 controllers either from the controllers' local label spaces, or from 21 a common Segment Routing Global Block (SRGB), or from each routers 22 Segment Routing Local Block (SRLB) that the controllers learn. In 23 case of labeled unidirectional tree and label allocation from the 24 common SRGB or from the controllers' local spaces, a single common 25 label can be used for all routers on the tree to send and receive 26 traffic with. Since the controllers calculate the trees, they can 27 use sophisticated algorithms and constraints to achieve traffic 28 engineering. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in BCP 35 14 [RFC2119] [RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on May 21, 2020. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 74 1.2. Resilience . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.4. Label Allocation . . . . . . . . . . . . . . . . . . . . 5 77 1.4.1. Using a Common per-tree Label for All Routers . . . . 6 78 1.4.2. Upstream-assignment from Controller's Local Label 79 Space . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1.5. Determining Root/Leaves . . . . . . . . . . . . . . . . . 8 81 1.5.1. PIM-SSM/Bidir or mLDP P2MP . . . . . . . . . . . . . 9 82 1.5.2. PIM ASM . . . . . . . . . . . . . . . . . . . . . . . 9 83 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9 84 2.1. Additional Tunnel Types for TEA . . . . . . . . . . . . . 9 85 2.1.1. Any-Encapsulation Tunnel . . . . . . . . . . . . . . 9 86 2.1.2. Load-balancing Tunnel . . . . . . . . . . . . . . . . 10 87 2.2. RPF Label Stack Sub-TLV . . . . . . . . . . . . . . . . . 10 88 2.3. Context Label Wide Community . . . . . . . . . . . . . . 10 89 2.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 90 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 91 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 92 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 93 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 95 6.2. Informative References . . . . . . . . . . . . . . . . . 12 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 99 1. Overview 101 1.1. Introduction 103 [I-D.zzhang-bess-bgp-multicast] describes a way to use BGP as a 104 replacement signaling for PIM [RFC7761] or mLDP [RFC6388]. The BGP- 105 based multicast signaling described there provides a mechanism for 106 setting up both (s,g)/(*,g) multicast trees (as PIM does, but 107 optionally with labels) and labeled (MPLS) multicast tunnels (as mLDP 108 does). Each router on a tree performs essentially the same 109 procedures as it would perform if using PIM or mLDP, but all the 110 inter-router signaling is done using BGP. 112 These procedures allow the routers to set up a separate tree for each 113 individual multicast (x,g) flow where the 'x' could be either 's' or 114 '*', but they also allow the routers to set up trees that are used 115 for more than one flow. In the latter case, the trees are often 116 referred to as "multicast tunnels" or "multipoint tunnels", and 117 specifically in this document they are mLDP tunnels (except that they 118 are set up with BGP signaling). While it actually does not have to 119 be restricted to mLDP tunnels, mLDP FEC is conveniently borrowed to 120 identify the tunnel. In the rest of the document, the term tree and 121 tunnel are used interchangeably. 123 The trees/tunnels are set up using the "receiver-initiated join" 124 technique of PIM/mLDP, hop by hop from downstream routers towards the 125 root. The BGP messages are either sent hop by hop between downstream 126 routers and their upstream neighbors, or can be reflected by Route 127 Reflectors (RRs). 129 As an alternative to each hop independently determining its upstream 130 router and signaling upstream towards the root (following PIM/mLDP 131 model), the entire tree can be calculated by a centralized 132 controller, and the signaling can be entirely done from the 133 controller, using the same BGP messages as defined in 134 [I-D.zzhang-bess-bgp-multicast]. For that, some additional 135 procedures and optimizations are specified in this document. 137 While it is outside the scope of this document, signaling from the 138 controllers could be done via other means as well, like Netconf or 139 any other SDN methods. 141 1.2. Resilience 143 Each router could establish direct BGP sessions with one or more 144 controllers, or it could establish BGP sessions with RRs who in turn 145 peer with controllers. For the same tree/tunnel, each controller may 146 independently calculate the tree/tunnel and signal the routers on the 147 tree/tunnel using MCAST-TREE S-PMSI/Leaf A-D routes 148 [I-D.zzhang-bess-bgp-multicast]. How the tree/tunnel roots/leaves 149 are discovered and how the calculation is done are outside the scope 150 of this document. 152 On each router, BGP route selection rules will lead to one 153 controller's route for the tree/tunnel being selected as the active 154 route and used for setting up forwarding state. As long as all the 155 routers on a tree/tunnel consistently pick the same controller's 156 routes for the tree/tunnel, the setup should be consistent. If the 157 tree/tunnel is labeled, different labels will be used from different 158 controllers so there is no traffic loop issue even if the routers do 159 not consistently select the same controlle's routes. In the 160 unlabeled case, to ensure the consistency the selection SHOULD be 161 solely based on the identifier of the controller, which could be 162 carried in an Address Specific Extended Community (EC). 164 Another consistency issue is when a bidirectional tree/tunnel needs 165 to be re-routed. Because this is no longer triggered hop-by-hop from 166 downstream to upstream, it is possible that the upstream change 167 happens before the downstream, causing traffic loop. In the 168 unlabeled case, there is no good solution (other than that the 169 controller issues upstream change only after it gets acknowledgement 170 from downstream). In the labeled case, as long as a new label is 171 used there should be no problem. 173 Besides the traffic loop issue, there could be transient traffic loss 174 before both the upstream and downstream's forwarding state are 175 updated. This could be mitigated if the upstream keep sending 176 traffic on the old path (in addition to the new path) and the 177 downstream keep accepting traffic on the old path (but not on the new 178 path) for some time. It is a local matter when for the downstream to 179 switch to the new path - it could be data driven (e.g., after traffic 180 arrives on the new path) or timer driven. 182 For each tree, multiple disjoint instances could be calculated and 183 signaled for live-live protection. Different labels are used for 184 different instances, so that the leaves can differentiate incoming 185 traffic on different instances. As far as transit routers are 186 concerned, the instances are just independent. Note that the two 187 instances are not expected to share common transit routers (it is 188 otherwise outside the scope of this document/revision). 190 1.3. Signaling 192 Each router only receives S-PMSI/Leaf A-D routes from the controllers 193 but does not originate or re-advertise those routes. The re- 194 advertisement of a received route can be blocked based on the fact 195 that a configured import RT matches the RT of the route, which 196 indicates that this router is the target and consumer of the route 197 hence it should not be re-advertised further. The routes includes 198 the outgoing forwarding information in the form of Tunnel 199 Encapsulation Attributes (TEA) [I-D.ietf-idr-tunnel-encaps], with 200 optional enhancements specified in this document. The router infers 201 the incoming forwarding information from the Upstream Router's IP 202 Address field in the NLRI in case of an unlabeled tree. 204 Suppose that for a particular tree, there are two downstream routers 205 D1 and D2 for a particular upstream router U. A controller C may 206 send two Leaf A-D routes to U, as if the two routes were originated 207 by D1 and D2 but reflected by the controller. As an alternative in 208 case of a labeled tree, C could just send one route to U, with a TEA 209 specifying both downstreams. In this case, the Originating Router's 210 Address field of the Leaf A-D route is set to the controller's 211 address. Note that for a TEA attached to a unicast NLRI, only one of 212 the tunnels in a TEA is used for forwarding a particular packet, 213 while all the tunnels in a TEA are used to reach multiple endpoints 214 when it is attached to a multicast NLRI. 216 Note that, in case of labeled trees, the (x,g) or mLDP FEC signaling 217 is actually not needed to transit routers but only needed on tunnel 218 root/leaves. However, for consistency, the same signaling is used to 219 all routers. 221 1.4. Label Allocation 223 In the case of labeled multicast signaled hop by hop towards the 224 root, whether it's (x,g) multicast or "mLDP" tunnel, labels are 225 assigned by a downstream router and advertised to its upstream router 226 (from traffic direction point of view). In the case of controller 227 based signaling, routers do not originate tree join (S-PMSI/Leaf A-D) 228 routes anymore, so the controllers have to assign labels on behalf of 229 routers, and there are three options for label assignment: 231 o From each router's SRLB that the controller learns 233 o From the common SRGB that the controller learns 235 o From the controller's local label space 236 Assignment from each router's SRLB is no different from each router 237 assigning labels from its own local label space in the hop-by-hop 238 signaling case. The assignments for a router is independent of 239 assignments for another router, even for the same tree. 241 Assignment from the controller's local label space is upstream- 242 assigned [RFC5331]. It is used if the controller does not learn the 243 common SRGB or each router's SRLB. Assignment from the SRGB 244 [RFC8402] is only meaningful if all SRGBs are the same and a single 245 common label is used for all the routers on a tree in case of 246 unidirectional tree/tunnel (Section 1.4.1). Otherwise, assignment 247 from SRLB is preferred. 249 The choice of which of the options to use depends on many factors. 250 An operator may want to use a single common label per tree for ease 251 of monitoring and debugging, but that requires explicit RPF checking 252 and either SRGB or upstream assigned labels, which may not be 253 supported due to either the software or hardware limitations (e.g. 254 label imposition/disposition limits). In an SR network, assignment 255 from the common SRGB if it's required to use a single common label 256 per unidirectional tree, or otherwise assignment from SRLB is a good 257 choice because it does not require support for context label spaces. 259 1.4.1. Using a Common per-tree Label for All Routers 261 MPLS labels only have local significance. For an LSP that goes 262 through a series of routers, each router allocates a label 263 independently and it swaps the incoming label (that it advertised to 264 its upstream) to an outgoing label (that it received from its 265 downstream) when it forwards a labeled packet. Even if the incoming 266 and outgoing labels happen to be the same on a particular router, 267 that is just incidental. 269 With Segment Routing, it is becoming a common practice that all 270 routers use the same SRGB so that a SID maps to the same label on all 271 routers. This makes it easier for operators to monitor and debug 272 their network. The same concept applies to multicast trees as well - 273 a common per-tree label is used for a router to receive traffic from 274 its upstream neighbor and replicate traffic to all its downstream 275 neighbor. 277 However, a common per-tree label can only be used for unidirectional 278 trees. Additionally, it requires each router to do explicit RPF 279 check, so that only packets from its expected upstream neighbor are 280 accepted. Otherwise, traffic loop may form during topology changes, 281 because the forwarding state update is no longer ordered. 283 Traditionally, p2mp mpls forwarding does not require explicit RPF 284 check as a downstream router advertises a label only to its upstream 285 router and all traffic with that incoming label is presumed to be 286 from the upstream router and accepted. When a downstream router 287 switches to a different upstream router a different label will be 288 advertised, so it can determine if traffic is from its expected 289 upstream neighbor purely based on the label. Now with a single 290 common label used for all routers on a tree to send and receive 291 traffic with, a router can no longer determine if the traffic is from 292 its expected neighbor just based on that common tree label. 293 Therefore, explicit RPF check is needed. Instead of interface based 294 RPF checking as in PIM case, neighbor based RPF checking is used - a 295 label identifying the upstream neighbor precedes the tree label and 296 the receiving router checks if that preceding neighbor label matches 297 its expected upstream neighbor. Notice that this is similar to 298 what's described in Section "9.1.1 Discarding Packets from Wrong PE" 299 of RFC 6513 (an egress PE discards traffic sent from a wrong ingress 300 PE). The only difference is one is used for label based forwarding 301 and the other is used for (s,g) based forwarding. [note: for 302 bidirectional trees, we may be able to use two labels per tree - one 303 for upstream traffic and one for downstream traffic. This needs 304 further verification]. 306 Both the common per-tree label and the neighbor label are allocated 307 either from the common SRGB or from the controller's local label 308 space. In the latter case, an additional label identifying the 309 controller's label space is needed, as described in the following 310 section. 312 1.4.2. Upstream-assignment from Controller's Local Label Space 314 In this case in the multicast packet's label stack the tree label and 315 upstream neighbor label (if used in case of single common-label per 316 tree) are preceded by a downstream-assigned "context label". The 317 context label identifies a context-specific label space (the 318 controller's local label space), and the upstream-assigned label that 319 follows it is looked up in that space. 321 This specification requires that, in case of upstream-assignment from 322 a controller's local label space, each router D to assign, 323 corresponding to each controller C, a context label that identifies 324 the upstream-assigned label space used by that controller. This 325 label, call it Lc-D, is communicated by D to C. 327 Suppose a controller is setting up unidirectional tree T. It assigns 328 that tree the label Lt, and assigns label Lu to identify router U 329 which is the upstream of router D on tree T. C needs to tell U: "to 330 send a packet on the given tree/tunnel, one of the things you have to 331 do is push Lt onto the packet's label stack, then push Lu, then push 332 Lc-D onto the packet's label stack, then unicast the packet to D". 333 Controller C also needs to inform router D of the correspondence 334 between and tree T. 336 To achieve that, when C sends an S-PMSI/Leaf A-D route, for each 337 tunnel in the TEA, it includes a label stack Sub-TLV 338 [I-D.ietf-idr-tunnel-encaps], with the outer label being the context 339 label Lc-D (received by the controller from the corresponding 340 downstream), the next label being the upstream neighbor label Lu, and 341 the inner label being the label Lt assigned by the controller for the 342 tree. The router receiving the route will use the label stacks to 343 send traffic to its downstreams. 345 For C to signal the expected label stack for D to receive traffic 346 with, we overload a tunnel TLV in the TEA of the Leaf A-D route sent 347 to D - if the remote endpoint of that tunnel TLV matches the Upstream 348 Router field in the Leaf A-D route, then it indicates that this is 349 actually for receiving traffic from the upstream. If a common tree 350 label is used, then the TLV contains a variant of the Label Stack 351 Sub-TLV because the D needs to treat the second inner most label as 352 the upstream neighbor label and set up forwarding state accordingly 353 for explicit RPF check. This variant is referred to as RPF Label 354 Stack Sub-TLV (Section 2.2). 356 Note that the use of TEA to specify downstream and upstream 357 forwarding information also apply to label assignment from the common 358 SRGB or each router's SRLB, with the differences that the context 359 label is not needed in the SRGB/SRLB case, and that in SRLB case only 360 a Label Stack Sub-TLV with a single SRLB label is used for upstream 361 and downstream forwarding information (no RPF Label Stack Sub-TLV is 362 needed) in the SRLB case. 364 1.5. Determining Root/Leaves 366 For the controller to calculate a tree, it needs to determine the 367 root and leaves of the tree. This may be based on provisioning 368 (static or dynamically programmed), or based on BGP signaling using 369 the BGP multicast messages defined in 370 [I-D.zzhang-bess-bgp-multicast], as described in the following two 371 sections. 373 In both cases, the BGP updates are targeted at the controller, via an 374 address specific Route Target with Global Administration Field set to 375 the controller's address and the Local Administration Field set to 0. 377 1.5.1. PIM-SSM/Bidir or mLDP P2MP 379 In this case, the PIM Last Hop Routers (LHRs) with interested 380 receivers or mLDP P2MP tunnel leaves encode a Leaf A-D route with the 381 Upstream Router's IP Address field set to the controller's address 382 and the Originating Router's IP Address set to the address of the LHR 383 or the P2MP tunnel leaf. The encoded PIM SSM source or mLDP FEC 384 provides root information and the Originating Router's IP Address 385 provides leaves information. 387 1.5.2. PIM ASM 389 In this case, the First Hop Routers (FHRs) originate Source Active 390 routes which provides root information, and the LHRs originate Leaf 391 A-D routes, encoded as in the PIM-SSM case except that it is (*,G) 392 instead of (S,G). The Leaf A-D routes provide leaf information. 394 2. Specification 396 2.1. Additional Tunnel Types for TEA 398 This document specifies two new Tunnel Types. The type codes will be 399 assigned by IANA from the "BGP Tunnel Encapsulation Attribute Tunnel 400 Types". 402 2.1.1. Any-Encapsulation Tunnel 404 When a multicast packet needs to be sent from an upstream node to a 405 downstream node, it may not matter how it is sent - natively when the 406 two nodes are directly connected or tunneled otherwise. In case of 407 tunneling, it may not matter what kind of tunnel is used - MPLS, GRE, 408 IPinIP, or whatever. 410 To support this, an "Any-Encapsulation" tunnel type is defined. This 411 tunnel MUST have a Tunnel Endpoint Sub-TLV and SHOULD NOT have any 412 other Sub-TLVs. The Tunnel Endpoint Sub-TLV specifies an IP address, 413 which could be any of the following: 415 o An interface's local address - when a packet needs to sent out of 416 the corresponding interface natively. 418 o An interface's remote address - when a packet needs to sent to the 419 address natively. 421 o An address that is not directly connected - when a packet needs to 422 be tunneled to the address (any tunnel type/instance can be used). 424 2.1.2. Load-balancing Tunnel 426 Consider that a multicast packet needs to be sent to a downstream 427 node, which could be reached via four paths P1~P4. If it does not 428 matter which of path is taken, an "Any-Encapsulation" tunnel with the 429 Tunnel Endpoint Sub-TLV specifying the downstream node's loopback 430 address works well. If the controller wants to specify that only 431 P1~P2 should be used, then a "Load-balancing" tunnel needs to be 432 used, listing P1 and P2 as member tunnels of the "Load-balancing" 433 tunnel. 435 A load-balancing tunnel has one "Member Tunnels" Sub-TLV defined in 436 this document. The Sub-TLV is a list of tunnels, each specifying a 437 way to reach the downstream. A packet will be sent out of one of the 438 tunnels listed in the Member Tunnels Sub-TLV of the load-balancing 439 tunnel. 441 2.2. RPF Label Stack Sub-TLV 443 This is almost identical to Label Stack Sub-TLV. The only difference 444 is that the second inner most label in the stack identifies the 445 expected upstream neighbor and explicit RPF checking needs to be set 446 up for the tree label accordingly. 448 2.3. Context Label Wide Community 450 For a router to signal the context label that it assigns for a 451 controller (or any label allocator that assigns labels that will be 452 seen by this router), it attaches a Context Label Wide Community 453 [I-D.ietf-idr-wide-bgp-communities] to the host route for its own 454 address used in its BGP session towards the controllers (directly or 455 via RRs). This is a new wide community that specifies the (Label 456 Allocator, Context Label) tuple, and the exact format will be 457 specified in a future revision. 459 2.4. Procedures 461 Details to be added. The general idea is described in the 462 introduction section. 464 3. Security Considerations 466 This document does not introduce new security risks. 468 4. IANA Considerations 470 This document makes the following IANA requests: 472 o "Any-Encapsulation" and "Load-balancing" tunnel types from the 473 "BGP Tunnel Encapsulation Attribute Tunnel Types" registry 475 o "Member Tunnels" and "RPF Label Stack" sub-TLV types from the "BGP 476 Tunnel Encapsulation Attribute Sub-TLVs" registry 478 o 480 5. Acknowledgements 482 The authors Eric Rosen for his questions, suggestions, and help 483 finding solutions to some issues like the neighbor based explicit RPF 484 checking. The authors also thank Lenny Giuliano, Sanoj Vivekanandan 485 and IJsbrand Wijnands for their review and comments. 487 6. References 489 6.1. Normative References 491 [I-D.ietf-idr-tunnel-encaps] 492 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 493 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-14 494 (work in progress), September 2019. 496 [I-D.ietf-idr-wide-bgp-communities] 497 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 498 and P. Jakma, "BGP Community Container Attribute", draft- 499 ietf-idr-wide-bgp-communities-05 (work in progress), July 500 2018. 502 [I-D.zzhang-bess-bgp-multicast] 503 Zhang, Z., Giuliano, L., Patel, K., Wijnands, I., mishra, 504 m., and A. Gulko, "BGP Based Multicast", draft-zzhang- 505 bess-bgp-multicast-03 (work in progress), October 2019. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, 509 DOI 10.17487/RFC2119, March 1997, 510 . 512 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 513 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 514 May 2017, . 516 6.2. Informative References 518 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 519 Thomas, "Label Distribution Protocol Extensions for Point- 520 to-Multipoint and Multipoint-to-Multipoint Label Switched 521 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 522 . 524 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 525 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 526 2012, . 528 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 529 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 530 Multicast - Sparse Mode (PIM-SM): Protocol Specification 531 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 532 2016, . 534 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 535 Decraene, B., Litkowski, S., and R. Shakir, "Segment 536 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 537 July 2018, . 539 Authors' Addresses 541 Zhaohui Zhang 542 Juniper Networks 544 EMail: zzhang@juniper.net 546 Robert Raszuk 547 Bloomberg LP 549 EMail: robert@raszuk.net 551 Dante Pacella 552 Verizon 554 EMail: dante.j.pacella@verizon.com 556 Arkadiy Gulko 557 Thomson Reuters 559 EMail: arkadiy.gulko@thomsonreuters.com