idnits 2.17.1 draft-parekh-bess-mvpn-evpn-sr-p2mp-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 : ---------------------------------------------------------------------------- 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 (September 08, 2020) is 1298 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) -- Looks like a reference, but probably isn't: '1' on line 586 -- Looks like a reference, but probably isn't: '2' on line 588 -- Looks like a reference, but probably isn't: '3' on line 590 -- Looks like a reference, but probably isn't: '4' on line 592 -- Looks like a reference, but probably isn't: '5' on line 594 -- Looks like a reference, but probably isn't: '6' on line 596 -- Looks like a reference, but probably isn't: '7' on line 598 -- Looks like a reference, but probably isn't: '8' on line 600 -- Looks like a reference, but probably isn't: '9' on line 602 == Outdated reference: A later version (-07) exists of draft-ietf-pim-sr-p2mp-policy-00 == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-08 == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-irb-mcast-04 == Outdated reference: A later version (-06) exists of draft-ietf-bess-evpn-mvpn-seamless-interop-01 == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-03 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-00 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Parekh 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track A. Venkateswaran 5 Expires: March 12, 2021 Cisco Systems, Inc. 6 H. Bidgoli 7 Nokia 8 D. Voyer 9 Bell Canada 10 Z. Zhang 11 Juniper Networks 12 September 08, 2020 14 Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint 15 Trees 16 draft-parekh-bess-mvpn-evpn-sr-p2mp-01 18 Abstract 20 A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain 21 efficiently carries traffic from a Root to a set of Leaves. This 22 document describes extensions to BGP encodings and procedures for 23 P2MP trees used in BGP/MPLS IP VPNs and Ethernet VPNs. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 12, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. SR P2MP P-Tunnels . . . . . . . . . . . . . . . . . . . . . . 3 67 3. PMSI Tunnel Attribute for SR P2MP . . . . . . . . . . . . . . 4 68 3.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1.1. SR MPLS . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. MVPN Auto-Discovery and Binding Procedures . . . . . . . . . 5 71 4.1. Intra-AS I-PMSI . . . . . . . . . . . . . . . . . . . . . 5 72 4.1.1. Originating Intra-AS I-PMSI routes . . . . . . . . . 5 73 4.1.2. Receiving Intra-AS I-PMSI A-D routes . . . . . . . . 6 74 4.2. Using S-PMSIs for binding customer flows to P2MP Segments 7 75 4.2.1. Originating S-PMSI A-D routes . . . . . . . . . . . . 7 76 4.2.2. Receiving S-PMSI A-D routes . . . . . . . . . . . . . 7 77 4.3. Inter-AS P-tunnels using P2MP Segments . . . . . . . . . 8 78 4.3.1. Advertising Inter-AS I-PMSI routes into iBGP . . . . 8 79 4.3.2. Receiving Inter-AS I-PMSI A-D routes in iBGP . . . . 8 80 4.4. Leaf A-D routes for P2MP Segment Leaf Discovery . . . . . 8 81 4.4.1. Originating Leaf A-D routes . . . . . . . . . . . . . 9 82 4.4.2. Receiving Leaf A-D routes . . . . . . . . . . . . . . 9 83 5. Damping of MVPN routes . . . . . . . . . . . . . . . . . . . 9 84 6. SR P2MP Trees for EVPN . . . . . . . . . . . . . . . . . . . 10 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 90 10.2. Informative References . . . . . . . . . . . . . . . . . 12 91 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 94 1. Introduction 96 RFC 6513 [RFC6513] and RFC 6514 [RFC6514] specify procedures that 97 allow a Service Provider to provide Multicast VPN (MVPN) service to 98 its customers. Multicast traffic from a customer is tunneled across 99 the service provider network over Provider Tunnels (P-Tunnels). 100 P-tunnels can be instantiated via different technologies. A service 101 provider network that uses Segment Routing can use a Point-to- 102 Multipoint (SR P2MP) tree [I-D.ietf-pim-sr-p2mp-policy] to 103 instantiate P-Tunnels for MVPN. 105 In a Segment Routing network, a P2MP tree allows efficient delivery 106 of traffic from a Root to set of Leaf nodes. A SR P2MP tree is 107 defined by a SR P2MP Policy and instantiated via a PCE. A P2MP 108 Policy consists of a Root, a Set of Leaf Nodes and a set of candidate 109 paths with optional set of constraints and/or optimization objectives 110 to be satisfied by the P2MP tree. A unique Identifier, called Tree- 111 SID, is associated with a P2MP tree. This Tree-SID can be an MPLS 112 label or an IPv6 address. 114 This document describes extensions to BGP Auto-Discovery procedures 115 specified in RFC 6514 [RFC6514] when P-Tunnels are realized by SR 116 P2MP trees. Use of PIM for Auto-Discovery is outside scope of this 117 document. Support for customer BIDIR-PIM is outside the scope of 118 this document. 120 For BGP MPLS Ethernet VPN specified in RFC 7432 [RFC7432] and 121 extensions to this document, P-Tunnels are advertised for handling 122 multi-destination traffic. These P-tunnels can be realized by SR 123 P2MP trees. 125 The reader is expected to be familiar with concepts and terminology 126 of RFC 6513, RFC 6514 and SR P2MP draft. 128 2. SR P2MP P-Tunnels 130 For MVPN or EVPN, Provider Edge(PE) routers steer customer traffic 131 into a P-Tunnel that can be instantiated by SR P2MP tree. A SR P2MP 132 tree is defined by a SR P2MP policy [I-D.ietf-pim-sr-p2mp-policy]. 134 Given a SR P2MP policy, a PCE computes and instantiates the SR P2MP 135 tree on the nodes that are part of the tree using Replication 136 segments and Tree-SID which a unique identifier for the tree 137 [I-D.ietf-spring-sr-replication-segment]. A Replication segment can 138 be initiated by various methods (BGP, PCEP, others) which are outside 139 the scope of this document. 141 A PCE provides conceptual APIs, listed below, to define and modify SR 142 P2MP policies. These APIs are invoked by a PCC, which is the root of 143 P2MP tree, using various methods (BGP, PCEP, etc.) which are outside 144 the scope of this document. 146 CreatePolicy: TBD 148 DeletePolicy: TBD 150 AddLeaf: TBD 152 DeleteLeaf: TBD 154 The Root of a P2MP tree imposes the Tree-SID to steer the customer 155 payload into the P2MP tree. Provider (P) routers replicate customer 156 payload, using Replication segments, towards the Leaf nodes of the 157 P2MP tree. Leaf nodes of the P2MP tree deliver the customer payload 158 after dispoing the Tree-SID. 160 3. PMSI Tunnel Attribute for SR P2MP 162 A PMSI Tunnel Attribute (PTA) is defined in RFC 6514 [RFC6514] to 163 identify the P-Tunnel that is used to instantiate a Provider 164 Multicast Service Interface (PMSI). The PTA is carried in Intra-AS 165 I-PMSI, Inter-AS I-PMSI, Selective PMSI, and Leaf Auto-Discovery 166 routes. 168 A P2MP tree PTA is constructed as follows: 170 o Tunnel Type: The codepoint is set to [[CREF1: TBD]]for SR P2MP 171 tree from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) 172 Tunnel Types" registry. 174 o Flags: See Section 4 for use of "Leaf Info Required bit". 176 o MPLS Label: See Section 3.1 178 o Tunnel Identifier: The SR P2MP P-tunnel is identified by where, 181 * Tree-ID is a 32-bit unsigned value that identifies a unique 182 P2MP tree at a Root.. 184 * Root is an IP address identifying the Root of a P2MP tree. 185 This can be either an IPv4 or IPv6 address and can be inferred 186 from the PTA length. 188 When a P-Tunnel is non-segmented, the PTA is created by PE router at 189 the Root of a SR P2MP tree. For segmented P-tunnels, each segment 190 can be instantiated by a different technology. If a segment is 191 instantiated using P2MP tree, the router at the root of a P2MP tree 192 creates the PTA. 194 3.1. MPLS Label 196 [RFC6514] allows a PE to aggregate two or more MVPNs onto one 197 P-tunnel by advertising the same P-tunnel in PTA of Auto-Discovery 198 routes of different MVPNs. This section specifies how the "MPLS 199 Label" field of PTA is filled to provide a context bound to a 200 specific MPVN. For EVPN considerations, see SR P2MP Trees for EVPN 201 section. 203 3.1.1. SR MPLS 205 When a SR P2MP P-tunnel, shared across different MVPNs, is 206 instantiated in a SR MPLS domain [RFC8660], "MPLS Field" of a PTA 207 advertised in a Auto-Discovery route MUST contain an upstream- 208 assigned MPLS label that the advertising PE has bound to the MVPN. 210 When a customer payload is steered into a shared SR P2MP P-tunnel, 211 this MPLS label MUST be imposed before the MPLS label representing 212 the Tree-SID. 214 4. MVPN Auto-Discovery and Binding Procedures 216 RFC 6514 [RFC6514] defines procedures for discovering PEs 217 participating in a given MVPN and binding customer multicast flows to 218 specific P-Tunnels. This section specifies modifications to these 219 procedures for SR P2MP P-Tunnels. 221 4.1. Intra-AS I-PMSI 223 Intra-AS I-PMSI A-D routes are exchanged to discover PEs 224 participating in a MVPN within an AS, or across different ASes when 225 non-segmented P-tunnels for inter-AS MVPNs. 227 4.1.1. Originating Intra-AS I-PMSI routes 229 RFC 6514 Section 9.1.1 [1] describes procedures for originating 230 Intra-AS I-PMSI A-D routes. For SR P2MP P-tunnels, these procedures 231 remain unchanged except as described in the following paragraphs. 233 When a PE originates an Intra-AS I-PMSI A-D route with a PTA having 234 SR P2MP P-tunnel Type, it MUST create a P2MP policy by invoking 235 CreatePolicy API of the PCE. When the PCE instantiates the P2MP tree 236 on the PE, the Tree-SID MUST be imposed for customer flow(s) steered 237 into the P2MP tree. The Leaf nodes of P2MP tree are discovered using 238 procedures described in Section 4.1.2. 240 For a PE in "Receiver Sites set", condition (c) is modified to 241 include P2MP tree i.e. such a PE MUST originate an Intra-AS I-PMSI 242 A-D route when some PEs of the MVPN have VRFs that use SR P2MP tree 243 but MUST NOT create a SR P2MP policy as described above. 245 When a PE withdraws an Intra-AS I-PMSI A-D route, advertised with a 246 PTA having SR P2MP P-tunnel Type, the Tree-SID imposition state at 247 the PE MUST be removed. 249 A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs 250 onto the same SR P2MP P-tunnel. When a PE withdraws the last Intra- 251 AS I-PMSI A-D route, advertised with a PTA identifying a SR P2MP 252 P-tunnel , it SHOULD remove the SR P2MP policy by invoking 253 DeletePolicy API of the PCE. 255 4.1.2. Receiving Intra-AS I-PMSI A-D routes 257 Procedure for receiving Intra-AS I-PMSI A-D routes, as described in 258 RFC 6514 Section 9.1.2 [2], remain unchanged for SR P2MP P-tunnels 259 except as described in the following paragraphs. 261 When a PE that advertises a SR P2MP P-tunnel in the PTA of its Intra- 262 AS I-PMSI A-D route, imports an Intra-AS I-PMSI A-D route from some 263 PE, it MUST add that PE as a Leaf node of the P2MP tree. The 264 Originating IP Address of the Intra-AS i-PMSI A-D route is used as 265 the Leaf Address when invoking AddLeaf API of the PCE. This 266 procedure MUST also be followed for all Intra-AS I-PMSI routes that 267 are already imported when the PE advertises a SR P2MP P-tunnel in PTA 268 of its Intra-AS I-PMSI A-D route. 270 A PE that imports and processes an Intra-AS I-PMSI A-D route from 271 another PE with PTA having SR P2MP P-Tunnel MUST program the Tree-SID 272 of the P2MP tree identified in the PTA of the route for disposition. 273 Note that an Intra-AS I-PMSI A-D route from another PE can be 274 imported before the P2MP tree identified in the PTA of the route is 275 instantiated by the PCEat the importing PE. In such case, the PE 276 MUST correctly program Tree-SID for disposition. A PE in "Sender 277 Sites set" MAY avoid programming the Tree-SID for disposition. 279 When an Intra-AS I-PMSI A-D route, advertised with a PTA having SR 280 P2MP P-tunnel Type is withdrawn, a PE MUST remove the disposition 281 state of the Tree-SID associated with P2MP tree. 283 A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs 284 onto the same SR P2MP P-tunnel. When a remote PE withdraws an Intra- 285 AS I-PMSI A-D route from a MVPN, and if this is the last MVPN sharing 286 a SR P2MP P-tunnel, a PE must remove the originating PE as a Leaf 287 from the P2MP tree, by invoking DeleteLeaf API. 289 4.2. Using S-PMSIs for binding customer flows to P2MP Segments 291 RFC 6514 [RFC6514] specifies procedures for binding (C-S,C-G) 292 customer flows to P-tunnels using S-PMSI A-D routes. RFC 6525 293 [RFC6625] specifies additional procedures to binding aggregate 294 customer flows to P-tunnels using "wildcard" S-PMSI A-D routes. This 295 section describes modification to these procedures for SR P2MP 296 P-tunnels. 298 4.2.1. Originating S-PMSI A-D routes 300 RFC 6514 Section 12.1 [3] describes procedures for originating S-PMSI 301 A-D routes. For SR P2MP P-tunnels, these procedures remain unchanged 302 except as described in the following paragraphs. 304 When a PE originates S-PMSI A-D route with a PTA having SR P2MP 305 P-tunnel Type, it MUST set the "Leaf Info Required bit" in the PTA. 306 The PE MUST create a SR P2MP policy by invoking1 API of the PCE. 307 When the PCEinstantiates the P2MP tree on the PE, the Tree-SID MUST 308 be imposed for customer flows steered into the SR P2MP P-tunnel. 310 The Leaf nodes of P2MP tree are discovered by Leaf A-D routes using 311 procedures described in Section 4.4.2. When a PE originates S-PMSI 312 A-D route with a PTA having SR P2MP P-tunnel Type, it is possible the 313 PE might have imported Leaf A-D routes whose route keys match the 314 S-PMSI A-D route. The PE MUST re-apply procedures of Section 4.4.2 315 to these Leaf A-D routes. 317 When a PE withdraws a S-PMSI A-D route, advetised with PTA having 318 P2MP tree P-tunnle type, the Tree-SID imposition state MUST be 319 removed. 321 A PE MAY aggregate two or more S-PMSIs onto the same SR P2MP 322 P-tunnel. When a PE withdraws the last S-PMSI A-D route, advertised 323 with a PTA identifying a specific SR P2MP P-tunnel , it SHOULD remove 324 the SR P2MP policy by invoking DeletePolicy API of the PCE. 326 4.2.2. Receiving S-PMSI A-D routes 328 RFC 6514 Section 12.3 [4] describes procedures for receiving S-PMSI 329 A-D routes. For SR P2MP P-tunnels, these procedures remain unchanged 330 except as described in the following paragraphs. 332 The procedure to join SR P2MP P-tunnel of S-PMSI A-D route by using a 333 Leaf A-D route is described in Section 4.4.1. If P2MP tree 334 identified in PTA of S-PMSI A-D route is already instantiated by PCE, 335 the PE MUST program Tree-SID for disposition. If the P2MP tree is 336 instantiated later, the Tree-SID MUST be programmed for disposition 337 at that time. 339 When a S-PMSI A-D route, whose SR P2MP P-tunnel is joined by a PE, is 340 withdrawn, or when conditions (see RFC 6514 Section 12.3 [5]) 341 required to join that P-Tunnel are no longer satisfied, the PE MUST 342 leave the P-Tunnel. The PE MUST withdraw the Leaf A-D route it had 343 originated and remove the Tree-SID disposition state. 345 4.3. Inter-AS P-tunnels using P2MP Segments 347 A segmented inter-AS P-tunnel consists of one or more intra-AS 348 segments, one in each AS, connected by inter-AS segments between 349 ASBRs of different ASes . These segments are constructed by PEs/ASBRs originating or re- 351 advertising Inter-AS I-PMSI A-D routes. This section describes 352 procedures for instantiating intra-AS segments using SR P2MP trees. 354 4.3.1. Advertising Inter-AS I-PMSI routes into iBGP 356 RFC 6514 Section 9.2.3.2 [6] specifies procedures for advertising an 357 Inter-AS I-PMSI A-D route to construct an intra-AS segment. The PTA 358 of the route identifies the type and identifier of the P-tunnel 359 instantiating the intra-AS segment. The procedure for creating SR 360 P2MP P-tunnel for intra-AS segment are same as specified in 361 Section 4.2.1 except that instead of S-PMSI A-D routes, the 362 procedures apply to Inter-AS I-PMSI A-D routes. 364 4.3.2. Receiving Inter-AS I-PMSI A-D routes in iBGP 366 RFC 6514 Section 9.2.3.2 [7] specifies procedures for processing an 367 Inter-AS I-PMSI A-D route received via iBGP. If the PTA of the 368 Inter-AS I-PMSI A-D route has SR P2MP P-tunnel Type, the procedures 369 are same as specified in Section 4.2.2 except that instead of S-PMSI 370 A-D routes, the procedures apply to Inter-AS I-PMSI A-D routes. If 371 the receiving router is an ASBR, the Tree-SID is stitched to the 372 inter-AS segments to ASBRs in other ASes. 374 4.4. Leaf A-D routes for P2MP Segment Leaf Discovery 376 This section describes procedures for originating and processing Leaf 377 A-D routes used for Leaf discovery of SR P2MP trees. 379 4.4.1. Originating Leaf A-D routes 381 The procedures for originating Leaf A-D route in response to 382 receiving a S-PMSI or Inter-AS I-PMSI A-D route with PTA having SR 383 P2MP P-tunnel Type are same as specified in RFC 6514 384 Section 9.2.3.4.1 [8]. 386 4.4.2. Receiving Leaf A-D routes 388 Procedures for processing a received Leaf A-D route are specified in 389 RFC 6514 Section 9.2.3.5 [9]. These procedures remain unchanged for 390 discovering Leaf nodes of P2MP trees except for considerations 391 described in following paragraphs. These procedures apply to Leaf 392 A-D routes received in response to both S-PMSI and Inter-AS I-PMSI 393 A-D routes, shortened to "A-D routes" in this section 395 A Root PE/ASBR MAY use the same SR P2MP P-tunnel in PTA of two or 396 more A-D routes. For such aggregated P2MP trees, the PE/ASBR MAY 397 receive multiple Leaf A-D routes from a Leaf PE. The P2MP tree for 398 which a Leaf A-D is received can be identified by examining the P2MP 399 tunnel Identifier in the PTA of A-D route that matches "Route Key" 400 field of the Leaf A-D route. When the PE receives the first Leaf A-D 401 route from a Leaf PE, identified by the Originating Router's IP 402 address field, it MUST add that PE as Leaf of the P2MP tree by 403 invoking the AddLeaf API of the PCE. 405 When a Leaf PE withdraws the last Leaf A-D route for a given SR P2MP 406 P-tunnel, the Root PE MUST remove the Leaf PE from the P2MP tree by 407 invoking DeleteLeaf API of PCE. Note that Root PE MAY remove the 408 P2MP tree, via the DeletePolicyAPI, before the last Leaf A-D is 409 withdrawn. In this case, the Root PE MAY decide to not invoke the 410 DeleteLeaf API. 412 5. Damping of MVPN routes 414 When P2MP trees are used as P-Tunnels for S-PMSI A-D routes, change 415 in group membership of receivers connected to PEs has direct impact 416 on the Leaf node set of a P2MP tree. If group membership changes 417 frequently for a large number of groups with a lot of receivers 418 across sites connected to different PEs, it can have an impact on the 419 interaction between PEs and the PCE. 421 Since Leaf A-D routes are used to discover Leaf PE of a P2MP tree, it 422 is RECOMMENDED that PEs SHOULD damp Leaf A-D routes as described in 423 Section 6.1 of RFC 7899 [RFC7899]. PEs MAY also implement procedures 424 for damping other Auto-Discovery and BGP C-multicast routes as 425 described in [RFC7899]. 427 6. SR P2MP Trees for EVPN 429 BGP MPLS Ethernet VPN specified in RFC 7432 [RFC7432] specifies 430 Inclusive Multicast Ethernet Tag route to support Broadcast, Unknown 431 Unicast and Multicast (BUM) traffic. This IMET route is the 432 equivalent of MVPN Intra-AS I-PMSI route and is advertised with a 433 PMSI Tunnel Attribute (PTA) as specified in RFC 6514 [RFC6514]. 434 P-tunnels advertised in the PTA can be realized by SR P2MP trees. 435 For SR P2MP trees, the ESI label used for split horizon MUST be 436 either upstream assigned by PE advertising Inclusive Multicast 437 Ethernet Tag route or assigned from a global context such as "Domain- 438 wide Common Block" (DCB) as specified in 439 [I-D.ietf-bess-mvpn-evpn-aggregation-label]. 441 [I-D.ietf-bess-evpn-bum-procedure-updates] updates BUM procedures to 442 support slective multicast and P-tunnel segmentation in EVPN. This 443 documents specifies new route types that are advertised with PTA. 444 These P-tunnels can be realized by SR P2MP trees. 446 [I-D.ietf-bess-evpn-irb-mcast] specifies procedures to support Inter- 447 Subnet Multicast. [I-D.ietf-bess-evpn-mvpn-seamless-interop] 448 specifies how MVPN SAFI routes can be used to support Inter-Subnet 449 Multicast. The P-tunnels advertised in PTA of either EVPN and MVPN 450 routes as specified in these documents respectively can be realized 451 by SR P2MP trees. 453 The same procedures specified for MVPN are used to collect the leaf 454 information of corresponding SR P2MP tree (either based on IMET route 455 or Leaf A-D routes in response to x-PMSI routes), to pass the tree 456 information to the PCE controller, and to get back tree forwarding 457 state used for customer multicast traffic forwarding. 459 7. IANA Considerations 461 IANA to assign a codepoint [[CREF2: TBD]] for "P2MP tree" in the 462 "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" 463 registry. 465 8. Security Considerations 467 The procedures in this document do not introduce any additional 468 security considerations beyond those mentioned in [RFC6513] and 469 [RFC6514]. For general security considerations applicable to P2MP 470 trees, please refer to [I-D.ietf-pim-sr-p2mp-policy] . 472 9. Contributors 474 Zafar Ali 475 Cisco Systems, Inc. 476 US 478 Email: zali@cisco.com 480 Ehsan Hemmati 481 Cisco Systems, Inc. 482 US 484 Email: ehemmati@cisco.com 486 Jayant Kotalwar 487 Nokia 488 Mountain View 489 US 491 Email: jayant.kotalwar@nokia.com 493 Tanmoy Kundu 494 Nokia 495 Mountain View 496 US 498 Email: tanmoy.kundu@nokia.com 500 Clayton Hassen 501 Bell Canada 502 Vancouver 503 CA 505 Email: clayton.hassen@bell.ca 507 10. References 509 10.1. Normative References 511 [I-D.ietf-pim-sr-p2mp-policy] 512 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 513 Zhang, "Segment Routing Point-to-Multipoint Policy", 514 draft-ietf-pim-sr-p2mp-policy-00 (work in progress), July 515 2020. 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, 519 DOI 10.17487/RFC2119, March 1997, 520 . 522 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 523 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 524 2012, . 526 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 527 Encodings and Procedures for Multicast in MPLS/BGP IP 528 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 529 . 531 10.2. Informative References 533 [I-D.ietf-bess-evpn-bum-procedure-updates] 534 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 535 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 536 bess-evpn-bum-procedure-updates-08 (work in progress), 537 November 2019. 539 [I-D.ietf-bess-evpn-irb-mcast] 540 Lin, W., Zhang, Z., Drake, J., Rosen, E., Rabadan, J., and 541 A. Sajassi, "EVPN Optimized Inter-Subnet Multicast (OISM) 542 Forwarding", draft-ietf-bess-evpn-irb-mcast-04 (work in 543 progress), October 2019. 545 [I-D.ietf-bess-evpn-mvpn-seamless-interop] 546 Sajassi, A., Thiruvenkatasamy, K., Thoria, S., Gupta, A., 547 and L. Jalil, "Seamless Multicast Interoperability between 548 EVPN and MVPN PEs", draft-ietf-bess-evpn-mvpn-seamless- 549 interop-01 (work in progress), July 2020. 551 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 552 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 553 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 554 ietf-bess-mvpn-evpn-aggregation-label-03 (work in 555 progress), October 2019. 557 [I-D.ietf-spring-sr-replication-segment] 558 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 559 Zhang, "SR Replication Segment for Multi-point Service 560 Delivery", draft-ietf-spring-sr-replication-segment-00 561 (work in progress), July 2020. 563 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 564 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 565 RFC 6625, DOI 10.17487/RFC6625, May 2012, 566 . 568 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 569 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 570 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 571 2015, . 573 [RFC7899] Morin, T., Ed., Litkowski, S., Patel, K., Zhang, Z., 574 Kebler, R., and J. Haas, "Multicast VPN State Damping", 575 RFC 7899, DOI 10.17487/RFC7899, June 2016, 576 . 578 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 579 Decraene, B., Litkowski, S., and R. Shakir, "Segment 580 Routing with the MPLS Data Plane", RFC 8660, 581 DOI 10.17487/RFC8660, December 2019, 582 . 584 10.3. URIs 586 [1] https://tools.ietf.org/html/rfc6514#section-9.1.1 588 [2] https://tools.ietf.org/html/rfc6514#section-9.1.2 590 [3] https://tools.ietf.org/html/rfc6514#section-12.1 592 [4] https://tools.ietf.org/html/rfc6514#section-12.3 594 [5] https://tools.ietf.org/html/rfc6514#section-12.3 596 [6] https://tools.ietf.org/html/rfc6514#section-9.2.3.2 598 [7] https://tools.ietf.org/html/rfc6514#section-9.2.3.2 600 [8] https://tools.ietf.org/html/rfc6514#section-9.2.3.4.1 602 [9] https://tools.ietf.org/html/rfc6514#section-9.2.3.5 604 Authors' Addresses 605 Rishabh Parekh 606 Cisco Systems, Inc. 607 170 W. Tasman Drive 608 San Jose, CA 95134 609 USA 611 Email: riparekh@cisco.com 613 Clarence Filsfils 614 Cisco Systems, Inc. 615 Brussels 616 BE 618 Email: cfilsfil@cisco.com 620 Arvind Venkateswaran 621 Cisco Systems, Inc. 622 170 W. Tasman Drive 623 San Jose, CA 95134 624 USA 626 Email: arvvenka@cisco.com 628 Hooman Bidgoli 629 Nokia 630 Ottawa 631 CA 633 Email: hooman.bidgoli@nokia.com 635 Daniel Voyer 636 Bell Canada 637 Montreal 638 CA 640 Email: daniel.voyer@bell.ca 642 Zhaohui Zhang 643 Juniper Networks 645 Email: zzhang@juniper.net