idnits 2.17.1 draft-ietf-bess-bgp-multicast-controller-06.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 2 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 -- The document date (February 19, 2021) is 1162 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 285, but not defined == Missing Reference: 'RFC 7752' is mentioned on line 368, but not defined ** Obsolete undefined reference: RFC 7752 (Obsoleted by RFC 9552) == Missing Reference: 'RFC6514' is mentioned on line 508, but not defined == Unused Reference: 'RFC6513' is defined on line 1006, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-bess-bgp-multicast-03 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-21 == Outdated reference: A later version (-11) exists of draft-ietf-idr-wide-bgp-communities-05 Summary: 1 error (**), 0 flaws (~~), 10 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: August 23, 2021 NTT Network Innovations 6 D. Pacella 7 Verizon 8 A. Gulko 9 Edward Jones Wealth Management 10 February 19, 2021 12 Controller Based BGP Multicast Signaling 13 draft-ietf-bess-bgp-multicast-controller-06 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 August 23, 2021. 55 Copyright Notice 57 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . 6 77 1.4.1. Using a Common per-tree Label for All Routers . . . . 7 78 1.4.2. Upstream-assignment from Controller's Local Label 79 Space . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1.5. Determining Root/Leaves . . . . . . . . . . . . . . . . . 9 81 1.5.1. PIM-SSM/Bidir or mLDP . . . . . . . . . . . . . . . . 9 82 1.5.2. PIM ASM . . . . . . . . . . . . . . . . . . . . . . . 9 83 1.6. Multiple Domains . . . . . . . . . . . . . . . . . . . . 9 84 1.7. SR-P2MP . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 2. Alternative to BGP-MVPN . . . . . . . . . . . . . . . . . . . 11 86 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 12 87 3.1. Enhancements to TEA . . . . . . . . . . . . . . . . . . . 12 88 3.1.1. Any-Encapsulation Tunnel . . . . . . . . . . . . . . 12 89 3.1.2. Load-balancing Tunnel . . . . . . . . . . . . . . . . 13 90 3.1.3. Receiving MPLS Label Stack . . . . . . . . . . . . . 13 91 3.1.4. RPF Sub-TLV . . . . . . . . . . . . . . . . . . . . . 14 92 3.1.5. Tree Label Stack sub-TLV . . . . . . . . . . . . . . 14 93 3.1.6. Backup Tunnel sub-TLV . . . . . . . . . . . . . . . . 15 94 3.2. Context Label TLV in BGP-LS Node Attribute . . . . . . . 15 95 3.3. SR P2MP Signaling . . . . . . . . . . . . . . . . . . . . 16 96 3.3.1. S-PMSI A-D Route for SR P2MP . . . . . . . . . . . . 16 97 3.3.2. S-PMSI A-D Route for Encoding Label/SID . . . . . . . 17 98 3.3.3. BGP Community Container for SR P2MP Policy . . . . . 18 99 3.3.4. SR Policy Tunnel Type . . . . . . . . . . . . . . . . 19 100 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 102 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 103 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 106 8.2. Informative References . . . . . . . . . . . . . . . . . 22 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 109 1. Overview 111 1.1. Introduction 113 [I-D.ietf-bess-bgp-multicast] describes a way to use BGP as a 114 replacement signaling for PIM [RFC7761] or mLDP [RFC6388]. The BGP- 115 based multicast signaling described there provides a mechanism for 116 setting up both (s,g)/(*,g) multicast trees (as PIM does, but 117 optionally with labels) and labeled (MPLS) multicast tunnels (as mLDP 118 does). Each router on a tree performs essentially the same 119 procedures as it would perform if using PIM or mLDP, but all the 120 inter-router signaling is done using BGP. 122 These procedures allow the routers to set up a separate tree for each 123 individual multicast (x,g) flow where the 'x' could be either 's' or 124 '*', but they also allow the routers to set up trees that are used 125 for more than one flow. In the latter case, the trees are often 126 referred to as "multicast tunnels" or "multipoint tunnels", and 127 specifically in this document they are mLDP tunnels (except that they 128 are set up with BGP signaling). While it actually does not have to 129 be restricted to mLDP tunnels, mLDP FEC is conveniently borrowed to 130 identify the tunnel. In the rest of the document, the term tree and 131 tunnel are used interchangeably. 133 The trees/tunnels are set up using the "receiver-initiated join" 134 technique of PIM/mLDP, hop by hop from downstream routers towards the 135 root. The BGP messages are either sent hop by hop between downstream 136 routers and their upstream neighbors, or can be reflected by Route 137 Reflectors (RRs). 139 As an alternative to each hop independently determining its upstream 140 router and signaling upstream towards the root (following PIM/mLDP 141 model), the entire tree can be calculated by a centralized 142 controller, and the signaling can be entirely done from the 143 controller, using the same BGP messages as defined in 145 [I-D.ietf-bess-bgp-multicast]. For that, some additional procedures 146 and optimizations are specified in this document. 148 While it is outside the scope of this document, signaling from the 149 controllers could be done via other means as well, like Netconf or 150 any other SDN methods. 152 1.2. Resilience 154 Each router could establish direct BGP sessions with one or more 155 controllers, or it could establish BGP sessions with RRs who in turn 156 peer with controllers. For the same tree/tunnel, each controller may 157 independently calculate the tree/tunnel and signal the routers on the 158 tree/tunnel using MCAST-TREE Leaf A-D routes 159 [I-D.ietf-bess-bgp-multicast]. How the tree/tunnel roots/leaves are 160 discovered and how the calculation is done are outside the scope of 161 this document. 163 On each router, BGP route selection rules will lead to one 164 controller's route for the tree/tunnel being selected as the active 165 route and used for setting up forwarding state. As long as all the 166 routers on a tree/tunnel consistently pick the same controller's 167 routes for the tree/tunnel, the setup should be consistent. If the 168 tree/tunnel is labeled, different labels will be used from different 169 controllers so there is no traffic loop issue even if the routers do 170 not consistently select the same controlle's routes. In the 171 unlabeled case, to ensure the consistency the selection SHOULD be 172 solely based on the identifier of the controller, which could be 173 carried in an Address Specific Extended Community (EC). 175 Another consistency issue is when a bidirectional tree/tunnel needs 176 to be re-routed. Because this is no longer triggered hop-by-hop from 177 downstream to upstream, it is possible that the upstream change 178 happens before the downstream, causing traffic loop. In the 179 unlabeled case, there is no good solution (other than that the 180 controller issues upstream change only after it gets acknowledgement 181 from downstream). In the labeled case, as long as a new label is 182 used there should be no problem. 184 Besides the traffic loop issue, there could be transient traffic loss 185 before both the upstream and downstream's forwarding state are 186 updated. This could be mitigated if the upstream keep sending 187 traffic on the old path (in addition to the new path) and the 188 downstream keep accepting traffic on the old path (but not on the new 189 path) for some time. It is a local matter when for the downstream to 190 switch to the new path - it could be data driven (e.g., after traffic 191 arrives on the new path) or timer driven. 193 For each tree, multiple disjoint instances could be calculated and 194 signaled for live-live protection. Different labels are used for 195 different instances, so that the leaves can differentiate incoming 196 traffic on different instances. As far as transit routers are 197 concerned, the instances are just independent. Note that the two 198 instances are not expected to share common transit routers (it is 199 otherwise outside the scope of this document/revision). 201 1.3. Signaling 203 Each router only receives Leaf A-D routes from the controllers but 204 does not originate or re-advertise S-PMSI/Leaf A-D routes. The re- 205 advertisement of a received route can be blocked based on the fact 206 that a configured import RT matches the RT of the route, which 207 indicates that this router is the target and consumer of the route 208 hence it should not be re-advertised further. The routes includes 209 the forwarding information in the form of Tunnel Encapsulation 210 Attributes (TEA) [I-D.ietf-idr-tunnel-encaps], with enhancements 211 specified in this document. 213 Suppose that for a particular tree, there are two downstream routers 214 D1 and D2 for a particular upstream router U. A controller C may 215 send two Leaf A-D routes to U, as if the two routes were originated 216 by D1 and D2 but reflected by the controller. Alternatively, C could 217 just send one route to U, with the Upstream Router's IP Address field 218 set to U's IP address and the TEA specifying both the two downstreams 219 and its upstream (see Section 3.1.4). In this case, the Originating 220 Router's Address field of the Leaf A-D route is set to the 221 controller's address. Note that for a TEA attached to a unicast 222 NLRI, only one of the tunnels in a TEA is used for forwarding a 223 particular packet, while all the tunnels in a TEA are used to reach 224 multiple endpoints when it is attached to a multicast NLRI. 226 Notice that, in case of labeled trees, the (x,g), mLDP FEC, or SR- 227 P2MP tree identification Section 1.7 signaling is actually not needed 228 to transit routers but only needed to tunnel root/leaves. However, 229 for consistency among the root/leaf/transit nodes, and for 230 consistency with the hop-by-hop signaling, the same signaling (with 231 tree identification encoded in the NLRI) is used to all routers. 233 Nonetheless, a new NLRI route type is defined to encode label/SID 234 instead of tree identification in the NLRI, for scenarios where there 235 is really no need to signal tree identification, e.g. as described in 236 Section 2. On a tunnel root, the tree's binding SID can be encoded 237 in the NLRI. 239 For a tree node to acknowledge to the controller that it has received 240 the signaling and installed corresponding forwarding state, it 241 advertises a corresponding Leaf AD route, with the Originating 242 Router's IP Address set to itself and with a Route Target to match 243 the controller. For comparison, the tree signaling Leaf AD route 244 from the controller has the Originating Router's IP Address set to 245 the controller and the Route Target matching the tree node. The two 246 Leaf AD routes (for controller to signal to a tree node and for a 247 tree node to acknowledge back) differ only in those two aspects. 249 Notice that a leaf node may also send a Leaf A-D route to the 250 controller to signal that it is a leaf of a tree (Section 1.5.1). 251 That leaf-announcing route is different from the above mentioned 252 acknowledgement route at least in the "Upstream Router's IP Address 253 field" - the former has the controller's address while the latter has 254 this node's address in the field. The RDs are likely different as 255 well. 257 With the acknowledgement Leaf AD routes, the controller knows if tree 258 setup is complete. The information can be used for many purposes, 259 e.g. the controller may instruct the ingress to start forwarding 260 traffic onto a tree only after it knows that the tree setup has 261 completed. 263 1.4. Label Allocation 265 In the case of labeled multicast signaled hop by hop towards the 266 root, whether it's (x,g) multicast or "mLDP" tunnel, labels are 267 assigned by a downstream router and advertised to its upstream router 268 (from traffic direction point of view). In the case of controller 269 based signaling, routers do not originate tree join (S-PMSI/Leaf A-D) 270 routes anymore, so the controllers have to assign labels on behalf of 271 routers, and there are three options for label assignment: 273 o From each router's SRLB that the controller learns 275 o From the common SRGB that the controller learns 277 o From the controller's local label space 279 Assignment from each router's SRLB is no different from each router 280 assigning labels from its own local label space in the hop-by-hop 281 signaling case. The assignments for a router is independent of 282 assignments for another router, even for the same tree. 284 Assignment from the controller's local label space is upstream- 285 assigned [RFC5331]. It is used if the controller does not learn the 286 common SRGB or each router's SRLB. Assignment from the SRGB 287 [RFC8402] is only meaningful if all SRGBs are the same and a single 288 common label is used for all the routers on a tree in case of 289 unidirectional tree/tunnel (Section 1.4.1). Otherwise, assignment 290 from SRLB is preferred. 292 The choice of which of the options to use depends on many factors. 293 An operator may want to use a single common label per tree for ease 294 of monitoring and debugging, but that requires explicit RPF checking 295 and either SRGB or upstream assigned labels, which may not be 296 supported due to either the software or hardware limitations (e.g. 297 label imposition/disposition limits). In an SR network, assignment 298 from the common SRGB if it's required to use a single common label 299 per unidirectional tree, or otherwise assignment from SRLB is a good 300 choice because it does not require support for context label spaces. 302 1.4.1. Using a Common per-tree Label for All Routers 304 MPLS labels only have local significance. For an LSP that goes 305 through a series of routers, each router allocates a label 306 independently and it swaps the incoming label (that it advertised to 307 its upstream) to an outgoing label (that it received from its 308 downstream) when it forwards a labeled packet. Even if the incoming 309 and outgoing labels happen to be the same on a particular router, 310 that is just incidental. 312 With Segment Routing, it is becoming a common practice that all 313 routers use the same SRGB so that a SID maps to the same label on all 314 routers. This makes it easier for operators to monitor and debug 315 their network. The same concept applies to multicast trees as well - 316 a common per-tree label is used for a router to receive traffic from 317 its upstream neighbor and replicate traffic to all its downstream 318 neighbor. 320 However, a common per-tree label can only be used for unidirectional 321 trees. Additionally, it requires each router to do explicit RPF 322 check, so that only packets from its expected upstream neighbor are 323 accepted. Otherwise, traffic loop may form during topology changes, 324 because the forwarding state update is no longer ordered. 326 Traditionally, p2mp mpls forwarding does not require explicit RPF 327 check as a downstream router advertises a label only to its upstream 328 router and all traffic with that incoming label is presumed to be 329 from the upstream router and accepted. When a downstream router 330 switches to a different upstream router a different label will be 331 advertised, so it can determine if traffic is from its expected 332 upstream neighbor purely based on the label. Now with a single 333 common label used for all routers on a tree to send and receive 334 traffic with, a router can no longer determine if the traffic is from 335 its expected neighbor just based on that common tree label. 336 Therefore, explicit RPF check is needed. Instead of interface based 337 RPF checking as in PIM case, neighbor based RPF checking is used - a 338 label identifying the upstream neighbor precedes the tree label and 339 the receiving router checks if that preceding neighbor label matches 340 its expected upstream neighbor. Notice that this is similar to 341 what's described in Section "9.1.1 Discarding Packets from Wrong PE" 342 of RFC 6513 (an egress PE discards traffic sent from a wrong ingress 343 PE). The only difference is one is used for label based forwarding 344 and the other is used for (s,g) based forwarding. [note: for 345 bidirectional trees, we may be able to use two labels per tree - one 346 for upstream traffic and one for downstream traffic. This needs 347 further verification]. 349 Both the common per-tree label and the neighbor label are allocated 350 either from the common SRGB or from the controller's local label 351 space. In the latter case, an additional label identifying the 352 controller's label space is needed, as described in the following 353 section. 355 1.4.2. Upstream-assignment from Controller's Local Label Space 357 In this case in the multicast packet's label stack the tree label and 358 upstream neighbor label (if used in case of single common-label per 359 tree) are preceded by a downstream-assigned "context label". The 360 context label identifies a context-specific label space (the 361 controller's local label space), and the upstream-assigned label that 362 follows it is looked up in that space. 364 This specification requires that, in case of upstream-assignment from 365 a controller's local label space, each router D to assign, 366 corresponding to each controller C, a context label that identifies 367 the upstream-assigned label space used by that controller. This 368 label, call it Lc-D, is communicated by D to C via BGP-LS [RFC 7752]. 370 Suppose a controller is setting up unidirectional tree T. It assigns 371 that tree the label Lt, and assigns label Lu to identify router U 372 which is the upstream of router D on tree T. C needs to tell U: "to 373 send a packet on the given tree/tunnel, one of the things you have to 374 do is push Lt onto the packet's label stack, then push Lu, then push 375 Lc-D onto the packet's label stack, then unicast the packet to D". 376 Controller C also needs to inform router D of the correspondence 377 between and tree T. 379 To achieve that, when C sends a Leaf A-D route, for each tunnel in 380 the TEA, it includes a label stack Sub-TLV 381 [I-D.ietf-idr-tunnel-encaps], with the outer label being the context 382 label Lc-D (received by the controller from the corresponding 383 downstream), the next label being the upstream neighbor label Lu, and 384 the inner label being the label Lt assigned by the controller for the 385 tree. The router receiving the route will use the label stacks to 386 send traffic to its downstreams. 388 For C to signal the expected label stack for D to receive traffic 389 with, we overload a tunnel TLV in the TEA of the Leaf A-D route sent 390 to D - if the tunnel TLV has a RPF sub-TLV (Section 3.1.4), then it 391 indicates that this is actually for receiving traffic from the 392 upstream. 394 1.5. Determining Root/Leaves 396 For the controller to calculate a tree, it needs to determine the 397 root and leaves of the tree. This may be based on provisioning 398 (static or dynamically programmed), or based on BGP signaling using 399 the BGP multicast messages defined in [I-D.ietf-bess-bgp-multicast], 400 as described in the following two sections. 402 In both cases, the BGP updates are targeted at the controller, via an 403 address specific Route Target with Global Administration Field set to 404 the controller's address and the Local Administration Field set to 0, 405 or a value pre-assigned to identify a VPN. 407 1.5.1. PIM-SSM/Bidir or mLDP 409 In this case, the PIM Last Hop Routers (LHRs) with interested 410 receivers or mLDP tunnel leaves encode a Leaf A-D route with the 411 Upstream Router's IP Address field set to the controller's address 412 and the Originating Router's IP Address set to the address of the LHR 413 or the P2MP tunnel leaf. The encoded PIM SSM source or mLDP FEC 414 provides root information and the Originating Router's IP Address 415 provides leaf information. 417 1.5.2. PIM ASM 419 In this case, the First Hop Routers (FHRs) originate Source Active 420 routes which provides root information, and the LHRs originate Leaf 421 A-D routes, encoded as in the PIM-SSM case except that it is (*,G) 422 instead of (S,G). The Leaf A-D routes provide leaf information. 424 1.6. Multiple Domains 426 An end to end multicast tree may span multiple routing domains, and 427 the setup of the tree in each domain may be done differently as 428 specified in [I-D.ietf-bess-bgp-multicast]. This section discusses a 429 few aspects specific to controller signaling. 431 Consider two adjacent domains each with its own controller in the 432 following configuration where router B is an upstream node of C for a 433 multicast tree: 435 | 436 domain 1 | domain 2 437 | 438 ctrlr1 | ctrlr2 439 /\ | /\ 440 / \ | / \ 441 / \ | / \ 442 A--...-B--|--C--...-D 443 | 445 In the case of native (un-labeled) IP multicast, nothing special is 446 needed. Controller 1 signals B to send traffic out of B-C link while 447 Controller 2 signals C to accept traffic on the B-C link. 449 In the case of labeled IP multicast or mLDP tunnel, the controllers 450 may be able to coordinate their actions such that Controller 1 451 signals B to send traffic out of B-C link with label X while 452 Controller 2 signals C to accept traffic with the same label X on the 453 B-C link. If the coordination is not possible, then C needs to use 454 hop-by-hop BGP signaling to signal towards B, as specified in 455 [I-D.ietf-bess-bgp-multicast]. 457 The configuration could also be as following, where router B borders 458 both domain 1 and domain 2 and is controlled by both controllers: 460 | 461 domain 1 | domain 2 462 | 463 ctrlr1 | ctrlr2 464 /\ | /\ 465 / \ | / \ 466 / \ | / \ 467 / \|/ \ 468 A--...---B--...---C 469 | 471 As discussed in Section 1.2, when B receives signaling from both 472 Controller 1 and Controller 2, only one of the routes would be 473 selected as the best route and used for programming the forwarding 474 state of the corresponding segment. For B to stitch the two segments 475 together, it is expected for B to know by provisioning that it is a 476 border router so that B will look for the other segment (represented 477 by the signaling from the other controller) and stitch the two 478 together. 480 1.7. SR-P2MP 482 [I-D.voyer-pim-sr-p2mp-policy] describes an architecture to construct 483 a Point-to-Multipoint (P2MP) tree to deliver Multi-point services in 484 a Segment Routing domain. An SR P2MP tree is constructed by 485 stitching together a set of Replication Segments that are specified 486 in [I-D.voyer-spring-sr-replication-segment]. An SR Point-to- 487 Multipoint (SR P2MP) Policy is used to define and instantiate a P2MP 488 tree which is computed by a controller. 490 An SR P2MP tree is no different from an mLDP tunnel in MPLS 491 forwarding plane. The difference is in control plane - instead of 492 hop-by-hop mLDP signaling from leaves towards the root, to set up SR 493 P2MP trees controllers program forwarding state (referred to as 494 Replication Segments) to the root, leaves, and intermediate 495 replication points using Netconf, PCEP, BGP or any other reasonable 496 signaling/programming methods. 498 Procedures in this document can be used for controllers to set up SR 499 P2MP trees with just an additional S-PMSI route type. 501 If/once the SR Replication Segment is extended to bi-redirectional, 502 and SR MP2MP is introduced, the same procedures in this document 503 would apply to SR MP2MP as well. 505 2. Alternative to BGP-MVPN 507 Multicast with BGP signaling from controllers can be an alternative 508 to BGP-MVPN [RFC6514]. It is an attractive option especially when 509 the controller can easily determine the source and leaf information. 511 With BGP-MVPN, distributed signaling is used for the following: 513 o Egress PEs advertise C-multicast (Type-6/7) Auto-Discovery (AD) 514 routes to join C-multicast trees at the overlay (PE-PE) 516 o In case of ASM, ingress PEs advertise Source Active (Type-5) AD 517 routes to signal sources so that egress PEs can establish Shortest 518 Path Trees (SPT). 520 o PEs advertise I/S-PMSI (Type-1/2/3) AD routes to signal the 521 binding of overlay/customer traffic to underlay/provider tunnels. 522 For some types of tunnels, Leaf AD routes are advertised by egress 523 PEs in response to I/S-PMSI AD routes to join the tunnels. 525 Based on the above signaled information, an ingress PE builds 526 forwarding state to forward traffic arriving on the PE-CE interface 527 to the provider tunnel (and local interfaces if there are local 528 downstream receivers), and an egress PE builds forwarding state to 529 forward traffic arriving on a provider tunnel to local interfaces 530 with downstream receivers. 532 Notice that multicast with BGP signaling from controllers essentially 533 programs "static" forwarding state onto multicast tree nodes. As 534 long as a controller can determine how a C-multicast flow should be 535 forwarded on ingress/egress PEs, it can signal to the ingress/egress 536 PEs using the procedures in this document to set up forwarding state, 537 removing the need of the above-mentioned distributed signaling and 538 processing. 540 For the controller to learn the egress PEs for a C-multicast tree (so 541 that it can set up or find a corresponding provider tunnel), the 542 egress PEs can advertise RTC routes that encodes ASM groups or 543 advertise MCAST-TREE Leaf AD routes towards the controller to signal 544 its desire to joins C-multicast trees, each carrying an extended 545 community mapped from the Route Target for the VPN so that the 546 controller knows which VPN it is for. The controller then advertises 547 corresponding MCAST-TREE Leaf AD routes to set up C-multicast 548 forwarding state on ingress and egress PEs. To encode the provider 549 tunnel information in the MCAST-TREE Leaf AD route for an ingress PE, 550 the TEA can explicitly list all replication branches of the tunnel, 551 or just the corresponding SR-P2MP policy name, or just the binding 552 SID. 554 If dynamic switching between inclusive and selective tunnels based on 555 data rate is needed, the ingress PE can advertise/withdraw S-PMSI 556 routes targeted only at the controllers, without Provider Tunnel 557 Attribute attached. The controller then updates relevant MCAST-TREE 558 Leaf AD routes to update C-multicast forwarding states on PEs to 559 switch to a new tunnel. 561 3. Specification 563 3.1. Enhancements to TEA 565 This document specifies two new Tunnel Types and four new sub-TLVs. 566 The type codes will be assigned by IANA from the "BGP Tunnel 567 Encapsulation Attribute Tunnel Types". 569 3.1.1. Any-Encapsulation Tunnel 571 When a multicast packet needs to be sent from an upstream node to a 572 downstream node, it may not matter how it is sent - natively when the 573 two nodes are directly connected or tunneled otherwise. In case of 574 tunneling, it may not matter what kind of tunnel is used - MPLS, GRE, 575 IPinIP, or whatever. 577 To support this, an "Any-Encapsulation" tunnel type is defined. This 578 tunnel MUST have a Tunnel Endpoint Sub-TLV and SHOULD NOT have any 579 other Sub-TLVs. The Tunnel Endpoint Sub-TLV specifies an IP address, 580 which could be any of the following: 582 o An interface's local address - when a packet needs to sent out of 583 the corresponding interface natively. On a LAN multicast MAC 584 address MUST be used. 586 o A directly connected neighbor's interface address - when a packet 587 needs to unicast to the address natively. 589 o An address that is not directly connected - when a packet needs to 590 be tunneled to the address (any tunnel type/instance can be used). 592 3.1.2. Load-balancing Tunnel 594 Consider that a multicast packet needs to be sent to a downstream 595 node, which could be reached via four paths P1~P4. If it does not 596 matter which of path is taken, an "Any-Encapsulation" tunnel with the 597 Tunnel Endpoint Sub-TLV specifying the downstream node's loopback 598 address works well. If the controller wants to specify that only 599 P1~P2 should be used, then a "Load-balancing" tunnel needs to be 600 used, listing P1 and P2 as member tunnels of the "Load-balancing" 601 tunnel. 603 A load-balancing tunnel has one "Member Tunnels" Sub-TLV defined in 604 this document. The Sub-TLV is a list of tunnels, each specifying a 605 way to reach the downstream. A packet will be sent out of one of the 606 tunnels listed in the Member Tunnels Sub-TLV of the load-balancing 607 tunnel. 609 3.1.3. Receiving MPLS Label Stack 611 While [I-D.ietf-bess-bgp-multicast] uses S-PMSI A-D routes to signal 612 forwarding information for MP2MP upstream traffic, when controller 613 signaling is used, a single Leaf A-D route is used for both upstream 614 and downstream traffic. Since different upstream and downstream 615 labels need to be used, a new "Receiving MPLS Label Stack" of type 616 TBD is added as a tunnel sub-TLV in addition to the existing MPLS 617 Label Stack sub-TLV. Other than type difference, the two are the 618 encoded the same way. 620 The Receiving MPLS Label Stack sub-TLV is added to each downstream 621 tunnel in the TEA of Leaf A-D route for an MP2MP tunnel to specify 622 the forwarding information for upstream traffic from the 623 corresponding downstream node. A label stack instead of a single 624 label is used because of the need for neighbor based RPF check, as 625 further explained in the following section. 627 The Receiving MPLS Label Stack sub-TLV is also used for downstream 628 traffic from the upstream for both P2MP and MP2MP, as specified 629 below. 631 3.1.4. RPF Sub-TLV 633 The RPF sub-TLV has a type to be allocated by IANA and a one-octet 634 length. The length is 0 currently, but if necessary in the future, 635 sub-sub-TLVs could be placed in its value part. If the RPF sub-TLV 636 appears in a tunnel, it indicates that the "tunnel" is for the 637 upstream node instead of a downstream node. The tunnel contains an 638 Receiving MPLS Label Stack sub-TLV for downstream traffic from the 639 upstream node, and in case of MP2MP it also contains a regular MPLS 640 Label Stack sub-TLV for upstream traffic to the upstream node. 642 The inner most label in the Receiving MPLS Label Stack is the 643 incoming label identifying the tree (for comparison the inner most 644 label for a regular MPLS Label Stack is the outgoing label). If the 645 Receiving MPLS Label Stack sub-TLVe has more than one labels, the 646 second inner most label in the stack identifies the expected upstream 647 neighbor and explicit RPF checking needs to be set up for the tree 648 label accordingly. 650 3.1.5. Tree Label Stack sub-TLV 652 The MPLS Label Stack sub-TLV can be used to specify the complete 653 label stack used to send traffic, with the stack including both a 654 transport label (stack) and label(s) that identify the (tree, 655 neighbor) to the downstream node. There are cases where the 656 controller only wants to specify the tree-identifying labels but 657 leave the transport details to the router itself. For example, the 658 router could locally determine a transport label (stack) and combine 659 with the tree-identifying labels signaled from the controller to get 660 the complete outgoing label stack. 662 For that purpose, a new Tree Label Stack sub-TLV is defined, with a 663 one-octet length field. The value field contains a label stack with 664 the same encoding as value part of the MPLS Label Stack sub-TLV, but 665 the sub-TLV has a different type. A stack is specified because it 666 may take up to three labels (see Section 1.4): 668 o If different nodes use different labels (allocated from the common 669 SRGB or the node's SRLB) for a (tree, neighbor) tuple, only a 670 single label is in the stack. This is similar to current mLDP hop 671 by hop signaling case. 673 o If different nodes use the same tree label, then an additional 674 neighbor-identifying label is needed in front of the tree label. 676 o For the previous bullet, if the neighbor-identifying label is 677 allocated from the controller's local label space, then an 678 additional context label is needed in front of the neighbor label. 680 3.1.6. Backup Tunnel sub-TLV 682 The Backup Tunnel sub-TLV is used to specify the backup paths for the 683 tunnel. The length is two-octet. The value part encodes a one-octet 684 flags field and a variable length Tunnel Encapsulation Attribute. If 685 the tunnel goes down, traffic that is normally sent out of the tunnel 686 is fast rerouted to the tunnels listed in the encoded TEA. 688 +--------------------------------+ 689 | Sub-TLV Type (1 Octet, TBD) | 690 +--------------------------------+ 691 | Sub-TLV Length (2 Octets) | 692 +--------------------------------+ 693 | P | rest of 1 Octet Flags | 694 +--------------------------------+ 695 | Backup TEA (variable length) | 696 +--------------------------------+ 698 The backup tunnels can be going to the same or different nodes 699 reached by the original tunnel. 701 If the tunnel carries a RPF sub-TLV and a Backup Tunnel sub-TLV, then 702 both traffic arriving on the original tunnel and on the tunnels 703 encoded in the Backup Tunnel sub-TLV's TEA can be accepted, if the 704 Parallel (P-)bit in the flags field is set. If the P-bit is not set, 705 then traffic arriving on the backup tunnel is accepted only if router 706 has switched to receiving on the backup tunnel (this is the 707 equivalent of PIM/mLDP MoFRR). 709 3.2. Context Label TLV in BGP-LS Node Attribute 711 For a router to signal the context label that it assigns for a 712 controller (or any label allocator that assigns labels - from its 713 local label space -- that will be received by this router), a new 714 BGP-LS Node Attribute TLV is defined: 716 0 1 2 3 717 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Type | Length | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Context Label | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | IPv4/v6 Address of Label Space Owner | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 The Length field implies the type of the address. Multiple Context 727 Label TLVs may be included in a Node Attribute, one for each label 728 space owner. 730 An as example, a controller with address 11.11.11.11 allocates label 731 200 from its own label space, and router A assigns label 100 to 732 identify this controller's label space. The router includes the 733 Context Label TLV (100, 11.11.11.11) in its BGP-LS Node Attribute and 734 the controller instructs router B to send traffic to router A with a 735 label stack (100, 200), and router A uses label 100 to determine the 736 Label FIB in which to look up label 200. 738 3.3. SR P2MP Signaling 740 An SR P2MP policy for an SR P2MP tree is identified by a (Root, Tree- 741 id) tuple. It has a set of leaves and set of Candidate Paths (CPs). 742 The policy is instantiated on the root of the tree, with 743 corresponding Replication Segments - identified by (Root, Tree-id, 744 Tree-Node-id) - instantiated on the tree nodes (root, leaves, and 745 intermediate replication points). The Candidate Path is implicitly 746 identified by the Route Distinguisher. 748 3.3.1. S-PMSI A-D Route for SR P2MP 750 With BGP signaled IP multicast trees and mLDP tunnels, the tree/ 751 tunnel identification is encoded in the NLRI of S-PMSI A-D routes and 752 corresponding Leaf A-D routes. The signaling sets up forwarding 753 state on each node of the tree, so the NLRI also contains the 754 identification of the node in the "Upstream Router's IP Address" 755 field. 757 For SR P2MP, forwarding state are represented as Replication Segments 758 and are signaled from controllers to tree nodes. A Replication 759 Segment is identified in a new type of S-PMSI A-D route and 760 corresponding Leaf A-D route (note that the "Leaf" term here does not 761 refer to tree leaves): 763 +- +-----------------------------------+ 764 | | Route Type - 4 (Leaf A-D) | 765 | +-----------------------------------+ 766 | | Length (1 octet) | 767 | L +- +-----------------------------------+ --+ 768 L | E | | Route Type (0x83 - SR P2MP S-PMSI)| | S 769 E | A | +-----------------------------------+ | | 770 A | F | | Length (1 octet) | | P 771 F | | +-----------------------------------+ | M 772 | R | | RD (8 octets) | | S 773 | O | +-----------------------------------+ | I 774 | U | | Root ID (4 or 16 octets) | | 775 N | T | +-----------------------------------+ | N 776 L | E | | Tree ID (4 octets) | | L 777 R | | +-----------------------------------+ | R 778 I | K | | Upstream Router's IP Address | | I 779 | E | +-----------------------------------+ --+ 780 | Y | | Originating Router's IP Address | 781 +- +- +-----------------------------------+ 783 Leaf A-D route for SR Replication Segment 785 3.3.2. S-PMSI A-D Route for Encoding Label/SID 787 As described in Section 1.3, tree label/SID instead of tree 788 identification could be encoded in the NLRI. For that a new Type- 789 0x4a is defined for label stack S-PMSI. A Leaf AD route that embeds 790 the label stack S-PMSI route has following format: 792 +- +-------------------------------------+ 793 | | Route Type - 4 (Leaf A-D) | 794 | +-------------------------------------+ 795 | | Length (1 octet) | 796 | L +- +-------------------------------------+ --+ 797 L | E | | Route Type 0x4a (label stack S-PMSI)| | S 798 E | A | +-------------------------------------+ | | 799 A | F | | Length (1 octet) | | P 800 F | | +-------------------------------------+ | M 801 | R | | RD (8 octets) | | S 802 | O | +-------------------------------------+ | I 803 | U | | Label Stack | | 804 N | T | + ...... + | N 805 L | E | | (variable) | | L 806 R | | +-------------------------------------+ | R 807 I | K | | Upstream Router's IP Address | | I 808 | E | +-------------------------------------+ --+ 809 | Y | | Originating Router's IP Address | 810 +- +- +-------------------------------------+ 812 Leaf A-D route for tree identification by label stack 814 As discussed in Section 1.4.2, a label stack may have to be used to 815 identify a tree in the data plane so a label stack is encoded here. 816 The number of labels is derived from the Length field of the S-PMSI 817 route. Each label stack entry is encoded as following: 819 0 1 2 3 820 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Label |0 0 0 0 0 0 0 0 0 0 0 0| 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 SRv6 case will be specified in future revisions. 827 3.3.3. BGP Community Container for SR P2MP Policy 829 The Leaf A-D route for Replication Segments signaled to the root is 830 also used to signal (parts of) the SR P2MP Policy - the policy name, 831 the set of leaves (optional, for informational purpose), preference 832 of the CP and other information are all encoded in a newly defined 833 BGP Community Container (BCC) [I-D.ietf-idr-wide-bgp-communities] 834 called SR P2MP Policy BCC. 836 The SR P2MP Policy BCC has a BGP Community Container type to be 837 assigned by IANA. It is composed of a fixed 4-octet Candidate Path 838 Preference value, optionally followed by TLVs. 840 0 1 2 3 841 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Candidate Path Preference | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | | 846 | TLVs (optional) | 847 | | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 BGP Community Container for SR P2MP Policy 852 One optional TLV is to enclose the following optional Atoms TLVs that 853 are already defined in [I-D.ietf-idr-wide-bgp-communities]: 855 o An IPv4 or IPv6 Prefix list - for the set of leaves 857 o A UTF-8 string - for the policy name 859 If more information for the policy are needed, more Atoms TLVs or SR 860 P2MP Policy BCC specific TLVs can be defined. 862 The root receives one Leaf A-D route for each Candidate Path of the 863 policy. Only one of the routes need to, though more than one MAY 864 include the above listed optional Atom TLVs in the SR P2MP Policy 865 BCC. 867 3.3.4. SR Policy Tunnel Type 869 The Tunnel Encapsulation Attribute (TEA) attached to Leaf A-D routes 870 encodes all replication branch information. For example, if an SR 871 explicit path is to be used to reach a particular downstream node, 872 the TEA will include a tunnel that lists the entire label stack for 873 that SR path, plus the label that identifies the SR P2MP tree to the 874 downstream node. 876 That SR path may have been installed on the node as a unicast SR 877 policy with a corresponding Binding SID. In stead of listing the 878 entire label stack in an MPLS tunnel in the TEA, a different tunnel, 879 SR Policy Tunnel [I-D.ietf-idr-segment-routing-te-policy], can be 880 used as an alternative. The tunnel includes a Binding SID sub-TLV, 881 an optional endpoint sub-TLV that identifies the downstream node, and 882 an optional one-segment segment list that identifies to the 883 downstream node the SR P2MP tree. When a node receives the Leaf A-D 884 route with the TEA that contains an SR Policy Tunnel without a RPF 885 sub-TLV, the Binding SID is used to locate corresponding outgoing 886 segment lists used to reach the downstream node; the tree-identifying 887 segment from the optional one-segment segment list is added to to 888 outgoing segment lists mapped from the binding SID to form the entire 889 segment list used to send traffic to downstream node. 891 Note that, the SR Policy Tunnel is initially defined to instantiate 892 an SR policy. For that use case it provides information associated 893 with the policy, e.g., Binding SID, preference, and segment lists. 894 The receiving node installs that policy and establishes the mapping 895 from the Binding SID to the outgoing segments. The use of SR Policy 896 Tunnel in this document is to refer to a pre-installed SR policy so 897 the preference and segment lists are not used. 899 If a tunnel in the TEA carries a RPF sub-TLV, it is for the upstream 900 node. The tunnel may be an MPLS tunnel in case of SR MPLS, and the 901 Receiving MPLS Label Stack sub-TLV specifies the incoming label stack 902 that identifies the tree and optionally the upstream neighbor. 903 Alternatively, for both SR-MPLS and SRv6 an SR Policy Tunnel with the 904 RPF sub-TLV can be used, in which the Binding SID sub-TLV is the SID 905 for the tree. 907 If the node is the root and a Binding SID is allocated by the 908 controller, the Binding SID is signaled to the root in a TEA tunnel 909 with a RPF sub-TLV as above but without a destination sub-TLV. 911 4. Procedures 913 Details to be added. The general idea is described in the 914 introduction section. 916 5. Security Considerations 918 This document does not introduce new security risks. 920 6. IANA Considerations 922 This document makes the following IANA requests: 924 o Assign "Any-Encapsulation" and "Load-balancing" tunnel types from 925 the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry 927 o Assign "Member Tunnels", "Receiving MPLS Label Stack", "Tree Label 928 Stack" and "RPF" sub-TLV types from the "BGP Tunnel Encapsulation 929 Attribute Sub-TLVs" registry. The "Member Tunnels" sub-TLV has a 930 two-octet value length (so the type should be in the 128-255 931 range), while the "Receiving MPLS Label Stack", "Tree Label" and 932 "RPF" sub-TLV has a one-octet value length. 934 o Assign "Context Label TLV" type from the "BGP-LS Node Descriptor, 935 Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. 937 o Assign "S-PMSI A-D Route for SR P2MP" route type from the "BGP 938 MCAST-TREE Route Types" registry, with a suggested value of 0x83. 940 o Assign a new BGP Community Container type "SR P2MP Policy", and to 941 create an "SR P2MP Policy Community Container TLV Registry", with 942 an initial entry for "TLV for Atoms". 944 7. Acknowledgements 946 The authors Eric Rosen for his questions, suggestions, and help 947 finding solutions to some issues like the neighbor based explicit RPF 948 checking. The authors also thank Lenny Giuliano, Sanoj Vivekanandan 949 and IJsbrand Wijnands for their review and comments. 951 8. References 953 8.1. Normative References 955 [I-D.ietf-bess-bgp-multicast] 956 Zhang, Z., Giuliano, L., Patel, K., Wijnands, I., Mishra, 957 M., and A. Gulko, "BGP Based Multicast", draft-ietf-bess- 958 bgp-multicast-03 (work in progress), January 2021. 960 [I-D.ietf-idr-segment-routing-te-policy] 961 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 962 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 963 Routing Policies in BGP", draft-ietf-idr-segment-routing- 964 te-policy-11 (work in progress), November 2020. 966 [I-D.ietf-idr-tunnel-encaps] 967 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 968 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 969 encaps-21 (work in progress), January 2021. 971 [I-D.ietf-idr-wide-bgp-communities] 972 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 973 and P. Jakma, "BGP Community Container Attribute", draft- 974 ietf-idr-wide-bgp-communities-05 (work in progress), July 975 2018. 977 [I-D.voyer-pim-sr-p2mp-policy] 978 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 979 Zhang, "Segment Routing Point-to-Multipoint Policy", 980 draft-voyer-pim-sr-p2mp-policy-02 (work in progress), July 981 2020. 983 [I-D.voyer-spring-sr-replication-segment] 984 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 985 Zhang, "SR Replication Segment for Multi-point Service 986 Delivery", draft-voyer-spring-sr-replication-segment-04 987 (work in progress), July 2020. 989 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 990 Requirement Levels", BCP 14, RFC 2119, 991 DOI 10.17487/RFC2119, March 1997, 992 . 994 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 995 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 996 May 2017, . 998 8.2. Informative References 1000 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 1001 Thomas, "Label Distribution Protocol Extensions for Point- 1002 to-Multipoint and Multipoint-to-Multipoint Label Switched 1003 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 1004 . 1006 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1007 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1008 2012, . 1010 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1011 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1012 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1013 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1014 2016, . 1016 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1017 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1018 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1019 July 2018, . 1021 Authors' Addresses 1023 Zhaohui Zhang 1024 Juniper Networks 1026 EMail: zzhang@juniper.net 1027 Robert Raszuk 1028 NTT Network Innovations 1030 EMail: robert@raszuk.net 1032 Dante Pacella 1033 Verizon 1035 EMail: dante.j.pacella@verizon.com 1037 Arkadiy Gulko 1038 Edward Jones Wealth Management 1040 EMail: arkadiy.gulko@edwardjones.com